Talent, Performance and Involvement

Richard Feynman illustrated a point about involvement and productivity in the book “Surely you are joking My Feynman”. There was a big team of physicists working with every possible resource available to create the atomic bomb. As part of the project they were supposed to do tons of calculations and hence ¬†hired the best mathematicians in the country and placed them along with expensive computers to churn the necessary calculations out. Since the project was top secret, the mathematicians just received the problems; in spite of their level of expertise, the performance was found to be too mediocre.

Feynman took the tough decision of disclosing the project secret to enhance their productivity and convinced his superiors to help him to do so. He got a buy in and went ahead in explaining about the nature of the project and why it is necessary for them to come up with the bomb before any other country comes up with their own. As expected by him he found the productivity to increase many folds when they knew the end goal and its importance. His idea of treating them not just as a facility for mathematics but involve them to be as part of the project has paid rich dividends. He has observed that the mathematicians became very inventive to make use of the limited availability of the computers and took extreme care to iron out inefficiencies.

This is a real life incident and I have also heard many times about “difference between laying the bricks and building the cathedral”. In the software building world, the bigger picture never gets painted to the entire team and often the talent is overrated than how the job can be taken to the finish line. Unless every one in the team has a strong sense of ownership towards the goal, the peak performance never occurs. Getting the whole picture can also give an illusion of a time consuming activity, but benefits out weigh the time spent on that activity.

What would happen if the captain of the football team need to yell to every one the field on what to do next, wont it be a terrible team to play with?

James Bond doesn’t need manuals

Is it not cool to look like James Bond and attack every problem coming to us at runtime ? My answer is, it does not take us too far if we are not using the manuals for the tools we use unless it is extremely simple like a hammer and has only two steps to use it.

I some times wonder that if search engines had made people lazy to learn something from the grass roots up. This is not just an one off observation, I have known developers who thrive on search engines for everything from silly to complex ones. Of course, the search engines made a huge repository easily accessible to us; but not everything can be solved using them. If any one argues that they can get lots done just by intuition, analysis and net search then; why not we have technological marvels built by almost everyone.

We should not shy away from understanding the details or referring the manuals (It is not cool to act like James Bond). Only with a strong understanding of foundations we could go very far or tackle difficult situations with ease.

Traffic jam

While travelling to office, I always take the inroads instead of the arterial ones to avoid the rush. Most of times, the travel is smooth but if there is one small break in the flow, then the narrow roads gets crowded and jammed in a matter of seconds. I observed the attitude among the bikers who want to keep moving at any cost, has contributed to the sudden jams. If all those on the road obeyed the rules and stayed on the left side of the road, then the chaos could be avoided or the traffic would not have jammed.

This behavior gets carried over to the workplace as well. When we are too concerned about our own learning and improvisation, without our knowledge we tend to create a situation like the traffic jam where the onus is on us individuals to pull ourselves up. Everything depends on the individual to claw her way up anywhere (school, workplace, even queues); doing something against the rules and getting an edge is considered to be great talent.

This creates an environment where team work is most likely to be division of labour and the learning is always an individual’s responsibility. Awards, recognitions follow for individual brilliance; but what is not realized is that sum of all individual efforts is always lesser than the collective output. One of my peers highlighted this very well by relating this to a story Birds that flock, seem to learn faster

We should realize that our own learning is dependent how much the peers also learn; individual learning and moving up the ladder is just an illusion or is beneficial only for the individual and that too it comes with a great cost.

Games people play!

Games people play!

This is not about the politics but the real games people play in the office like Ping pong, video games (Wii, PC), board games etc. My general observation is that people who started playing a new game and started improvising on it rapidly, showed the same kind of approach towards coding. Apart from the improvisation part, games also provided a platform for people to get together in an informal setting which is not very easily available in the offices other than the coffee table or water cooler. The gaming zones are the breeding ground for people identify like minded ones and also develop camaraderie.

