You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
64 lines
2.7 KiB
64 lines
2.7 KiB
4 years ago
|
+++
|
||
|
|
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.
|
||
|
|
|
||
|
|
<!-- more -->
|
||
|
|
|
||
|
|
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.
|