The Importance of Breathing Space in Software Development
Writing code is a pretty thought intensive activity. Breaking down the individual steps, reviewing API documentation, testing and debugging as you go. We switch between some pretty intensive tasks. The satisfaction when the problem is solved is indeed thrilling. Any factors that impede these steps will prevent engineers yielding the desired results.
I have seen first hand how work environment can affect developer productivity. Engineers in our environment are still using noise cancelling headphones to ensure the ability to become engrossed in their work. The state of their calendar is another influencing factor that should be explored.
A recent catch up with a colleague got me thinking about space. They were very frank about how extending free time in their calendar caused their productivity to thrive. To mark my thirtieth blog post, I reflect on how space has contributed to my own productivity over the course of my career, and how my tactics to focus on deliverables have evolved.
A Sky Full of Stars
Back in the good ol’ days, the ratio of scheduled meetings to space in my calendar generally favoured the latter. Measurement of my productivity was the development of features. In the majority of my early projects, meetings were reserved for key updates only.
Scheduled meetings are a big productivity killer when the time compared to unscheduled time tips the scales. Especially if there are many with small gaps between them. Keeping meetings to a minimum is required for developer productivity to thrive.
I’ve seen differing attitudes to the number of meetings dictated by Agile methodologies such as Scrum. Some consider the number of meetings too frequent, or a surveillance mechanism to monitor developers. I recently reflected on different experiences, where under a waterfall model I was subjected to a myriad of update meetings that impeded my own deadlines. This is a clear example of how such a lack of space to code affects developer deadlines. Becoming engrossed in a coding tasks only to switch out thirty minutes later will affect the quality of any code submitted for review.
Supermassive Black Hole
Minimum meetings not only produces programmer productivity. In my early career, it allowed me to build a reputation for reliable delivery. It also granted me the opportunity to develop expert knowledge in the technologies I used daily.
Once in a position of knowledge, you are faced with two options. The first is to keep your cards close to your chest to ensure a dominant position. The second is to disseminate that knowledge among colleagues to ensure a long term strategy. While the latter is always the best option, it has presented me with challenges on an old high profile project.
Providing training is not always a scheduled classroom activity. The majority of training we receive is as part of the daily grind. More commonly it is ad-hoc conversations as developers encounter issues with their own deliverables. As an oracle of expertise you need to embrace that providing on-the-job training is a valid pursuit.
Good managers will protect inexperienced engineers through use of office hours, where it makes sense. Developers will not opt for such a solution. They will aim to please as their own individual items start to suffer. Specific knowledge sharing meetings have been the right call in half of the situations that I’ve encountered. Then again, spending all day training and all night coding is, in hindsight, never the right call!
Transitions to senior engineer and manager makes space harder to find. Measurement of your success is no longer dependent on the code you write, but the features delivered by others. Quickly you become a facilitator, rather than a technical contributor.
This is certainly true in my case. I did touch code this week. Shock horror! However, my commits are often small tidy ups to improve software quality. The ratio of meetings to space very much lies in the former camp now.
Dedicated thinking time, be it for code, slides or just getting stuff done, now has to be scheduled for me. Fake calendar entries are a great mechanism to allow me to achieve that.
The lack of gaps in my calendar are vastly becoming an ongoing joke in the office. To be productive I also need space to support and guide developers when they need it. All my hours need to be office hours. Not just a couple of dedicated sessions per week. No matter how senior you get, you need space in your calendar to get the job done. The question becomes whether it is explicitly scheduled or available freely.
Thanks for reading!