‘Can’t be fucked’: a causa subestimada da dívida técnica
(jesseduffield.com)- Habilidade de desenvolvimento não é determinada apenas por conhecimento; mesmo sabendo o que precisa ser feito, adiar testes, refatoração e a criação de casos reproduzíveis por falta de motivação faz a dívida técnica se acumular
- Bons desenvolvedores investigam e corrigem flaky tests, transformam bugs encontrados em tickets ou os corrigem na hora e, quando uma nova funcionalidade não se encaixa bem no código existente, fazem refatoração antes
- Máximas como “premature optimisation”, “duplication is better than the wrong abstraction” e “Keep It Simple, Stupid” são úteis ao lidar com restrições reais, mas também podem ser usadas para esconder o simples fato de não estar a fim
- No Lazygit, foi criado ao longo de vários meses um sistema de testes end-to-end e seu efeito foi claramente sentido, mas no Lazydocker os mesmos testes não foram adicionados, e também foram adiados o pedido de um repositório mínimo reproduzível e a refatoração de uma God Struct
- Mesmo quando não há energia para escrever código perfeito, expor com honestidade o que está faltando facilita avaliar os padrões de manutenção e a prioridade do próximo trabalho
Falta de motivação que cria dívida técnica
- “Can’t Be Fucked” é uma gíria australiana que significa não querer fazer algo ou estar sem energia e motivação para isso
- Eu achava que aprender muito conhecimento de desenvolvimento me tornaria um programador melhor, mas, na prática, os desenvolvedores que passei a admirar são pessoas que, além de conhecimento, têm consistência e dedicação
- Bons desenvolvedores sabem e agem com base no fato de que lidar direito com um problema enquanto ele ainda é pequeno economiza tempo no longo prazo
- se há um flaky test, investigam e corrigem
- se encontram um bug em produção, criam um ticket ou corrigem imediatamente
- se uma nova funcionalidade não se encaixa no código existente, preferem refatorar antes em vez de forçar o encaixe
- se necessário, descem até as camadas mais baixas da stack para identificar a causa
- Esses desenvolvedores também sabem distinguir quando “good enough” é a escolha certa, quando é preciso reduzir o escopo e quando é melhor aprender mais sobre o domínio antes de mudar a arquitetura
- O problema é que, independentemente desse tipo de julgamento, em certos momentos a falta de motivação se torna uma restrição mais forte do que as restrições externas do projeto
Ser honesto sem se esconder atrás de máximas
- O sistema de testes end-to-end do Lazygit foi construído ao longo de vários meses em tempo parcial, depois evitou muitas regressões, e há convicção de que hoje seria mais difícil adicioná-lo
- ainda assim, o motivo para não adicionar testes end-to-end ao Lazydocker foi simplesmente CBF
- Depois de abrir uma issue em outro repositório open source, foi pedido um repositório Git mínimo reproduzível, mas ele ainda não foi criado; além disso, uma grande refatoração iniciada há mais de um ano também não foi concluída, então muito código ainda permanece em uma God Struct
- Não se afirma com certeza se isso é burnout, falta de mindset de crescimento ou uma questão de personalidade
- Saber da dor de longo prazo da dívida técnica pode servir como motivação para evitar isso, mas saber e realmente agir da forma correta são coisas diferentes
- Frases como “testes demais geram custo de manutenção”, “vou refatorar depois de ver o impacto de outras funcionalidades”, “premature optimisation” e “cut scope aggressively” podem ser usadas tanto para bons julgamentos quanto como desculpa
- Se você admitir que uma parte do código ou de um pull request ficou aquém por preguiça, o revisor pode julgar diretamente se isso ainda atende ao padrão ou se é melhor gastar tempo na próxima tarefa
- Quando o estado de CBF chegar, em vez de desanimar, seja honesto; se você vem correndo a 100% por tempo demais, talvez precise de férias
1 comentários
Opiniões no Hacker News
Uma parte considerável do CBF pode ser explicada apenas por remuneração e incentivos
Quando entrei na empresa atual, eu estava cheio de energia: consertava builds quebrados, fazia testes abandonados passarem, refatorava pipelines de deploy e encontrava e corrigia a causa-raiz de bugs
Mas, com o tempo, em vez de me tomarem como exemplo, as pessoas passaram a pensar “de qualquer forma, aquela pessoa vai consertar”, e percebi que fazer trabalho braçal só trazia mais trabalho braçal
Em contrapartida, quem fazia as coisas de qualquer jeito, como um hack, embalava bem os resultados e era promovido primeiro; quando os problemas estouravam em operação, já tinha passado para outro projeto
O júnior que ajudo por algumas horas toda semana ganha mais do que eu graças à contratação apressada de 2022, e eu recebi avaliação de “acima das expectativas” em 2023, mas nem aumento tive porque eram tempos difíceis
No fim, do ponto de vista de quem trabalha por salário, se o esforço não é recompensado — ou, pior, acaba punido —, não é estranho a motivação desaparecer
Vá embora e encontre o lugar onde você deve estar e as suas pessoas
Quando há reconhecimento, o custo da motivação cai bastante, e as pessoas gostam de recompensas
As pessoas jogam milhares de horas porque o custo da motivação é muito baixo
Não estou dizendo para gamificar o trabalho, mas, como defender a si mesmo pode parecer mesquinho, os colegas deveriam reconhecer uns aos outros
Dívidas técnicas também têm taxas de juros diferentes, e a competência está em deixar as dívidas de 0% de lado e pagar primeiro as de juros altos
Ao instalar o piso de um armário no porão, faltou material e não consegui cobrir completamente a parte de trás; visualmente fica meio feio, mas está sempre escondido por caixas e não afeta nada mesmo morando ali por décadas. Isso é dívida técnica de 0%
Por outro lado, se a calha entope, com o passar do tempo o custo cresce por infiltração no porão ou porque a calha se solta; essa é uma dívida que rende juros. Uma escada de entrada quebrada, que faz as pessoas tropeçarem o tempo todo, também é uma dívida de juros altos que precisa ser corrigida rápido
Em engenharia, um problema de arquitetura que atrasa o desenvolvimento de todos os recursos pode ser uma dívida de juros altos, enquanto código bagunçado ou TODOs em um arquivo quase nunca tocado podem, na prática, ser uma dívida de juros baixos
Engenheiros, por um lado, deixam trabalhos mais importantes passarem enquanto corrigem dívidas de 0%; por outro, dizem que “produto/liderança não apoia a resolução de dívida técnica”, mas muitas vezes não conseguem explicar bem o custo real e a taxa de juros
De cima a baixo, só o que é novo e brilhante recebe atenção; manter o que já existe não desperta interesse
Mesmo que você convença as pessoas da importância, a diretoria apenas concorda que aquilo é necessário, mas isso não tem nenhum impacto positivo na avaliação de desempenho. Se der errado, eu é que fico com a tarefa que só rende bronca
Se a base de código é bagunçada e inconsistente, mesmo em arquivos escondidos, os desenvolvedores ficam menos inclinados a implementar novos recursos com consistência e qualidade
Vira “de qualquer forma, este módulo inteiro precisa ser reescrito, então vamos colocar isso aqui de qualquer jeito por enquanto e arrumar depois”
https://en.wikipedia.org/wiki/Broken_windows_theory
É uma extensão natural da expressão dívida técnica e comunica o ponto principal de forma concisa, então dá vontade de usá-la na empresa
Por isso, culpar o desenvolvedor dizendo que “não explicou o custo real” é uma desculpa um pouco fácil
Se surge um problema visível para o cliente, há chance de ser resolvido; se é apenas um problema interno, essa chance cai muito
Quando se usa seriamente uma expressão como “dívida técnica de 0%”, talvez seja o caso de repensar se o conceito não está mal definido
Dívida precisa ser paga ou gerar juros; se não há nada disso, não é dívida
Da próxima vez, vão chamar também uma funcionalidade ainda não implementada de dívida técnica de 0%
Não sou fã do Steve Jobs, mas sempre gostei das citações dele sobre artesanato e atenção aos detalhes
“Quando você é um marceneiro fazendo uma bela cômoda, não vai usar compensado na parte de trás só porque ela fica voltada para a parede e ninguém vai ver. Você sabe que ela está lá, então vai usar uma madeira bonita também na parte de trás. Para dormir bem à noite, a estética e a qualidade precisam ir até o fim”
Acho que o software como um todo sofre muito com a atitude de “cumpri tecnicamente os requisitos no limite, então meu trabalho acabou”
https://www.goodreads.com/quotes/445621-when-you-re-a-carpen...
Há muitas histórias de que ele se recusava a lançar hardware e software abaixo do padrão e demitia pessoas que não conseguiam construir conforme as especificações corretas
Já a maioria trabalha sob uma liderança exatamente oposta: “termine o mais rápido possível para vender mais e ajuste o que for necessário, de qualquer jeito, só para passar nos testes de qualidade”
Um marceneiro de verdade precisa ser prático e eficiente em custo para competir no mercado
Se ele usar madeira cara ou gastar tempo em lugares que ninguém vê, a vazão cai e o custo para o cliente sobe desnecessariamente
Mesmo para artesãos, tempo e dinheiro são finitos, e o tempo gasto em trabalho invisível é tempo que não foi gasto em algo mais visível
Num mercado em que marceneiros de habilidade equivalente produzem mais a um custo menor, esse marceneiro seria deixado para trás
Acho que o problema em software é mais uma questão de incentivos do que de atitude. Gosto de fazer um bom trabalho e de usar software bom, mas as horas do dia são limitadas, e não vou abrir mão do meu tempo pessoal em nome de um benefício de negócio do qual eu não vou colher o retorno
Além disso, quando começo uma refatoração, dá para prever racionalmente que, de repente, vai aparecer uma funcionalidade obrigatória que precisa ficar pronta ainda hoje
Mesmo que a diretoria concorde em resolver a dívida técnica, no fim ela não se resolve se você não inflar as estimativas de prazo e refatorar no lugar do trabalho que foi designado
Em um livro, um personagem ferreiro conserta uma peça de carroça e diz: “sempre faça o melhor que você puder”
Quando alguém diz “mas essa peça fica embaixo, ninguém vai ver”, ele responde: “mas eu sei que ela está lá. Se eu não fizer tão bem quanto posso, vou me sentir envergonhado toda vez que essa carroça passar. E vou ver essa carroça todos os dias”
https://news.ycombinator.com/item?id=28086786
Se você escreve testes unitários/de integração/de ponta a ponta decentes e, ao encontrar código bagunçado, refatora em vez de empilhar mais coisa em cima, sua produtividade no papel fica menor do que a do colega que continua “resolvendo” tickets
Isso é especialmente grave em organizações “totalmente ágeis” que não levam em conta refatoração nem limpeza de qualidade de código
A Apple foi uma exceção, pelo menos em algum momento. O preço dos produtos era alto, os clientes esperavam qualidade, a empresa tinha margens para tornar isso possível e, acima de tudo, havia Steve Jobs, que tinha olho para a experiência
No extremo oposto, há exemplos como a Juicero, que criou uma máquina para espremer pacotes de suco com engenharia de nível aeroespacial
Durante a maior parte da minha carreira, eu limpava dívida técnica quando via uma oportunidade, mesmo sem pedirem. Era porque eu tinha apego e senso de propriedade
Agora, num ambiente com microgerenciamento baseado em Jira e sem autonomia, não faço nada além do estritamente necessário
Antes, o esforço voluntário era uma parte central da minha carreira, mas agora o custo burocrático e social de gerenciamento de projeto para qualquer mudança ficou tão alto que simplesmente não vale a pena
Não me importo se o produto vai dar certo no longo prazo ou se a empresa vai ter sucesso; só vou fechando tickets até encontrar o próximo emprego
Por outro lado, se você segue a ideia de “não peça permissão para refatorar, apenas faça”, leva bronca por abrir um PR que não segue os padrões existentes do repositório
Vira um “está bom, mas precisamos discutir com a equipe inteira”
Então a dívida técnica continua crescendo, leva meses para mesclar um único PR, e os testes ficam tão instáveis que parecem uma máquina caça-níqueis de cassino em que você aperta o botão de reiniciar até compilar. Ágil é realmente maravilhoso
Em um ambiente que só age de forma reativa, agir de forma proativa nunca foi recompensado na minha experiência
Quando você identifica um problema, naquele instante ele vira problema seu; e, se ele estourar de novo depois, a culpa é sua por ter estragado algo
PMs e a camada de gestão sempre trabalham com pressupostos negativos, então não vale a pena
Especialmente porque algumas pessoas acham que têm o caminho iluminado para chegar a um código bom, mas, na prática, muitas vezes estão escolhendo o caminho mais fácil em vez de ler e entender o código existente
Há alguns mal-entendidos nos comentários aqui
Para um programador individual, motivação, esforço, energia, força de vontade — chame como quiser — são recursos finitos, e isso é totalmente normal
A vantagem de uma organização é conseguir realizar mais do que um programador individual, mas, no processo de conectar vários elementos, surgem lacunas e o trabalho cai por elas
Pessoas pagas para operar a organização, não para fazer trabalho técnico, como COO, RH e gerentes de produto, deveriam criar processos para lidar com essas lacunas
Só que cada vez mais empresas empurram esse trabalho para engenheiros e designers individuais, porque é difícil medi-lo por lucro e prejuízo ou por OKRs
A empresa sofre e os engenheiros entram em burnout. Há um limite para ficar cuidando continuamente de pequenos tickets e tarefas que caem pelas frestas sem remuneração adicional
Há um clima bem negativo aqui, mas fiquei feliz porque este texto descreve exatamente o que sinto no dia a dia
Quando vejo a ótima cobertura de testes e as refatorações com princípios de projetos open source, em alguns dias eu também entro no modo “vamos fazer direito” e consigo produzir muita coisa bem-feita
Aí, em algum dia, essa energia desaparece e, como o autor, eu também fico no CBF. Pulo testes, acrescento código em lugares que sei que não são bons e abro caminhos pelos quais meu eu do futuro não vai me agradecer
Vejo isso acontecendo em tempo real, mas não tenho energia nem motivação para voltar ao modo inspirado de “vamos fazer direito”
Tudo isso também acontece em software que eu mesmo crio e vendo
Fiquei impressionado ao ver que o autor é quem criou o Lazygit, e eu gosto muito do lazygit. Na minha cabeça, ele sempre entra na categoria de mantenedores open source que conseguem fazer as coisas direito
Parece que nós dois temos experiências parecidas com motivação
Fico feliz que você goste do lazygit, e espero conseguir manter essa boa avaliação daqui para frente
A maioria das decisões é, na verdade, inconsciente
O estado de “não consigo mesmo fazer isso” significa que algum circuito do cérebro concluiu que coisas como refatoração ou testes não valem a pena
Esse circuito pode estar certo. Porque, de forma objetiva e geral, muitas vezes a recompensa pelo esforço realmente não é suficiente
Por exemplo, se você passou dois meses criando testes de ponta a ponta e, nos seis meses seguintes, economizou três semanas com depuração etc., a conta não fecha
Existem dois extremos comuns. De um lado, o negócio força os engenheiros a aceitar dívida técnica que é um trade-off realmente ruim; de outro, engenheiros às vezes gastam tempo com uma estruturação ideal e enormes pacotes de testes que no fim não serão recompensados
Parte disso também acontece porque alguém teme que outra pessoa encontre uma estrutura de código melhor ou testes adicionais e o avalie por isso
Se sinto que estou entregando algo abaixo do meu padrão, mesmo que esse padrão seja mais alto do que a necessidade real, isso prejudica muito a moral e a motivação
Vejo o maior problema da dívida técnica justamente no fato de ela destruir a moral
No Lazygit, passei alguns meses construindo parcialmente um sistema de testes de ponta a ponta, e penso todos os dias nas regressões que esse sistema impediu e em como seria muito mais difícil adicioná-lo agora
Sei claramente que valeu a pena, mas por que não adicionei testes de ponta a ponta ao Lazydocker? Simplesmente porque estou em CBF
Testes de ponta a ponta são infernalmente chatos e dão um trabalho enorme quando não há boas ferramentas. Precisamos de frameworks básicos melhores, que sejam fáceis de encaixar
Com sorte, essa pessoa ainda terá tempo para cuidar dos testes de integração
Acho que, nesta sociedade e neste mundo, a forma como as pessoas veem a preguiça é, em grande parte, absurda
É como se fosse preciso trabalhar 40 horas por semana durante décadas e só descansar depois de reencarnar; e ainda querem falar de preguiça?
A energia mental é extraída para produzir a riqueza dos outros, e, quando você fica velho demais para fazer qualquer coisa, é descartado
Toda semana aparece mais uma funcionalidade que deveria ter ficado pronta ontem, então não sei quando é que deveríamos corrigir a dívida técnica. No tempo livre? Nem sei por que isso deveria continuar existindo, para começo de conversa
Em um projeto maduro de uma equipe pequena, todos os tickets restantes eram bugs difíceis que ninguém queria pegar
Mesmo investindo dias, você não tinha nada para mostrar além de riscar alguns itens da lista de suspeitas; e eram bugs do tipo que, se você riscasse algo errado, voltavam uma semana depois
Todos os dias eu precisava despejar toda a minha energia mental nesses tickets e, quando finalmente conseguia resolver um bug à base de café ou estimulantes, enviava o código, fechava o ticket e ia direto para o próximo
Não havia descanso de verdade; só dava para descansar a cabeça por um instante no começo do próximo ticket, quando ninguém esperava resultados imediatos
Mas, depois de alguns dias, as pessoas perguntavam o que eu tinha feito até então, perguntavam se eu estava travado e, quando eu na verdade mal tinha começado, precisava inventar pequenas mentiras para justificar o atraso
No momento em que eu mais precisava descansar, eu já estava mais atrasado e as pessoas já tinham percebido, então até tirar férias não parecia uma opção
Agora trabalho de 20 a 30 horas por semana, às vezes menos, em uma organização sem fins lucrativos de engenharia; o dinheiro é apertado, mas trabalhar mais é simplesmente impossível
Tenho um pouco de tempo para projetos paralelos e para andar de bicicleta, e nunca trabalho nos fins de semana. Também não trabalho às terças, salvo casos especiais
Eu amo de verdade meu emprego atual, é meu emprego dos sonhos, mas não vale a pena me matar por ele. A vida é uma só, e vou vivê-la amando direito
Hoje terminei um trabalho de 1 mês que foi praticamente uma reescrita completa do firmware de um dispositivo da empresa, mas que inicialmente tinha sido estimado como uma tarefa de 1 semana para corrigir um pequeno bug em parte do módulo de comunicação
Felizmente tenho um PM e colegas tranquilos, que reconheceram que agora podemos de fato corrigir bugs legados de 8 anos nesse código
Ainda faltam testes de casos extremos e ajustes adicionais, mas, como a atualização remota de código funciona, já podemos despachar o dispositivo
Aqui, “mentir” é quase uma recomendação de comportamento. Originalmente comecei o comentário com “minta”, mas houve mal-entendido
Também é para mostrar aos colegas que é importante ter tempo para pensar nas implicações mais amplas do trabalho
E também para contribuir com seus pensamentos em comunidades como esta, comer chocolate, passear com o cachorro se possível e ouvir palestras de Alan Watts no YouTube
Como alguém que tenta fazer as coisas direito, acho que o mais importante na dívida técnica é o rastreamento
Leva apenas alguns minutos para transformar um problema visível em uma tarefa, e essa tarefa passa a ser dívida técnica
A liderança tem a responsabilidade de priorizar a dívida técnica e reduzir continuamente uma certa quantidade dela
Às vezes, também se reduz dívida técnica ao decidir não fazer alguma coisa, e isso é totalmente aceitável
O objetivo do processo de registrar, revisar e tratar é dar uma segunda oportunidade de olhar para problemas que são “não agora”
A primeira intuição pode ter sido errada, e X talvez não fosse necessário; ou, ao contrário, ela pode ter sido correta por motivos que não vieram à mente na época
Acima de tudo, algumas coisas do tipo “não dá para fazer agora” são realmente importantes. Se você não dedicar tempo para examiná-las, não vai encontrá-las