A lição que o gerente que eu odiava me ensinou

• Hoje sou gerente de engenharia, mas na época em que eu trabalhava como engenheiro de software, passei vários dias desenvolvendo uma funcionalidade complexa e abri um PR
• O feedback foi firme e frio: “Isso é overengineering. Está complexo. Refatore” foi toda a mensagem
• Fiquei furioso por receber apenas crítica, sem uma palavra de elogio, mas esse episódio com aquele gerente foi só o começo

Um estilo de liderança que não poupa sentimentos

• Esse gerente era diferente dos líderes que eu conhecia até então
• Ele não pegava ninguém pela mão, nem usava palavras gentis
• Tinha características como estas
  • Rejeitava imediatamente ideias ainda mal amadurecidas
  • Odiava complexidade pela complexidade
  • Só valorizava código limpo, eficiente e de fácil manutenção
• Até nas retrospectivas, apontava os problemas diretamente, sem rodeios
• No começo achei que ele era simplesmente frio, mas havia outra filosofia por trás disso

O ponto de virada de um feedback que abalou meu orgulho

• Em uma sprint review, apresentei com confiança uma funcionalidade, mas o gerente me interrompeu no meio e perguntou

  “Isso é frágil. O que acontece sob carga? Qual é o plano de rollback?”

• Como eu não consegui responder direito, ele disse:

  “Agora você está pensando como um programador. Precisa pensar como um engenheiro”

• No início fiquei com raiva, mas acabei percebendo que meu estilo de código priorizava mais a esperteza do que a resiliência

A verdadeira lição: aquele gerente não estava me atacando pessoalmente

• Houve uma grande mudança na minha forma de pensar
  • Em vez de código “inteligente”, passei a escrever código fácil de ler
  • Passei a focar em projetar para cenários de falha
  • Parei de escrever código para mim mesmo e comecei a escrever código para quem viria depois
• Depois disso, as revisões de código daquele gerente passaram sem obstáculos
• Não foi o gerente que mudou, fui eu que cresci

O impacto disso no meu estilo de liderança

• Depois que me tornei gerente de engenharia, pensei muitas vezes nessa experiência
• Eu não queria ser um líder que as pessoas odeiam, mas também não queria ser apenas um líder gentil
• Acabei moldando meu estilo desta forma
  • Dou feedback direto com contexto
  • Enfatizo o pensamento sistêmico
  • Mantenho um padrão alto, mas ofereço feedback humano
• Engenheiros querem ser desafiados, mas não querem se sentir desconsiderados

Quando um gerente firme é necessário

• Liderança fica confusa porque envolve ego, prazo e pressão
• Um gerente firme elimina essa confusão ao fazer com que você
  • Pense em escalabilidade, não apenas em funcionalidade
  • Escreva código sustentável em vez de código esperto
  • Se prepare com antecedência para falhas e casos de exceção
• Ele valoriza mais a sobrevivência do código do que os sentimentos

Como sobreviver e crescer sob um gerente firme

• Se você está sob um líder sufocante, pode lidar com isso assim
  • Não leve para o lado pessoal: o feedback é sobre o código
  • Pergunte “por quê?” depois do feedback: na maioria das vezes, líderes firmes respeitam a curiosidade
  • Pense primeiro, por conta própria, nos pontos de falha: você precisa começar a raciocinar como o gerente
• Se você é líder, deve praticar o seguinte
  • Estabeleça padrões altos, mas explique por que eles importam
  • Seja específico em vez de dar feedback vago
  • Comemore o crescimento, não apenas o sucesso: se um desenvolvedor identificou um problema antes do gerente, elogie isso

O melhor presente que um Pull Request rejeitado me deu

• Na hora, meu orgulho ficou ferido, mas olhando para trás, aquele PR rejeitado foi a maior oportunidade da minha vida
• Foi o momento em que passei a enxergar programação não como um projeto pessoal, mas como construção de sistemas
• Um gerente firme talvez não faça você se sentir bem, mas faz você crescer como desenvolvedor
• O verdadeiro crescimento não começa quando um PR é aprovado, e sim quando ele é rejeitado

[ohyecloudy]

Se há um gerente direto, que não leva em conta os sentimentos, e um gerente gentil, que mantém o rapport, qual tipo de gerente consegue impulsionar o crescimento dos membros da equipe por meio de feedback? Ao ler o texto anterior, essa dúvida me surgiu.

Acho que é um jogo de probabilidades. Em qualquer lugar existem pessoas que conseguem crescer superando probabilidades terríveis. Acho que o gerente deve deixar essas pessoas de lado e se esforçar para aumentar a probabilidade geral. Penso que um gerente que age acreditando, à sua maneira, que essa é uma atitude que aumenta essa probabilidade merece respeito. Desde que não seja apenas manter o método que sempre usou no dia a dia só porque pode continuar fazendo isso.

[roxie]

Acho que esse tipo de feedback, dependendo da personalidade, da cultura e das diferenças individuais, pode soar desagradável ou até causar raiva quando a pessoa ouve. Mas, no geral, abordar isso partindo do princípio de que "essa pessoa não está tentando me atormentar de propósito" parece ser melhor tanto para a saúde mental quanto para o crescimento. Quando uma situação assim surgir, acho que dá para lembrar deste texto e pensar: "Será que esse gerente também?". Ótimo texto.

