I was speaking to a tech lead who was inspired by Dan Pink’s drive and motivation video. This person was speaking great lengths about how to motivate team members, how to set them goals etc and also went on to say that only if this person’s managers showed same consideration and handover more autonomy, then there are so many more things that can be done.

Below is the link for the nice presentation by Dan Pink, about his work on Drive

I asked a few questions to understand what kind of autonomy was working for this tech lead. The team size was around 8 with a mix of Developers, QA and BA. The team members were given a free hand on when to take a day off, go on vacation, flexible timings etc. The flexibility in working and taking a time off is not directly related to autonomy so I asked my favourite question next.

Given your team size is small, what is your version control process? The answer was that everyone works on their own branches, they will then raise a pull request to the tech lead, the tech lead will review the piece of work, some back and forth happens before it can be merged to the master. The tech lead controls the merge to master and it is a privilege to commit to master.

Where is the autonomy in this process? Code for developers is like a habitat, they should feel connected and own the place they are considering it as their habitat. By putting a very strong gated process that too in a small team is removing the autonomy away from the members. Will members be connected and own the code they are developing or is it just that they are following their tech lead says?

Then the question arises on ‘how to ensure quality’; in our teams we never gate someone’s commits as a merge request/pull request is not the only safety check we have in place. We have a huddle every morning and people demonstrate what they have coded & committed to main along with any observations they have on other’s code. This is repeated every day and this mob review works a lot better than a gating PR review because the learning as a group is much stronger and less hierarchical. This activity also enforces the collective ownership and every individual takes up the challenge of living upto the expectations. The only catch is, it has to be moderated well in the initial days before the new found inertia can take over and run without the chaperone.

I started following this style after reading the chapter “Habitability and Piecemeal Growth” in the book Patterns of software architecture by Richard Gabriel. Autonomy is not just about working from home, flexible timings or casual holidays, it is about the ability to own things at grass roots level.

In some professional settings, when I had to meet new people; often during the greeting people say “Hi, I am ABC and I am the <<insert fancy title>>” and look back at me, while my responsibilities were at similar level I did not have a fancy title. I have always been associated with companies which did not go for fancy titles and it has been a downhill when there needs to be a peer to peer conversation but it ends up in a hierarchical communication.

This has a big domino effect and people want bigger and fancier titles much earlier in their life. My dad retired as an engineer and when I looked into his career path, he was not called an engineer until he spent 5-6 years as a technical assistant to the engineer, another 5 years as deputy engineer and finally an engineer when he had enough experience and wisdom to handle a lot of things. Now we started calling people who connect cables to the modem as service engineers.

Different people are motivated by different things, for a few people status is one of them but by succumbing to that need we put a lot of others at a disadvantage because; now every one has to play the game to make sure there is proper titles associated to them based on the years of experience or the volume of things they are handling.

Looking forward to a future where titles do not matter that much and we stick only the basic ones. We should not have inflated titles to the point where people are judging someone’s worth by the title they carry.

I have heard from my fellow programmers about cooking, the more they are able to handle abstract problems at work, the better they are at cooking. Cooking here in the context is not just about making a tasty dish, but cooking a meal that is tasty, healthy in the long run and maintaining the kitchen well to keep it ready for subsequent meals.

A majority of the us just concentrate on a single (or two or three) nice meal in the taste and quantity aspect as great cooking, but do not see it as a sustainable thing that we will do it on and on. Why I drew parallels with programming is what I learnt at work while coding that was applicable in the kitchen, following are a few.

  • Always leave the code better than how you found it, (Campsite rule).
    • Leave the kitchen in a condition that you can cook your next meal immediately. Don’t leave it in a mess for someone else to cleanup.
  • Abstractions help you to concentrate on things as a whole, instead of the simple sum of the parts. You know how things work at ground level as well as how it looks when seen from high above.
    • This concept is key to mix and match, new recipes can be born and improvisations based on the abstract taste. Substituting Almonds for coconut, ripe tomato for tamarind. Understanding how things blend with each other makes a good cook.
  • Lessening feedback time, fail fast.
    • Taste well if possible involve another person when trying new dishes. This will help to avoid throwing away a dish cooked for two hours.
  • Use of automations for mundane repeatable things.
    • Use electronic devices with timers for mundane activities like boiling milk, water, rice cooking, grilling, baking, roasting, washing so that mind is free to concentrate on things that need attention. Cleaning spilt hot milk due to forgetfulness sometimes takes as much time as cooking a meal.
  • Acknowledge when you don’t know and reach out for expert opinion even if the manual says it to do obvious things.
    • Whatever we read about cooking and then scientifically do it, there are still many artistic aspects that needs to be done to be a good cook. Listen to people who cook well and do it as they say.
  • There is a routine that helps, keep it sustainable so that you will come back next day with enough energy to go through that day again and again.
    • You can plan a great feast, but then you should give a break to recover to your normal rhythm of running the kitchen. Over time you will learn to cook a lot in a less amount of time.
  • Shortcuts give you that edge, but that is an easy way out that will lead you back into mess again.
    • It is very tempting to use taste enhancers, chemical preservatives etc to get most out of our cooking but it will be damaging in the longer run to our health

The reverse also is true, those who manage to cook well, will be good programmers.