Why you should respect deprecation warnings

At C42, I have worked on multiple Ruby on Rails migration projects. A simple task of upgrading an application from Rails 2.3 to Rails 3, can take anywhere from two days to three months. After such experiences, I have developed a small set of rules to make sure, my projects don't run into these two to three months long upgrades. A blog post by me on, how a simple discipline of fixing deprecation warnings can help you maintain your ruby applications in the long run.


C42 Launchpad - bridging the gap between hackers and the industry

At C42 Engineering, we spend about 108 man hours for every good developer we hire. For a small product company, I would rather spend that time developing features. We've always wanted to hire more awesome developers with less effort, and I think we may have a way to do just that.

We receive about 30-40 resumes a month. Our interview process, although time consuming, allows us to know the candidate better. Even before we call them to our office, we spend about half an hour with each candidate on the phone. Every face to face interview takes about 6 hours. After this extensive investment of time and energy, we consider ourselves lucky if we hire 1 developer a month, i.e. conversion rate of 2.5%, something we always wanted to improve.

While speaking with other startups at RubyConf India 2012, I realized, rather, that a 2.5% conversion rate is extremely high. I have heard horror stories of interviewing 150 candidates to hire one or two developers. The point is, businesses spend enormous amounts of energy and money in the hiring market with returns that are too low to be considered acceptable.

If we ask any consultancy or product company what skill set they would like prospective hires to have, the following common points come up over and over:

  • Understands what is good code
  • Understands maintainability
  • Understands Object Oriented Programming principles
  • Familiarity with TDD
  • Deployments and DevOps
  • Awareness of standards and conventions

In summary, every business needs developers who care about good code and are capabale of being productive from day one.

The missing rockstars

Most engineers who don't make it through our interview process are asked to apply again in six months. We don't do it just out of politeness, but because we actually believe that they can in time grow to become the capable developers we need.

These developers have the potential and inclination to become experts, but lack the correct exposure and guidance. Focused training on OO, TDD and Agile, with discussions around nuances of development practices and principles will convert these talented folk into the rockstars that every company seeks.

As always, we gave this feedback to the candidates in question. A consistent pattern emerged where candidates would get back to us asking for more information on how they could go about learning the requisite skills.

Unfortunately, there are no organizations like hacker/school in India, places that expose programmers to the art of software craftsmanship. Be it universities or university-like classroom training programs, they just can't keep up with our fast moving industry. The gap is already large and growing every day.

Most lot of these skills are best learned by working closely with experienced developers and following practices for an extended duration. A 2 or 3 day workshop is useful for knowledge transfer, but it's impossible to develop discipline or grok the principles underlying the methodology in that short a duration.

The launchpad

C42 Launchpad hopes to be an answer to this problem. A 4-6 weeks full time hands-on workshop that will cover everything C42 Engineering expects a developer to know before she starts working on a codebase. We will have different batches for fresh graduates and for experienced developers. A rough sketch of the program for freshers:

  • Programming 101
    • Introduction to Ruby
    • Introduction to Git
    • OO Design Principles
    • OO Patterns
      • Creational
      • Structural
      • Behavioral
    • Programming/Design anit-patterns
  • Web Application Development
    • Working within browsers
      • Introduction to HTML & DOM
      • Introduction to CSS
      • Introduction to Javascript and Prototype based programming
    • Ruby on Rails 101
      • Journey through Rails components
      • TDD with rails
  • Introduction to Agile
    • Agile principles
    • Planning and estimation
    • Importance of Automated Testing and Continuous Integration
    • Pair programming, TDD, Simple Design, Refactoring
    • Basics of XP and Scrum
  • 2 Weeks of Ruby on Rails project development in teams, following all the methodologies and principles mentioned above.

The course structure as you can see is still being finalized, but the guiding principle is simple. Provide opportunity and inspiration to the willing engineers to hone their skills.

Bridging the gap