In the last few years I have worked with teams which plays a team game regularly (twice or thrice a week). I noticed many positives after people started playing team games.

  • People got more comfortable with each other and were quick to share feedback about something not going on fine, those feedbacks were also well received and often in a jovial way.
  • The teams were anxious to play almost every day which meant the work on the day had to be finished on time, this made the entire team focussed on becoming very efficient to save time for the evening.
  • The post game retrospectives were so great for some of the strategy games that people made use of that data to plan for next games, which is similar to having iteration retrospectives and planning for the next week. Though the same kind of passion was not evident in the workplace retrospective, I have seen some people referring to a game’s retrospective and set the tone for the team at work.
  • Overall, games reduced the stress levels for individuals who had been pre-occupied with work the entire day.

Apart from games I have observed music, code jams, craft and arts also help people in similar ways mentioned above. which means

All work and no play makes jack a dull boy. Play games at workplace!

The moment you observe

Sometime during the school days, I read about uncertainty principle. In simple terms it says if you need to know what a particle’s velocity or position is, then you need to shoot another particle at it and deduce the information from the reflected particle. When you do this, you are transferring some energy to the other particle and it uses that to change its velocity or position.

It was tempting for me to draw an interesting analogy to evaluation of people. Will it be the same way that once you evaluate, the data is invalid because the person would have learned what needs to be improved and that person is already improving on it. In my experience it is true for me. If I take part in a contest or attend an interview, irrespective of the outcome I have always learnt about where I stand and what I need to do next.

The critics play well in someone’s performance indirectly.¬†First they will say that the task is impossible. Then they will say it is possible, but not within the time frame. Then they will say it is possible to complete within the time frame, but will be with lots of problems. Then they will say there wont be any problems, but may not be able to integrate with the bigger solution. Then they will be a mute spectator after the successful completion of the task. What the critics do here is they communicate the problems and short comings to the individual who would not have a holistic view of the problem in hand. Thus critics are evaluating and providing immediate feedback but in a harsh manner, which can swing the outcome to either side (The receiver can be demoralized and not finish it or s/he can get excited to prove someone wrong and finish it). Whatever the outcome there will be a learning and the same person approaching a similar task next time will do it better.

This observation leads me to ask the question, is evaluation is very much necessary in any kind of work place? My answer from the experience would be that at least an environment is necessary in which the individual can observe oneself and identify the weak links. This environment could be in any form like mentorships, contests, debates. Sadly most of the workplaces stick to the traditional evaluation through perceptions from the people around which can proceed to outcomes like the critic example stated above. The data collected becomes obsolete as the individual would have changed by that point.

The moment you observe who you are, you are never going to be the same person from then on. We need to make sure we have enough of those moments to keep us improving ourselves instead of sticking to traditional evaluation practices.


Richard P Gabriel introduces the term “habitability” in the context of software development. It is about how good is the code to navigate easily and understand what changes to make. He relates this one directly to a person living in a building. If the building is simple, well lighted and ventilated then it is very habitable one but if a building has been designed to win a awards then it might not be an easy to live in place. Some thing like how many people will choose their place of work to be Taj Mahal.

This topic evoked a mixed response in me as I was very much inclined to aesthetics and reduced number of lines. This was definitely food for thought as I had never thought about me being a builder and want to build dwellings such a way that it would be a habitable one. The next few days went by pondering over the thoughts again and also discussing that analogy with some peers. We all felt that if we programmers consider ourselves to be builders (coders) then our aim should be long term life and habitability of what we build.

How to know if the code is habitable or keep it habitable? My inference so far has been that not to treat any software as a finished product. Developers should consider that the system will always be under repair and should keep it in a constant repairable state. The idea might not get along very well with everyone, but so far any thing which I have coded and considered complete has been changed within a short period of time. That means there is nothing called a finished product, which can be related to leaving a semi-finished building to both engineers and dwellers to start using and making changes at the same time.

The more habitable a codebase is, more is the sense of ownership and responsibility. I will finish with a snippet from the book

When people lose the sense of responsibility for the environment they live in, and realize they are mere cogs in someone else’s machine, how can they feel any sense of identification with the community, or any sense of purpose there?