Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Muita gente pensa que o volume de código produzido é o principal critério para crescer na carreira de desenvolvimento. Mas, na prática, isso pode ser uma armadilha.
No artigo do Devrim Ozcay, ele conta como ficou observando ciclos de revisão e percebeu que o sistema estava meio quebrado. A história dele reforça que qualidade, impacto no produto e colaboração são mais relevantes do que só quantidade.
Em times que priorizam entregas rápidas, muitas vezes acabamos focando em produzir mais sem pensar na manutenção, na clareza do código ou no valor real para o negócio. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.
A questão é: qual o peso que damos ao impacto real do que entregamos? Como evitar que a busca por números acabe prejudicando nossa evolução profissional? O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar.
Seja na revisão de código ou na estratégia de carreira, acho que o mais importante é pensar na qualidade do que entregamos, não só na quantidade. Afinal, a promoção vem do reconhecimento pelo impacto, não da quantidade de linhas. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte.
Até que ponto o seu time valoriza mais o impacto do que o volume de código? Essa balança faz sentido na sua experiência? Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar.
No meu time a gente tenta focar na revisão de impacto, não só na quantidade de commits. Mas é difícil mudar essa cultura, ainda mais em squads mais pressionadas por entregas rápidas. ajudou pra cacete
Isso pesa demais no meu time. Muitas veezes a gente acaba valorizando a quantidade porque é mais fácil de medir, mas no fundo o impacto que o código tem na operação é o que realmente importa.
Verdade, Bruno. Já passei por isso. Acho que o desafio é criar métricas que valorizem a qualidade e o valor entregue, não só o volume. Como vocês medem isso na prática?