Lots of potential hackers join the Indian IT industry with big dreams. Due to lack of inspiration and opportunities, they stop caring about programming and become an hourly billable unit in an excel sheet somewhere. We want to show them what real development feels like, enable them with both the tools and the practices to become productive and enjoy coding as we do.

Providing this training is pointless if they don't get to work at places where these skills are appreciated. A number of startups in India are being limited by the shortage of technical talent. Businesses are unable to grow as they struggle to hire talented programmers that can build high quality, maintainable codebases that scale and are easy to change. If their codebases are in good hands, business owners are free to concentrate on the non-technical aspects that are often extremely critical for the success of the business.

We plan to connect developers, who are looking for new challenges, with companies who need and appreciate the value they bring to the table.


Aakash is VP Consulting at C42 Engineering. If you liked this post, please consider...


No virtuous circle, or how India's Silicon Valley is... different

A blog post by me explaining my take on India's startup scene, something which has directly impacted C42 Engineering's business model.


Why I design for C42 Engineering, and why you should too

After 13 years of helping companies of all shapes and sizes design products and applications, I joined C42 Engineering a couple of months ago to start our experience design practice, based in the Bay Area.  I’m not sure if the phrase ‘design practice lead’ reflects what I do, but I'll get to that later.  As you can imagine, for a young start-up in India that is making significant investments in developing products, it is challenging to support my market salary in the US.  So, I chose to earn a variable income, with the optimism of growing our business in the US market, offering services in software design and development. 

My decision has been met with a variety of reactions - some positive, and a lot skeptical.  For me, this move was the most logical next step, and a no-brainer.  The main challenge so far has been explaining its rewards to a husband who is a mergers and acquisitions consultant, and I’ve come out in flying colors on that one.  Here’s why I think C42 is going to be an organization of choice for other designers as well:

 At C42, the whole is greater than the sum of its parts

"In order to achieve high-quality user experience in a company's offerings, there must be a seamless merging of the services of multiple disciplines, including engineering, marketing, graphical and industrial design, and interface design" (quoting Nielsen Norman). I know this is true from having practiced collaborative design in a variety of environments.  But, I am yet to see another organization where personal agendas and turf wars have not got in the way of achieving this seamless merging.  At best, you might have engineering, product management, and design teams having regular meetings, and more commonly each of them throwing deliverables over the cube to each other.  Ultimately, the product suffers, and the user’s experience is compromised. C42 being a small team seeded with talented engineers who aren’t sniffled by silos and roles, is extremely well positioned to deliver products and solutions that are beautifully designed and engineered by a multi-disciplinary team.

At C42, it will be as beautiful as possible, even if it's inside the box

I’ve met several designers with great ideas for product designs, frustrated that those designs just show up in their portfolio, and haven’t made it into the hands of the user.  At C42, you will experience the satisfaction and joy of seeing your design ideas get delivered.  What’s more impressive is the passion and commitment with which the team writes beautiful code.  If you’re a passionate designer, you can relate to what Steve Jobs said about the PC board “I want it to be as beautiful as possible, even if it’s inside the box.  A great carpenter isn’t going to use lousy wood for the back of a cabinet, even though nobody’s going to see it.”  

C42 Labs is design thinking in action

The empathy with which C42's first product (rubymonk.com) was designed, the extreme collaboration and iterative prototyping that's gone into its releases - is design thinking in action.  If you are interested in leading through design, I invite you to see how C42 Labs develops products. If design thinking is more doing than thinking, then, the team does one heck of a lot of design thinking.  It provides a solid platform for professional growth and thought leadership in the design community.

So, if you are someone who cares about the user more than your design portfolio, someone who believes that user experience should be second nature to software engineering teams, someone who is committed to making the power of extreme collaboration work in creating great products, you want to talk to us.


Anu is the Practice Lead for User Experience Design at C42 Engineering. If you liked this post, please consider...


Want designers who code? Something's got to give.

While we at C42 continue to debate this topic amongst ourselves, thought I'd share my thoughts, and hear what others have to say.  Let us know what you think.

Want designers who code? Something's got to give.