Tenho algumas experiências com “código ruim”. Muitas vezes trabalhei sozinho, mas também já escrevi em equipe um código que simplesmente funcionava, sem ser o ideal. Quando eu tentava refatorar código antigo junto com trabalho novo, isso frequentemente era rejeitado, e mesmo quando eu deixava tickets para refatorações ou correções necessárias, normalmente eles perdiam prioridade ou eram ignorados
Sozinho, dá para colocar o que precisa ser feito na prioridade, mas em equipe decisões de segunda linha podem ficar para sempre ou ser deixadas de lado até o momento de “sistema fora do ar”. Depois, na análise pós-incidente, se você apontava para o ticket em que pediu meses antes para consertar a bomba, isso era visto como “culpa” ou “agressividade”, e no fim a solução parecia ser nunca escrever código de segunda linha, o que aumentava a frustração e a ansiedade ao programar
Em 2017, também me chamaram para corrigir código que eu havia escrito em 2003/2004, e ele ainda estava em produção. Rever código quebrado e compromissos que fiz, percebendo que o responsável era justamente eu, é uma experiência bastante humilhante, e depois disso minha visão sobre código de fácil manutenção e documentação mudou muito
Depende da equipe e da empresa. Já passei muito por equipes em que os desenvolvedores eram incentivados a gastar tempo com manutenção e refatoração de código, às vezes até obrigados a fazer só isso, em que trabalho centrado em engenharia tinha prioridade sobre exigências aleatórias de produto, e em que o cronograma era ajustado para concluir direito
Isso foi comum na minha experiência, incluindo grandes empresas do S&P 500, companhias de 100 milhões a 1 bilhão de dólares e startups. Nesses casos, havia engenheiros de software e gestores experientes capazes de fazer concessões razoáveis sem deixar de atender às necessidades do negócio, e era frequente que engenheiros interagissem diretamente com clientes
O ponto central é equilíbrio, e esse equilíbrio normalmente surge por meio de pessoas capazes de julgar com equilíbrio. Se você buscar apenas a “perfeição”, vai para refatoração infinita e nada é lançado; se ignorar dívida técnica ou qualidade lixo, o negócio pode desmoronar com o tempo. Onde ficar nesse espectro depende do produto, do setor, do cliente e do negócio
Ou você morre como herói, ou sobrevive tempo suficiente para ver seu próprio nome em um git blame de 10 anos atrás
“Funciona, mas não é o ideal” muitas vezes é uma concessão aceitável quando falta tempo e há muita coisa a fazer. Slogans de MBA como “o perfeito é inimigo do bom” também servem quando falta alguma coisa
O fato de em 2017 terem me chamado para consertar código que escrevi em 2003/2004 também significa que todos nós somos viajantes do tempo. Sou tolerante com meu eu do passado e levemente rude com meu eu do futuro
Meu eu do passado era jovem e ingênuo, mas produtivo, e atravessou muitas montanhas. Levei dois dias para entender o código, mas no fim ele era bem inteligente, e talvez o eu atual tenha esquecido tudo só por ter memória ruim
Meu eu do futuro vai corrigir todos os erros. Será mais velho e mais sábio, vai trocar XXX e TBD por código inteligente, implementar as boas ideias e acreditar que tem tempo infinito para reimplementar as ideias mais ou menos. Se houvesse comentários melhores, talvez esses três fossem a mesma pessoa
Acho prejudicial essa postura de “aquela única pessoa” justa. É muito libertador e saudável quando desenvolvedores sêniores conseguem falar sobre os próprios erros e fracassos
Não é só uma oportunidade de aprendizado; isso também mostra uma cultura aberta e ajuda a combater a síndrome do impostor. A postura perfeccionista vai na direção oposta: tudo vira “esforce-se mais para não errar”, sem nada para aprender e apenas exigindo mais esforço individual
Em pelo menos duas ocasiões, “aquela única pessoa” não admitiu um erro grande, evitou isso mesmo ao custo de perder um bom cliente, e imagino que tenha falado mal pelas costas
Uma vez, eu assumi uma pequena falha de um júnior que colocou a versão errada do software em um relatório, algo que bastava resolver dizendo ao cliente “houve um erro e aqui está o relatório corrigido”, mas meu chefe só pensava em “dá para esconder isso e manter a aparência de que somos perfeitos?”. A mesma pessoa aproveitava erros dos outros como oportunidade para pedir desconto, compensação ou gratuidade
Acho que a maioria vai melhorando enquanto faz o próprio trabalho. Na nossa gestão de configuração há várias coisas que eu escrevi e que funcionam bem em termos funcionais, mas depois de lidar com a ferramenta por 1 ou 2 anos, passei a chamá-las de bem ruins em qualidade por vários motivos
E tudo bem. Quando surgir um motivo para mudar, dá para arrumar; até lá, elas ficam como exemplos de maus hábitos e de abordagens melhores
Se você não consegue encontrar nada para criticar em si mesmo, isso significa que não está evoluindo. Compartilhar essa autocrítica também permite que os outros aprendam com meus erros e entendam que tudo bem aprender com os próprios erros
Em review de código, frequentemente ouço coisas como “por que você simplesmente não evita esse erro?” ou “por que você simplesmente não faz assim?”
Hoje em dia respondo: “provavelmente porque seu QI é maior que o meu. Eu tenho QI baixo, então preciso fazer coisas mais burras e simples”. Às vezes isso faz a pessoa perceber o quanto agiu como um pequeno esquisitão depreciativo e sem reflexão, e ela fica vermelha
Tenho certa alergia a perguntas que começam com “por que você simplesmente não...?”. Só essas três palavras já costumam me fazer prever a sugestão que vem depois, não porque seja extremamente complexa, mas porque geralmente é a forma óbvia que vem primeiro à cabeça, e que já foi cuidadosamente considerada ou tentada
A pergunta em si não é ruim, mas a premissa de “minha ideia é tão fácil” e “você não pensou nessa solução óbvia e fácil” pode soar irritante ou ofensiva. Por outro lado, quando eu pergunto isso aos outros, tento evitar o “simplesmente não”, e algo como “posso entender que houve algum motivo para você não ter feito X?” ou só perguntar o motivo com gentileza pode funcionar melhor
Se for uma pergunta causada por falta de contexto, dá para evitar isso explicando antes, em vez do que fiz, por que os caminhos mais óbvios não funcionaram, ou quais eram os requisitos complicados e entradas problemáticas. Se o código já foi commitado, o objetivo é reduzir comentários tardios com observações no commit ou no merge request. Às vezes também ajuda não rebater, mas explicar diretamente que tentei aquele caminho e por que não funcionou, e perguntar com sinceridade se a pessoa tem outra ideia
Se realmente for uma sugestão em que eu não tinha pensado e que parece resolver o problema, digo que é uma boa ideia e peço ajuda para implementar. Nessas horas existe a tentação de confrontar a premissa ou o tom da pessoa, mas tento só aceitar e sentir um pouco de vergonha por um momento
Este é um caso de aplicar muito bem o grug brain https://grugbrain.dev/
“Se tivesse que escolher entre complexidade e lutar no mano a mano com um tiranossauro, grug escolheria o tiranossauro. Pelo menos grug consegue ver o tiranossauro”
A menos que seja brincadeira, a primeira pergunta não ajuda e é quase uma grosseria. Todo mundo erra de vez em quando
A segunda pergunta geralmente pode ser um feedback razoável. As habilidades e os conhecimentos das pessoas nem sempre se sobrepõem. Algo absurdamente complexo para A pode não ser para B, e o contrário também pode acontecer, e isso não significa necessariamente que alguém seja mais inteligente. A pode não saber SQL e B pode não saber pandas
Se já assumirmos que a stack técnica inclui tanto SQL quanto pandas, às vezes faz sentido mover algum código de SQL para pandas ou vice-versa. Algumas pessoas acham o estilo orientado a objetos mais fácil, outras acham o estilo funcional mais fácil. Nem sempre é óbvio o que é mais razoável, então a pergunta pode ser uma boa pergunta. Se a sugestão for ruim, basta explicar por que é ruim; se for boa, dá para avaliar se vale a pena fazer isso agora. Se estiver no meio-termo ou não houver tempo, basta reconhecer isso e seguir em frente
Outra alternativa é simplesmente concordar de forma explícita. Dá para responder “É, foi burrice mesmo?”, “É, talvez não devesse ter sido assim”, ou “Vou pensar nisso”
Aí fica mais difícil a outra pessoa me envergonhar ou me fazer sentir culpa por eu ter feito a segunda melhor coisa. Vejo que o objetivo desse tipo de fala muitas vezes é estabelecer superioridade pela vergonha. É escolher não entrar no jogo, e em geral essa é a jogada vencedora
Se foi dito por ignorância, não é preciso necessariamente tomar como um ataque e fazer a outra pessoa passar vergonha para que pague por isso
Não encontro mais o blog ou texto que vi antes, mas a mensagem era “ao ver algo não ideal no código, não assuma incompetência”. A pessoa que escreveu aquele código pode ter tido um prazo apertado, outras prioridades ou outros fatores que a impediram de fazer imediatamente “a coisa certa” naquela hora
Mesmo que o código fosse perfeito quando foi escrito, o crescimento da base de código e as mudanças de requisitos podem tê-lo tornado ruim
Por exemplo, se houver 10 itens para armazenar, um arquivo simples pode ser uma escolha prática, mas quando isso vira 10.000, talvez seja preciso um banco de dados. Só que, se você tivesse usado um banco desde o começo para 10 itens, teriam reclamado de overengineering
Se houver 2 classes, if/else pode bastar, mas quando viram 20, talvez seja necessário um padrão Factory, e se isso tivesse sido feito desde o início, teria parecido arquitetura espacial demais. Tentar prever esse crescimento e errar leva à criação de código complexo. Projetos em desenvolvimento contínuo crescem sistematicamente além de si mesmos
Também existe a cerca de Chesterton. Aquela coisa idiota no código talvez realmente tenha sido importante no passado. Pior: talvez ainda seja importante em casos de borda raros, e você só ainda não enxergou o motivo
Já recebi alguns comentários maldosos sobre posts de blog aqui e no reddit. Nesses casos, uso uma abordagem de jogar luz sobre isso, adicionando ao texto um link para o comentário maldoso sem julgá-lo. Normalmente não acontece nada, mas às vezes isso ajuda a recolocar a discussão num rumo mais saudável
Eu também já recebi bastante disso. Alguns talvez fossem merecidos, mas a maioria provavelmente não. Alguns tinham até certo ponto razão, mas não ajudavam ou eram diretamente nocivos para a comunidade. Se você diz a coisa certa da forma errada, continua dizendo a coisa errada
Linkar um comentário maldoso sem julgar não é uma má ideia. Nem sempre dá para fazer isso quando o comentário foi apagado, mas de qualquer forma eu não revido do mesmo jeito. Eu até poderia, mas aprendi que gasolina não é um extintor eficaz
Se eu estiver errado, tento reconhecer isso logo no mesmo lugar em que o erro ocorreu. Detesto especialmente pedido de desculpas em privado depois de um ataque público
Há limites. Acho que faço um trabalho muito bom, faço isso há uns 40 anos e aprendi bastante nesse tempo. Já trabalhei em ambientes exigentes que não aceitavam trabalho de baixo nível, então acabei criando o hábito de fazer um trabalho decente
Em geral, evito julgar os outros em público. Não ajuda, e eu nem sempre estou certo. Mas pode ser diferente se eu estiver trabalhando junto com a pessoa ou usando aquilo que ela fez. Já fui atacado de forma grosseira por não aceitar lixo, mas não ajo como Linus Torvalds. Quando possível, digo de forma respeitosa que aquele trabalho é inaceitável para mim
Ainda assim, sempre dá para melhorar e aprender algo novo, e às vezes isso vem de lugares totalmente inesperados. Estar aberto a esse aprendizado é, no geral, uma boa política. Eu estou errado e me torno certo ao aprender. “Bom julgamento vem da experiência, e experiência vem de mau julgamento”
Um dos podcasts de que gosto, well there's your problem, no YouTube, quase sempre fixa comentários reclamando do podcast. Em geral são reclamações do tipo “não gostei deste podcast, então ele deveria virar outro podcast”, e o comentário fixado costuma ser, toda vez, algo próximo da interpretação mais idiota possível daquele episódio
Não sei se isso funciona para reduzir esse tipo de comentário, mas pelo menos serve para colocar um chapéu de bobo metafórico em quem participa do debate dessa forma
Concordo que alguns engenheiros têm uma atitude ruim. Qualquer um pode escrever código ruim, e também há algum mérito na lógica de que todo código é ruim e é dívida
É interessante ler este post junto com “No more pink mustache”. Nele, a Lyft é descrita como “quebrada em uma escala difícil de acreditar”, e a causa da qualidade muitas vezes não é a organização, e não a pessoa sentada na cadeira :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
Li este texto em 2018 e fico feliz em vê-lo reaparecer. Foi um dos textos que me fizeram me questionar. Se não dá para eliminar o absolutismo ou a extremidade, fico pensando que tipo de filtro dá para criar ao lidar com esse tipo de conversa ou de pessoa. Tenho meu próprio modelo, mas fico curioso sobre que estratégias outras pessoas usam
Essas pessoas tentam ocupar um território emocional que não é delas. Em geral, elas já calcularam antes que “podem fazer isso”, o que significa que veem a outra pessoa como fraca
Há três opções. Desistir e ceder esse território, então seguir com a vida; quanto menos noites mal dormidas por causa da injustiça, melhor. Enfrentar de frente; essas pessoas estão prontas para brigar, mas como a posição delas é intrinsecamente irracional, quanto menos você for puxado para o espaço mental delas, mais “vence”. Vir por cima; isto é, levar para o espaço delas uma prova social de que elas estão erradas. No caso do post original, isso seriam programadores produtivos que respeitam o trabalho uns dos outros e não ficam caçando defeito
Quando alguém aconselha “talvez tivesse sido melhor fazer assim”, isso nem sempre é um ataque pessoal ou um insulto à minha competência
A pessoa que dá conselhos pode ser um idiota sem habilidade social, ou simplesmente um idiota completo. Tudo bem que uma parte do mundo não concorde comigo. O fato de as pessoas expressarem opiniões contrárias ou discordarem não significa que estejam me ameaçando
Texto estranho. Soa como um tuíte, tem pouco conteúdo e o título não reflete o corpo do texto, então parece clickbait
Não discordo da ideia principal, mas existe o outro lado também. É preciso ter capacidade de aceitar feedback
A maioria das pessoas consegue aceitar feedback e aplicá-lo. O problema é que algumas dão feedback de forma péssima e depois acham que a outra pessoa não sabe aceitar feedback
Essas pessoas acreditam que o jeito de dar feedback de que elas gostam é o melhor, que todo mundo deveria sentir o mesmo e que, se não for assim, a outra pessoa é que precisa mudar. Claro que isso está errado. Mas, se você disser isso a elas, elas mesmas mostram por que eu disse “a maioria” na primeira frase.
1 comentários
Comentários do Hacker News
Sozinho, dá para colocar o que precisa ser feito na prioridade, mas em equipe decisões de segunda linha podem ficar para sempre ou ser deixadas de lado até o momento de “sistema fora do ar”. Depois, na análise pós-incidente, se você apontava para o ticket em que pediu meses antes para consertar a bomba, isso era visto como “culpa” ou “agressividade”, e no fim a solução parecia ser nunca escrever código de segunda linha, o que aumentava a frustração e a ansiedade ao programar
Em 2017, também me chamaram para corrigir código que eu havia escrito em 2003/2004, e ele ainda estava em produção. Rever código quebrado e compromissos que fiz, percebendo que o responsável era justamente eu, é uma experiência bastante humilhante, e depois disso minha visão sobre código de fácil manutenção e documentação mudou muito
Isso foi comum na minha experiência, incluindo grandes empresas do S&P 500, companhias de 100 milhões a 1 bilhão de dólares e startups. Nesses casos, havia engenheiros de software e gestores experientes capazes de fazer concessões razoáveis sem deixar de atender às necessidades do negócio, e era frequente que engenheiros interagissem diretamente com clientes
O ponto central é equilíbrio, e esse equilíbrio normalmente surge por meio de pessoas capazes de julgar com equilíbrio. Se você buscar apenas a “perfeição”, vai para refatoração infinita e nada é lançado; se ignorar dívida técnica ou qualidade lixo, o negócio pode desmoronar com o tempo. Onde ficar nesse espectro depende do produto, do setor, do cliente e do negócio
Meu eu do passado era jovem e ingênuo, mas produtivo, e atravessou muitas montanhas. Levei dois dias para entender o código, mas no fim ele era bem inteligente, e talvez o eu atual tenha esquecido tudo só por ter memória ruim
Meu eu do futuro vai corrigir todos os erros. Será mais velho e mais sábio, vai trocar XXX e TBD por código inteligente, implementar as boas ideias e acreditar que tem tempo infinito para reimplementar as ideias mais ou menos. Se houvesse comentários melhores, talvez esses três fossem a mesma pessoa
Não é só uma oportunidade de aprendizado; isso também mostra uma cultura aberta e ajuda a combater a síndrome do impostor. A postura perfeccionista vai na direção oposta: tudo vira “esforce-se mais para não errar”, sem nada para aprender e apenas exigindo mais esforço individual
Uma vez, eu assumi uma pequena falha de um júnior que colocou a versão errada do software em um relatório, algo que bastava resolver dizendo ao cliente “houve um erro e aqui está o relatório corrigido”, mas meu chefe só pensava em “dá para esconder isso e manter a aparência de que somos perfeitos?”. A mesma pessoa aproveitava erros dos outros como oportunidade para pedir desconto, compensação ou gratuidade
E tudo bem. Quando surgir um motivo para mudar, dá para arrumar; até lá, elas ficam como exemplos de maus hábitos e de abordagens melhores
Hoje em dia respondo: “provavelmente porque seu QI é maior que o meu. Eu tenho QI baixo, então preciso fazer coisas mais burras e simples”. Às vezes isso faz a pessoa perceber o quanto agiu como um pequeno esquisitão depreciativo e sem reflexão, e ela fica vermelha
A pergunta em si não é ruim, mas a premissa de “minha ideia é tão fácil” e “você não pensou nessa solução óbvia e fácil” pode soar irritante ou ofensiva. Por outro lado, quando eu pergunto isso aos outros, tento evitar o “simplesmente não”, e algo como “posso entender que houve algum motivo para você não ter feito X?” ou só perguntar o motivo com gentileza pode funcionar melhor
Se for uma pergunta causada por falta de contexto, dá para evitar isso explicando antes, em vez do que fiz, por que os caminhos mais óbvios não funcionaram, ou quais eram os requisitos complicados e entradas problemáticas. Se o código já foi commitado, o objetivo é reduzir comentários tardios com observações no commit ou no merge request. Às vezes também ajuda não rebater, mas explicar diretamente que tentei aquele caminho e por que não funcionou, e perguntar com sinceridade se a pessoa tem outra ideia
Se realmente for uma sugestão em que eu não tinha pensado e que parece resolver o problema, digo que é uma boa ideia e peço ajuda para implementar. Nessas horas existe a tentação de confrontar a premissa ou o tom da pessoa, mas tento só aceitar e sentir um pouco de vergonha por um momento
“Se tivesse que escolher entre complexidade e lutar no mano a mano com um tiranossauro, grug escolheria o tiranossauro. Pelo menos grug consegue ver o tiranossauro”
A segunda pergunta geralmente pode ser um feedback razoável. As habilidades e os conhecimentos das pessoas nem sempre se sobrepõem. Algo absurdamente complexo para A pode não ser para B, e o contrário também pode acontecer, e isso não significa necessariamente que alguém seja mais inteligente. A pode não saber SQL e B pode não saber pandas
Se já assumirmos que a stack técnica inclui tanto SQL quanto pandas, às vezes faz sentido mover algum código de SQL para pandas ou vice-versa. Algumas pessoas acham o estilo orientado a objetos mais fácil, outras acham o estilo funcional mais fácil. Nem sempre é óbvio o que é mais razoável, então a pergunta pode ser uma boa pergunta. Se a sugestão for ruim, basta explicar por que é ruim; se for boa, dá para avaliar se vale a pena fazer isso agora. Se estiver no meio-termo ou não houver tempo, basta reconhecer isso e seguir em frente
Aí fica mais difícil a outra pessoa me envergonhar ou me fazer sentir culpa por eu ter feito a segunda melhor coisa. Vejo que o objetivo desse tipo de fala muitas vezes é estabelecer superioridade pela vergonha. É escolher não entrar no jogo, e em geral essa é a jogada vencedora
Por exemplo, se houver 10 itens para armazenar, um arquivo simples pode ser uma escolha prática, mas quando isso vira 10.000, talvez seja preciso um banco de dados. Só que, se você tivesse usado um banco desde o começo para 10 itens, teriam reclamado de overengineering
Se houver 2 classes, if/else pode bastar, mas quando viram 20, talvez seja necessário um padrão Factory, e se isso tivesse sido feito desde o início, teria parecido arquitetura espacial demais. Tentar prever esse crescimento e errar leva à criação de código complexo. Projetos em desenvolvimento contínuo crescem sistematicamente além de si mesmos
Linkar um comentário maldoso sem julgar não é uma má ideia. Nem sempre dá para fazer isso quando o comentário foi apagado, mas de qualquer forma eu não revido do mesmo jeito. Eu até poderia, mas aprendi que gasolina não é um extintor eficaz
Se eu estiver errado, tento reconhecer isso logo no mesmo lugar em que o erro ocorreu. Detesto especialmente pedido de desculpas em privado depois de um ataque público
Há limites. Acho que faço um trabalho muito bom, faço isso há uns 40 anos e aprendi bastante nesse tempo. Já trabalhei em ambientes exigentes que não aceitavam trabalho de baixo nível, então acabei criando o hábito de fazer um trabalho decente
Em geral, evito julgar os outros em público. Não ajuda, e eu nem sempre estou certo. Mas pode ser diferente se eu estiver trabalhando junto com a pessoa ou usando aquilo que ela fez. Já fui atacado de forma grosseira por não aceitar lixo, mas não ajo como Linus Torvalds. Quando possível, digo de forma respeitosa que aquele trabalho é inaceitável para mim
Ainda assim, sempre dá para melhorar e aprender algo novo, e às vezes isso vem de lugares totalmente inesperados. Estar aberto a esse aprendizado é, no geral, uma boa política. Eu estou errado e me torno certo ao aprender. “Bom julgamento vem da experiência, e experiência vem de mau julgamento”
Não sei se isso funciona para reduzir esse tipo de comentário, mas pelo menos serve para colocar um chapéu de bobo metafórico em quem participa do debate dessa forma
É interessante ler este post junto com “No more pink mustache”. Nele, a Lyft é descrita como “quebrada em uma escala difícil de acreditar”, e a causa da qualidade muitas vezes não é a organização, e não a pessoa sentada na cadeira :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
Há três opções. Desistir e ceder esse território, então seguir com a vida; quanto menos noites mal dormidas por causa da injustiça, melhor. Enfrentar de frente; essas pessoas estão prontas para brigar, mas como a posição delas é intrinsecamente irracional, quanto menos você for puxado para o espaço mental delas, mais “vence”. Vir por cima; isto é, levar para o espaço delas uma prova social de que elas estão erradas. No caso do post original, isso seriam programadores produtivos que respeitam o trabalho uns dos outros e não ficam caçando defeito
A pessoa que dá conselhos pode ser um idiota sem habilidade social, ou simplesmente um idiota completo. Tudo bem que uma parte do mundo não concorde comigo. O fato de as pessoas expressarem opiniões contrárias ou discordarem não significa que estejam me ameaçando
Essas pessoas acreditam que o jeito de dar feedback de que elas gostam é o melhor, que todo mundo deveria sentir o mesmo e que, se não for assim, a outra pessoa é que precisa mudar. Claro que isso está errado. Mas, se você disser isso a elas, elas mesmas mostram por que eu disse “a maioria” na primeira frase.