[bbulbum]

Fala-se muito sobre kind and direct, mas, na verdade, ser direct é bem mais difícil do que ser kind.

[pcj9024]

Um líder que não consegue transmitir o contexto que seus liderados precisam seguir, mesmo sem fornecer o contexto completo, não tem valor algum.
Parece um texto escrito por um excelente liderado, alguém tão competente que acaba atribuindo isso aos outros.
Se o líder não transmite contexto, então esse líder não é particularmente necessário.
Precisa ser substituído com urgência.

[colus001]

Nem tudo o que soa agradável é realmente bom. Eu também acho que a revisão de código mais útil da minha vida foi uma que continha apenas duas palavras: "Nasty Code".

[halfenif]

Nem todo desenvolvedor é igual.

[kipsong133]

Fiquei pensando no que seria "pensamento sistêmico" e, no contexto do texto, me pareceu ser uma forma de pensar a partir da perspectiva do funcionamento de uma aplicação. Ainda assim, acho que é uma perspectiva realmente importante.

[play1204dev]

Eu me identifico bastante, porque já vi uma base de código virar uma bagunça enquanto todo mundo tentava manter a paz. A importância da capacidade de um gerente é realmente enorme.

[girr311]

Concordo.

[spilist2]

A implicação do texto me parece mais que o autor se saiu bem do que que aquele gerente era excepcional. (Será que o autor não é o tipo de pessoa que cresce com qualquer feedback que receba?)

Lembro de ter visto um estudo dizendo que, quando se recebe um feedback negativo (sem contexto suficiente), há uma grande chance de o comportamento mudar no sentido oposto ao esperado.

[kandk]

É preciso entender que feedback sobre o trabalho não é um ataque pessoal.
Teria sido melhor se o gerente fosse uma pessoa melhor, mas a empresa não é uma escola... somos profissionais... então precisamos aprender por conta própria a lidar com feedback.
Também é preciso ter a coragem de dizer que não sabe quando não souber.

[vvvvvv]

Parece que você tem uma perspectiva bem diferente da minha. Talvez por eu ainda ter pouca experiência, vi muitas vezes feedbacks pouco claros ou com referências ambíguas acabarem produzindo justamente o efeito contrário...

[laeyoung]

A ortografia está incorreta.
"Você precisa perceber que não é uma crítica." -> você deve escrever "Você precisa perceber que não é uma crítica".

Embora você saiba que não é uma crítica pessoal, acho que ficou com raiva da minha correção assim que a viu. Alguns chamam isso de josammosa, mas parece que as pessoas são do tipo que recebem josammosa e josamosam de forma diferente.

ps. Eu também não tinha percebido seus erros de ortografia, mas só encontrei o que estava escrito errado depois de colocar no corretor ortográfico porque queria achar um exemplo.

[roxie]

Se alguém corrigir um erro de ortografia, bastaria agradecer e dizer “não sabia”; não parece ser algo que justifique ficar bravo. Acho que pensar que os outros vão sentir o mesmo que você sentiu é uma generalização perigosa. E não é "aceitar separado", mas sim "aceitar".

[kandk]

Acredito que ser profissional também significa conseguir resolver até situações estressantes.
Não estou tentando justificar atitudes que causam estresse. Mas, quando se trabalha de forma profissional, situações que dão raiva podem acontecer, e acredito que ser profissional é lidar com isso com sabedoria.

[kandk]

Acho que não sou nenhum especialista em ortografia. E a comunidade também não é uma empresa.

[qodot]

Concordo muito com o comentário. Acho que isso se deveu à competência e à atitude excelentes de quem recebeu. Penso que esse gerente tinha uma filosofia bem definida, mas não sabia qual seria uma boa abordagem para transmitir sua própria filosofia à equipe.

[kwj9211]

Mesmo que a pessoa jogue algo de qualquer jeito, você entende perfeitamente o que ela quis dizer... acho que é mais ou menos isso, rsrs.

[tsboard]

Texto realmente muito bom. Acho que vou precisar continuar relendo isso, tanto antes quanto depois de abrir um PR.

[ethanhur]

Para que não se torne um ataque pessoal, acho que é preciso ter construído bem o rapport. (Especialmente no contexto da sociedade coreana.)

Pessoalmente, tomo cuidado com o uso do sujeito. Quem está com overengineering é este código, não a outra pessoa que está errada.

[winterjung]

Isso me lembra o texto O que, afinal, está acontecendo na cabeça de um especialista. Quando você recebe uma revisão como “É overengineering. Está complexo. Refatore”, “Isso é vulnerável. O que acontece sob carga? Qual é o plano de rollback?”, também pode ser bom perguntar por que a pessoa pensou assim, que problemas ela está prevendo e em que direção de melhoria está pensando. (Não que o autor não tenha feito isso; é só que, em uma situação dessas, fiquei pensando em como seria possível extrair mais valor.)

[kandk]

Texto realmente muito bom..