2.7 KiB
+++ title = "How to Kill Developer Productivity" date = 2020-07-20
[taxonomies] tags = ["developers", "productivity", "programming", "ti", "onboarding", "data flow", "architecture"] +++
There are several ways to not kill developer productivity in a project. Unfortunately, the real causes are never discussed.
Recently I read another post about "how to not kill your developer productivity", that says exactly what every other post about it says: Basically, "do not interrupt".
But can we really avoid interruptions? Isn't the "ping!" from the coffee machine an interruption? Isn't a full bladder an interruption? Isn't the front door bell ringing when a package and/or food delivery an interruption?
What's the difference between those interruptions and someone asking something?
And do less meetings? Why? Is it because nobody cares enough to write a meeting agenda to point what needs to be decided? Or maybe 'cause the frontend developers don't care enough about the problems the backend developers are facing and vice-versa?
Would a meeting scheduled a week in advance an "interruption"?
I can't see how interruptions can be a problem. Imagine this:
This developer went though an onboarding when they joined the company, and they were shown the purpose of the company, they were shown the product the company sells and how it works, there were shown the product architecture, they were explained the reasons behind every solution applied, they were given time to discuss other solutions with their pairs, they were not put on a corner to explain every minute of their working day.
With that, can you imagine that someone making a question about some part of the system while whoever is coding is in the middle of a function to frobnicate[^1] foo? Maybe they will need a bit time to find where they stopped, but as the solution was already discussed, and they know the purpose of the solution they are working, the interruption would do very little in their productivity.
Unfortunately, in IT, we are seen as "machines" and most manufacturing techniques are applied directly without considering that we are people (or do you think "kanban" was born in IT and not inside the Toyota manufacturing plant?).
A stopped machine is wasted money. Stopping production for preventive maintenance, without the machine being really broken, having to take it and check every part, is wasted money.
And, unfortunately, when a developer is not "developing", they are seen as wasted money. And that's why simple stuff, like explaining why a system exists, what is the idea of the data flow inside the system and things like that are completely ignored: 'Cause the "machine" is not producing anything.
And that's why, when the production is halted, productivity goes down.