I have always shunned the idea of hiring people only from the top institutions at my workplace. The reason for that was my observation; that there were people from many relatively not so top institutions ending up top performers at the organization compared to their peers from top ones. This was not an one off observation, I had been observing this year on year that recruits from top institutions and not so top institutions were many at times on par with each other and there were few exceptions on either sides.
My school was a very competitive place to study, scoring in the 90s out 100 just meant that you are in the 50th percentile. It was getting increasingly tough as grades went higher and people were merely looking to outscore each other without gaining deep understanding of the subjects studied. Parent’s pressure on the ranking meant students had no choice but to play in the rat race getting stressed out and not learning much except scoring marks. There was a shuffle of groups happened after grade 8 and that was a breather in my school life, the competition eased out and it was so easy to be at the 75th percentile. This sudden ease of pressure made me learn subjects like science and maths with greater depth in understanding without worrying about optimizing learning only from the exam point of view. I could see that depth of understanding eventually helping me at my college and work place and I feel the positive effects of that even now. Had I been in the ultra competitive environment, I would have given up on learning.
I stumbled on the talk by Malcolm Gladwell which had rekindled my memories while I kept nodding at many his points in the talk.
Top institutions always gets the brightest of the minds, there is no doubt in that. But increasingly these institutions are getting competitive that people in the lower percentile in these places may face too daunting a task to accomplish something even though they were the best among their their peers in the country. It will favour the ‘smart gets more smarter’ culture. So as mentioned in the talk it will be better if we recruit the toppers from multiple other institutions rather than focussing on getting talent from top institutions. This may apply to organizations which forms A-teams as well.
One of the common answers a developer gives when s/he notices a bug is that “it works in my machine”. This was so common and always boils down to the configuration difference between the testing environments and development environments. It is not so easy to keep the development and testing environments very similar but lots of those could be scripted and made automated such that it is an executable document. There are also lots of development hygiene practices that needs to be strictly adhered to avoid these kind of bugs.
Where could things go wrong?
There are many things that could go wrong, here are some of them in no particular order.
Poor version control – Either the code is not checked in(sometimes extra files locally modified for debugging) or the branching/merging is mismanaged.
Incorrect dependencies and libraries – The dependencies/libraries are manually copied to the servers. Example – copying some jar files to tomcat, could easily go out of version between different machines.
Testing only in debugging mode – When testing at the developer’s machine, developers have a tendency to run in debug, breakpoints in the code will give ample time for the application so that synchronous issues do not crop up during developer’s testing.
Not testing at all – This sounds silly, but when the pressure is high chances are that the code is committed without tests and then bugs have to appear to give time to finish the coding.
Incorrect environments and test data – Large projects have a tough time managing test data and environments, developers could be pointing to an outdated external environment or using only a narrow set of test data.
“Image courtesy of Grant Cochrane / FreeDigitalPhotos.net”.
If you want to walk fast, walk alone; if you want to walk far, walk together
When I talk about pair programming, I am confronted with things like return on investment, efficiency etc. The arguments which come against are with very simple programs and simple domains where it does not matter you pair to program or test drive the code. Beyond the fibonacci and measurement problems there are complex domains which people get involved to solve problems and pair programming helps there.
A good analogy is racing. Racing falls into circuit racing and rallies, if we note that circuit racing like Formula-1 or driving around in circles like in NASCAR has only one driver. These ones are repetitive with relatively very few unknowns and parameters for the driver to take care. The moment you know about the car condition and the track conditions and few laps taken then the driver’s mind is on autopilot. Rally unlike circuit racing has lots of challenges, we just roughly know the route and it could be riddled with lots of surprises and obstacles. There is no way that a driver without a co-driver (navigator) could win the race.
Programming at work is like rally driving, many of the examples which people take up for classroom sessions are similar to Formula-1 or NASCAR driving; which is the primary reason that most of them fail to see the potential benefits of pair programming. Depending on the nature of the task at hand we should be able to decide if we need work in pairs, group or alone to find a solution to the problem. Having a blanket rule to always program in pairs or avoid pair programming will force us to fit into one of the styles of work which may prove counter productive. Always failures are taken as strong examples than successes and if we fail in choosing the wrong approach, chances are high that the approach itself will be called a failure.
Image courtesy of patrisyu / FreeDigitalPhotos.net
Novi's 