How to kill developer productivity

content/thoughts/how-to-kill-developer-productivity.md

@@ -0,0 +1,63 @@
++++
+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.

content/thoughts/how-to-kill-developer-productivity.pt.md

@@ -1,9 +1,10 @@
 +++
 title = "Como Matar a Produtividade de Desenvolvedores"
-date = 2020-07-13
+date = 2020-07-20
 
 [taxonomies]
-tags = [""]
+tags = ["desenvolvedores", "programação", "ti", "onboarding", 
+"fluxo de dados", "arquitetura", "produtividade"]
 +++
 
 Existem várias formas de não matar a produtividade de desenvolvedores num
@@ -16,21 +17,59 @@ desenvolvedores", que diz exatamente o que todos os artigos sobre como não
 matar a produtividade de desenvolvedores diz: Basicamente "Evite
 interrupções".
 
-A questão que ninguém levanta é porque interromper um desenvolvedor mata a sua
+Mas será que dá pra evitar interrupções mesmo? Não seria o "ping!" da
-produtividade. 
+cafeteira uma interrupção? Não seria a bexiga cheia uma interrupção? Não seria
+a campainha avisando que chegou a encomenda e/ou a tele-entrega uma
+interrupção?
 
-Imagine que você, desenvolvedor, está escrevendo código e vem alguém lhe fazer
+Qual é a diferença entre essas e alguém pedindo ajuda?
-uma pergunta. Você interrompe
 
-Onboarding
+E fazer menos reuniões? Por que? Porque ninguém se liga de fazer uma pauta de
+reunião para ter o que decidir? Ou será que é porque os desenvolvedores de
+frontend não dão a mínima para os problemas que o pessoal de backend está
+enfrentando e vice-versa?
 
-Entendendo o propósito da empresa
+Seria uma reunião marcada com uma semana de antecedência uma "interrupção"?
 
-Entendendo o propósito do produto para a empresa
+Eu não consigo ver que as interrupções em si são o problema. Imaginem o
+seguinte:
 
-Tendo tempo e discutindo soluções para o produto da empresa
+Essa pessoa passou por um onboarding quando entrou na empresa, e foi
+apresentado ao propósito da mesma, foi apresentado ao produto que a empresa
+vende e como o produto funciona, foi apresentada à arquitetura do sistema, foi
+explicado o motivo de cada solução aplicada, foi dado tempo para discutir
+outras soluções com seus pares, não foi colocado contra a parede para explicar
+cada minuto de trabalho do seu dia.
 
-Interrupções não afetam mais o resultado.
+Dado isso, vocês conseguem imaginar que alguém fazendo uma pergunta sobre
+alguma parte do sistema enquanto quem está programando está no meio da função
+de frobnicar[^1] foo? Talvez perca algum tempo para ver em qual ponto parou,
+mas como a solução já foi discutida, e já se sabe o propósito da
+funcionalidade sendo introduzida, a interrupção vai afetar muito pouco o
+resultado final.
+
+Infelizmente, na área de TI, passamos muito tempo sendo vistos como "máquinas"
+e técnicas de produção são aplicadas diretamente sem considerar que somos
+pessoas (ou vocês acham que "kanban" nasceu no meio da TI mesmo e não dentro
+da fábrica da Toyota?). 
+
+Uma máquina parada é dinheiro perdido. Parar a produção para manutenção
+preventiva, sem que a máquina esteja realmente quebrada, tendo desmontar a
+mesma e verificar cada uma das partes, é dinheiro perdido.
+
+E, infelizmente, quando um programador não está "programando", é visto como
+dinheiro perdido. E por isso coisas básicas, como explicar o porque o sistema
+existe, qual a ideia do fluxo de dados dentro do mesmo, deixando que
+programadores parem e discutam soluções e coisas do tipo são completamente
+ignoradas: Porque a "máquina" não está produzindo.
+
+E, quando é preciso parar a produção, por qualquer motivo, a produtividade vai
+lá pra baixo.
+
+---
+
+[^1]: Eu não se tem alguma forma melhor de traduzir
+  [frobnicate](https://www.techopedia.com/definition/27996/frobnicate)
 
 
 <!--