Não seja esse tipo de Desenvolvedor
Lendo o excelente mangá Terra Formars (não se preocupem, sem spoilers), me deparei com uma situação curiosa: Um desenvolvedor no meio da história.
Wolf Redfield é um dos personagens, e vai ser basicamente isso que vou me resumir a dizer para não dar nenhum spoiler sobre o papel desempenhado pelo mesmo na trama.
O interessante é a história do personagem, algo que muitos desenvolvedores passam todos os dias, e algo, que como mostrado, tem um efeito devastador: necessidade de entregas cada vez mais rápidas e entregas cada vez maiores.
Estudantes de Stanford fizeram uma pesquisa para mensurar a produtividade com base no tempo que uma pessoa trabalha, e o resultado não foi nada diferente do que imaginamos:
Productivity during 60 hour weeks would be less than two-thirds that of what it was when 40 hour weeks were worked.
Traduzindo: A produtividade em uma jornada de 60h por semana será menor que dois terços da produtividade em 40h por semana.
Lembro-me de um emprego anterior em que (para variar) nossos prazos estavam atrasados. Qual foi a solução do chefe da equipe? Horas extra.
Trabalhamos de segunda a segunda, sem sábado, sem domingo, sem feriado. O resultado?
É engraçado, que quem quer que já tenha passado por algo parecido entende o significado da palavra automático. É como se estivéssemos lá em corpo, mas nossos pensamentos já não são mais tão lineares, nossa noção das coisas é comprometida também. Lembro de vezes e vezes que mesmo ao me deitar sonhar com o trabalho e com a resolução do problema que estava passando.
Fora o estresse pessoal, não é preciso dizer que a qualidade do código estava completamente comprometida.
Enquanto as pessoas continuarem a enxergar desenvolvedores como máquinas de replicação, a métrica de produtividade será a regras de três simples: Se um desenvolvedor produz X em 8h diárias, logo, produzirá X + X/2 em 12h. O que sabemos estar errado por uma série de outros fatores que interferem nesse cálculo.
Outro problema que somos acometidos está na cobrança excessiva de nós mesmos por resultados, uma síndrome conhecida por Síndrome do Impostor, e que pode ser entendida melhor neste post do Business Insider.
Qual então seria a solução? Ser ágil? Não exatamente, e como bem explicado por Edson Yanaga, o que deve ser buscado primeiro é a qualidade em detrimento da agilidade.
Acho interessante essa entrevista com o Edson, porque foi com ele que pela primeira vez ouvi falar do termo Artesão de Software.
Como artesão, é sabido que sua integridade física e mental interferem para a execução de suas obras, bem como que cada obra é diferente entre si, e mesmo que quiséssemos replicar uma delas, como desenvolvedores, mudaríamos coisas por conta dos novos conhecimentos e abstrações que estamos aprendendo e nos submetendo a cada dia.
Enfim… recomendo a leitura do capítulo 102, página 2 à 11… qualquer coisa além disso, fica por conta de vocês… qualquer semelhança com a (sua) realidade é mera coincidência.
