From a70cadc4e542510ddb8fb07ffd01349db9ed19d1 Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Mon, 20 Jul 2020 13:05:12 -0300 Subject: [PATCH] How to kill developer productivity --- .../how-to-kill-developer-productivity.md | 63 +++++++++++++++++++ .../how-to-kill-developer-productivity.pt.md | 61 ++++++++++++++---- 2 files changed, 113 insertions(+), 11 deletions(-) create mode 100644 content/thoughts/how-to-kill-developer-productivity.md diff --git a/content/thoughts/how-to-kill-developer-productivity.md b/content/thoughts/how-to-kill-developer-productivity.md new file mode 100644 index 0000000..db4367b --- /dev/null +++ b/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. + + + +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. diff --git a/content/thoughts/how-to-kill-developer-productivity.pt.md b/content/thoughts/how-to-kill-developer-productivity.pt.md index c752bcc..3005908 100644 --- a/content/thoughts/how-to-kill-developer-productivity.pt.md +++ b/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 -produtividade. +Mas será que dá pra evitar interrupções mesmo? Não seria o "ping!" da +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 -uma pergunta. Você interrompe +Qual é a diferença entre essas e alguém pedindo ajuda? -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)