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!

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?