engineering perfection on rails

How would you describe RubyMonk's interface?

We receive a lot of love from our users about RubyMonk's visual design. And while we agree -- it's super cute! -- the site's visuals are hardly its interface. The "user interface" for RubyMonk is really the boundary between the student and the mentor.

How do we evaluate your code? How do we decide whether it is correct or not? These are the interesting questions in the user interaction. And, as emerges in the design of any product, these questions highlight the necessary unification of form and function, engineering and design, purpose and path. When you boil it down, the purpose of RubyMonk is to automate the teacher. On some level, this goal might seem akin to beating the Turing Test. In its current incarnation things are much simpler, of course.

I've explored this idea a bit in my post "defining the interface for rubymonk". Take a look and check back soon as I take this idea forward to discuss the yin and yang of tests and the boundaries they exercise.

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...

• following @aakashd on twitter
• subscribing to this blog

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...

• following @anu5ramaswamy on twitter
• subscribing to this blog

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.

Three years in a row: We're speaking at RubyConf India once again

We've got three talks at this years RubyConf India. Here's a quick list - click through for more details.

• "Sandboxing Ruby Code - Lessons from the battlefield," by Tejas Dinkar and Jasim Basheer
• "Clojure is my favourite ruby," by Steven Deobald
• "Testing patterns," by Sidu Ponnappa and Aninda Kundu 

We're also happy to be one of the sponsors the event for the second year running.

Most of C42 is flying out to Pune for RubyConf India, so do say hello if you're going to be there.

TDD isn't about testing, it's about design

The reason I haven't written about this before is because in certain circles, this post would be stating the obvious. However, it's become increasing clear to me that in the mad rush to prove that they 'get testing,' most new Ruby/Rails programmers completely miss the real reason TDD is so valuable. So, here goes:

"TDD is not about testing your code. The fact that your code gets tested is a valuable side effect."

The hardest part of writing code is keeping all of the moving parts in your head so you know exactly what side-effects the new code you're writing will have on existing code. This is how most bugs crop up. Nobody wants to introduce a bug, but the chain of cause and effect in a non-trivial codebase can be very hard to follow. Everyone runs into this sooner or later, and this has been named "The curse of the gifted programmer" (in a different context, but the principle applies).

TDD is a tool which allows you to use your tests to break the code you're working on down into tiny chunks, thereby reducing what you need to hold in your head, in turn reducing the likelihood of you introducing defects and making it easier for you to understand what's going on. The fact that the the test suite thus produced can subsequently be used for regression testing is a very positive and useful side-effect, but a side-effect nonetheless.

A few other conclusions can be derived from this statement:

• Languages and codebases which eschew side-effects and thereby achieve the same goal of reducing the quantity of code programmers need to hold in their heads see decreased or negligible value from TDD.
• If you and your team are smart enough, you don't need TDD because holding code in your head isn't a problem. You know you're this smart when you can consistently hold in your head the cause and effect chain across your entire codebase for any change you or your colleagues make.
• If you can't test drive a particular piece of code, either you know too little about possible solutions, or you have poorly factored code. Consequently, you can use TDD as a sort of canary-in-the-coalmine to figure out which bits of your codebase could be better factored.

If testing was what TDD was about, TDD (test first) and unit testing (test last) would be equivalent. They aren't.

Memories of conf.KDE.in

Well they say in solitude you sometimes remember your fondest memories, I would like to share with one you folks.

Today morning I realized that it was March, now March might be an ordinary month for most of you but looking back I can say for sure it was and it still is special for me;  I can clearly recall the events that occurred and how they changed my life.

A year back the first KDE conf India happened from 9-13th of March, I remember I was more of an ordinary student in the class, I had a decent GPA and I used to get by without much trouble for the most part but somehow on 9th I had an urge to attend KDE conf despite it had 700 bucks for registration and my HOD(Head of Department) had clearly denied the request to attend it, but I still went for the conference as it was happening right below my department.

I wish I could say that after attending the very first talk of the conference my life changed but in actuality nothing happened ;  I met really smart people but that just increased my insecurity and I couldn’t follow most of the talks. I was doubting if I made right choice of attending it in the first place, both 9th – 10th went without any feelings that I learned something valuable, something which I could have followed and used in my daily life.

Than came 11th March, the day was normal till the afternoon after that we had a hands-on bug squashing lab, where young KDE developers would guide us by fixing a bug from KDE bugzilla. Since it was the last day for the talks and I was tired with all the information i received which I couldn’t made sense of; I wanted to skip the lab but somehow I didn’t do that for some reason. In the lab we had to solve a bug in Rekonq (a browser bundled with KDE) the bug description said that it had to something to do with ad blockers, now I used to browse the internet before and I knew a thing or two about how Ad-blockers work; so I quickly found the code/file which needed to be patched and it was more of a lucky guess then any real skill involved but that was enough as it impressed the KDE developer that were there.

One particular (Vishesh Handa) came to me and told me that I knew things and I should  use my knowledge to write patches for KDE and there is something about it; when a complete stranger sees your work for the first time and praises you for it. I think I was on cloud nine for rest of the day; when I reached my apartment I started looking for sub project to contribute to and I found Nepomuk junior job page which basically consists of easy bugs which can help new people learn about the project, bug fixing and writing patches but I was naive and I didn’t know where you can actually find the source code, let alone any knowledge about version control systems.

Luckily next day it was a hacking session for the speakers; I took that opportunity to meet them and learn how to solve bugs and where to find help in case you don’t know what to do. They even gave me a simple bug to get started on which was quite trivial and would take around 3-4 lines of code to solve it but with all things that look simple while looking back, the bug took me more than 6 hours to fix as I was clueless on where exactly i needed to put that code in the first place.Though all of that work didn’t go to waste as I remember the feeling when that patch was committed on the next day. I was hooked after that commit and in 3-4 days I submitted even more patches which eventually got committed. After a month or so I finally received my KDE developer account to push my own commits.

Looking back, if I had not attend the lab or if that KDE developer (Vishesh Handa) hadn’t said those things to me, my entire life would have been completely different and I would be a normal guy today working at a MNC but thankfully life had better plans. So many great memories are the result of that one moment and in my heart I still have gratitude for KDE without it I wouldn’t have become a contributor, a GSoCer, made smart friends, visited different places, improved my programming skills and maybe biggest of all I wouldn’t be a part of c42 (The place I work at). My entire life from that single moment to the moment when I received my first salary is indebted to KDE.

Recently, I finally had the chance to catch up with one of my friend from KDE (Shantanu) whom I first met at conf.KDE.in . We kept delaying our meet because of our busy schedules but we finally caught up last Sunday and the last Sunday was on 11th March. eh, coincidences can be funny sometimes

Overcoming UX Exclusivity

Anu Ramaswamy, our Practice Lead for XD writes about why UX should be second nature to software development teams. Take a look and let us know what you think!