📎 Webclip
[Off-Topic] Net Negative Producing Programmer
O texto sustenta que um NNPP não é apenas mais lento, mas alguém que empurra a equipe para trás ao comprometer a manutenibilidade e a extensibilidade do software. A partir disso, defende que gerentes precisam reconhecer esse tipo de comportamento e agir com rapidez.
Fichamento#
- Um programador ruim pode causar mais prejuízo ao projeto do que um programador melhor pode compensar com produtividade.
- O problema aparece como dívida técnica e como perda de manutenibilidade e extensibilidade.
- É difícil identificar um programador ruim, especialmente quando o gerente também não é programador.
- O texto distingue “codificadores”, que só executam o que mandam, de “desenvolvedores”, que estudam, aprendem e tratam software como um trabalho que exige dedicação constante.
- Toda equipe de desenvolvimento precisa de líderes técnicos seniores.
- O texto recomenda procurar bons programadores em comunidades open source e desconfiar de quem se apoia primeiro em certificados.
- Se a equipe inteira for formada por NNPPs, a saída proposta é dissolver a equipe.
- O texto alerta contra o custo perdido e diz que pode ser mais barato recomeçar do que sustentar uma equipe ruim.
- Há crítica ao foco em resultado imediato e elogio a soluções que preservem a qualidade no longo prazo.
- O cowboy é descrito como alguém que resolve problemas que ele mesmo criou.
- Sinais de alerta incluem código escondido, conhecimento concentrado em uma pessoa e dificuldade de manutenção quando só um desenvolvedor entende o sistema.
- A troca de um programador ruim por um bom é apresentada como uma troca de 1 por 10.
- Pair programming, collective ownership e testes são apresentados como práticas que programadores cowboy costumam rejeitar.
- O texto sugere desconfiança quando o software vive de correções rápidas e recorrentes.
- A rotatividade anual é vista como uma forma de evitar acomodação e queda de qualidade.
- A atualização esclarece que o ponto não é atacar iniciantes, mas sim pessoas que sabem que são ruins e não mudam.
- O texto usa o exemplo da aviação e do PACE para defender que um bom programador deve dizer não a um chefe que conduz a equipe ao erro.