Confissões de um desenvolvedor de software: sem mais autocensura

• Um desenvolvedor que havia parado de escrever e de manter atividades online por meses por causa do medo decide parar com a autocensura e confessar deficiências técnicas e pessoais que não conseguia admitir até então
• Admite que não entendeu o conceito de polimorfismo (polymorphism) por mais de 10 anos, que perdeu a prática em SQL e que implantou a maior parte do código sem testes automatizados
• Ao tentar acompanhar a mudança de stack da empresa, interrompeu o aprendizado de C# e Blazor; continua amando Ruby, mas sem conseguir usá-lo profissionalmente; e sente o peso psicológico de saber que gestores e colegas leem seu blog
• Relata a experiência de sofrer cyberbullying após enviar um PR escrito com IA, além de opiniões francas sobre trabalho remoto e sobre a desnecessidade de processos de desenvolvimento personalizados dentro da organização
• Termina com a decisão de deixar o medo de lado e seguir com aprendizado contínuo e escrita pública sem mais autocensura

---

Começo: o que levou à decisão de parar com o medo e a autocensura

• Desde abril, houve um período em que o medo era tão grande que ele não conseguia publicar nada, e cortou completamente redes sociais, agregadores de notícias e fóruns
  • Sentiu que não dava mais para continuar assim e decidiu voltar a escrever, superando o medo
• Passou muito tempo escondendo suas lacunas por não querer expor fundamentos fracos, mas acabou percebendo que muitos desenvolvedores trabalham com falhas de conhecimento parecidas
  • Seu modo de aprender até aqui se parecia com um slime mold que cresce de forma desproporcional só nas áreas usadas, enquanto o conhecimento não utilizado secava por completo
• Recentemente voltou a preencher os fundamentos e, ao reorganizar o que aprende em texto e fala, começou a se firmar a sensação de admitir com leveza que “não sabe”
• Ao sentir na prática que dá para reaprender a base, surgiu a convicção de que nunca é tarde

O período em que não entendeu polimorfismo por mais de 10 anos

• Desde 2012 achava que escrevia código orientado a objetos, mas acabou admitindo para si mesmo que até cerca de um ano atrás ainda não entendia polimorfismo de verdade
  • Enfrentou a realidade de que o código que escreveu até aqui era, mais do que orientado a objetos, mais próximo de programação estruturada
  • Nunca havia pensado em substituir condicionais por classes para mudar o design
• Ao ler textos de Sandi Metz e materiais de Martin Fowler, finalmente entendeu o conceito, e ficou claro o quanto havia deixado passar

• Por que era difícil expor isso

  • Pesava admitir que alguém que participava de entrevistas avaliando conceitos de orientação a objetos na verdade não sabia polimorfismo
  • Isso também escancarava como, no início da carreira, o foco esteve mais em ferramentas do que em princípios, e como havia muitos fundamentos perdidos por não ter formação em CS

A experiência de esquecer SQL

• No passado, houve claramente uma fase em que, acompanhando livros de SQL e fazendo exercícios, escrevia JOINs e subqueries com fluência
• Como passou a atuar principalmente em frontend e deixou de usar SQL por completo, percebeu em algum momento que uma habilidade inteira havia simplesmente desaparecido da cabeça
  • As queries básicas ainda vêm à mente, mas para explicar a diferença entre left join e outer join, precisaria abrir a documentação de novo

• Por que era difícil admitir isso

  • Quando era mais jovem, acreditava que, mesmo depois de anos, fatos e habilidades voltariam à memória com apenas uma pequena pista
  • Agora sentiu na prática que essa capacidade já não se mantém igual, e que a primeira habilidade a sair inteira da memória foi SQL
  • Não foi fácil escrever publicamente sobre envelhecer e sobre a mudança no funcionamento da memória

A realidade de ter desenvolvido sem testes automatizados

• Admite que mais de 95% do código colocado em produção até hoje roda sem testes automatizados
  • No começo da carreira, nem tinha contato com o conceito de testes, e na época de Ember era difícil usar bem as ferramentas de teste
• Mais recentemente, por lidar muito com código legado, não conseguiu dedicar tempo suficiente ao trabalho preparatório para tornar o código testável
  • Só conseguiu incluir testes em subsistemas novos

• Por que era difícil expor isso

  • Sentia que essa confissão era o fato mais devastador para a carreira
  • Pelo padrão do Uncle Bob, código em produção sem testes poderia ser visto como uma postura antiética, e foi assustador encarar a distância entre esse padrão e sua realidade
  • Parecia muito provável que, se isso se tornasse público, fosse prejudicado em processos seletivos, o que o levou até a adiar o próprio registro do processo de aprendizado

Por que não conseguiu aprender Blazor

• Quando a empresa decidiu migrar de Angular para Blazor, ele era a única pessoa do time sem experiência com C#, então começou a estudar às pressas para acompanhar
• Alguns meses depois, a decisão de migração foi revertida, e a motivação para estudar desapareceu por completo; ele não terminou o livro e parou
• C# e .NET nunca foram linguagens que quisesse usar em side projects; ficou evidente que estava estudando isso exclusivamente por trabalho

• Por que era difícil escrever isso

  • Em um texto anterior, havia prometido explicitamente escrever uma continuação, e foi ficando cada vez mais desconfortável escrever outros textos sem cumprir essa promessa
  • Como os textos sobre Blazor tiveram alta audiência, temia que admitir a mudança de direção parecesse uma derrota

A vontade de usar mais Ruby

• Ruby continua sendo a linguagem mais confortável e divertida para ele, e é a escolha natural em exemplos, open source, katas e hackathons
• Mas, desde 2013, não recebeu salário por trabalhar com Ruby nem uma única vez, e no trabalho usa linguagens como TypeScript
• Como gosta muito dos colegas com quem trabalhou em várias empresas, precisou continuar fazendo a escolha de ceder na linguagem para escolher as pessoas
• Gostaria de dedicar noites e fins de semana a Ruby, mas outras obrigações e metas de estudo seguem ocupando esse espaço, e quase nunca sobra tempo suficiente para usar Ruby como gostaria

• Por que era difícil revelar isso

  • Seu gerente e o CTO leem o blog, então tinha medo de que dizer que queria usar mais Ruby fosse interpretado como um sinal de saída da empresa
  • Também não queria parecer alguém tentando empurrar no trabalho uma linguagem com a qual a empresa não está acostumada

Cyberbullying ainda machuca na vida adulta

• Depois de enviar um pequeno patch gerado com LLM para um projeto open source e compartilhar a experiência em um fórum online,
  enfrentou uma enxurrada de ataques pessoais como incompetente, nojento e ameaçador
• Os ataques ultrapassaram o site e se estenderam a outros sites, e-mail, SMS e ligações, trazendo uma sensação concreta de insegurança
• Pediu ao administrador do fórum que removesse seu nome real, mas, em vez disso, mais PII foi adicionada ao perfil,
  e ainda se viu diante da situação de ficar marcado permanentemente com uma frase falsa dizendo que ele inventou a história dos contatos externos
• No fim, não teve alternativa a não ser desativar a conta e abandonar o site

• Por que era difícil escrever isso

  • O assédio, que durou vários dias, foi a experiência online mais tóxica que já viveu, e os efeitos ainda permanecem
  • Continua existindo o medo de que, ao tornar isso público, os agressores apareçam de novo
  • Também foi ficando ainda mais difícil falar sobre isso por imaginar que as informações falsas deixadas no perfil poderiam prejudicar sua empregabilidade

A ideia de que um time de SaaS não precisa de um “processo especial”

• A indústria de software já conta há décadas com processos refinados,
  e abordagens como Agile, Lean, Kanban e XP já existem como estruturas validadas
• Foi se consolidando naturalmente a visão de que a capacidade limitada da empresa deveria ser usada no desenvolvimento do produto, e não na invenção de um novo processo

• Por que era difícil falar disso

  • Ao escrever, ele sempre tenta partir de temas que conhece bem, e neste caso o gatilho havia sido um processo customizado de desenvolvimento de software proposto por um colega da mesma empresa
    • Parecia haver o risco de o texto soar como uma crítica pública a uma pessoa específica ou à sua ideia
  • Ele admira em autores como Kent Beck e Martin Fowler a capacidade de explicar formas melhores de colaboração sem mirar frontalmente em colegas que erraram
    • Sentindo que ainda não tem esse equilíbrio, hesitou em escrever

Como o trabalho remoto atrapalha a colaboração na prática

• O trabalho remoto resolve muitos problemas, mas continua difícil afastar a sensação de que o desenvolvimento de software em si funciona melhor quando as pessoas estão juntas no mesmo espaço
• Chamadas de vídeo são uma forma de comunicação de baixa largura de banda e baixa sensorialidade, e a perda de percepção periférica dificulta notar quando um colega está com problemas
• Pedir ajuda também fica mais oneroso, e formas espaciais de pensar, como quadro branco e sticky notes, se quebram com facilidade em ferramentas online
• Conflitos se agravam mais rápido por causa da facilidade de transformar a pessoa do outro lado da tela em um inimigo

• Por que era difícil escrever isso

  • Depois da covid, a empresa virou totalmente remota, e isso permitiu construir uma vida com 27 acres de terra e até vacas leiteiras para a família
  • Como sua estrutura de vida hoje torna difícil se mudar para a cidade, dizer que não prefere trabalho remoto
    parecia passar uma impressão ruim tanto no emprego atual quanto em qualquer vaga remota futura

Planos daqui para frente

• Sente que este texto foi um primeiro passo para voltar a superar o medo,
  e planeja continuar estudando os fundamentos e registrando tudo o que aprender sem esconder nada
• Também orienta pessoas com experiências parecidas, quem queira ajudar e quem esteja curioso pelo próximo texto a acompanhar as novidades por Mastodon, RSS e mailing list

[GN⁺]

Comentários do Hacker News

• Aprendi algo com um colega muito inteligente. Ele não tem medo de não saber e continua perguntando até entender. Achei impressionantes a confiança e a paciência necessárias para aprender em público
• Gostei da humildade e da sinceridade do texto. Não há motivo para ter vergonha de não saber. Estou aprendendo há 37 anos e ainda continuo aprendendo coisas novas.
  Eu também prefiro trabalhar no escritório, mas isso não significa defender RTO (volta ao escritório). É só o meu jeito.
  Parece que a ansiedade e a síndrome do impostor no setor deixam as pessoas mais agressivas. Acho que, se todos fossem mais sinceros, ficaria mais fácil.
  E, para confessar, nunca escrevi nada mais complexo que Fibonacci em Lisp ou Haskell. Meu cérebro simplesmente não funciona desse jeito
  • Discordo da sua opinião sobre trabalho remoto, mas acho que não há problema porque você a expressou como uma opinião pessoal.
    Mas o texto original apresenta a própria experiência como se fosse uma verdade objetiva e generalizável. Especialmente a narração em segunda pessoa soou arrogante.
    A forma como se fala é tão importante quanto o conteúdo. Em temas sensíveis como trabalho remoto, é preciso ter cuidado com a forma de se expressar.
    Eu também precisei trabalhar remotamente por questões de saúde na família, então o tom do texto me pareceu leviano e isso me irritou.
    No fim, antes de dizer que as pessoas estão exagerando, é melhor refletir primeiro sobre o impacto das próprias palavras
  • Eu também não conseguia escrever nada além de Fibonacci antes de participar de um projeto baseado em Lisp. Depois de usar no dia a dia, acabei me acostumando
  • Por que tanta gente te xinga quando você diz que prefere trabalho remoto? Porque, depois da covid, muita gente sentiu que ganhou liberdade e agora sente que está sendo restringida de novo. Por isso a reação parece tão forte
  • Hoje em dia, os gurus de programação do YouTube dizem que estão certos sobre tudo. É um mundo em que, faça o que fizer, vão dizer que está errado
• Sempre que ouço falar de trabalho remoto, sinto saudade da era do IRC. Naquela época, já colaborávamos remotamente muito bem.
  Em vez de conversas de corredor, resolvíamos problemas no chat da equipe, e todo mundo ajudava ativamente.
  Hoje, dá até a sensação de que usamos pior as ferramentas
  • Hoje em dia, muita gente tem medo de escrever em canais públicos. Antes havia anonimato, mas agora tudo gira em torno de identidade real, então as pessoas ficam mais cautelosas.
    Com menos espaços para falar anonimamente, surgiu uma cultura em que é difícil falar com liberdade
  • Antigamente, usar Slack no escritório era muito mais eficiente do que agora.
    Se desse errado, bastava ir até a mesa ao lado e resolver; agora, se dá errado, simplesmente acaba ali
  • O trabalho remoto da época da covid não era trabalho remoto de verdade. Era isolamento, e a cultura e os processos não estavam preparados.
    Por isso, as pessoas acabaram culpando o trabalho remoto pela solidão
  • Acho que a causa da mudança é mais uma mudança de personalidade do que de demografia. Antes havia muitos “garotos esquisitos”, e eles não tinham medo de fazer perguntas.
    Agora há mais gente socialmente ajustada, então são mais fracos em comunicação assíncrona
  • Corrigir bugs por chat não é a mesma coisa que “respirar o mesmo ar”.
    Como a densidade de sinais não verbais é menor, também há menos pistas sociais
• Mesmo estando no mesmo setor de SaaS, parece que vivemos em mundos completamente diferentes.
  Muitos desenvolvedores estão seguindo trajetórias de carreira, e não o interesse.
  Reaprendi SQL três vezes. Como a tecnologia muda o tempo todo, não dá para lembrar de tudo.
  O importante não é a sintaxe, e sim a capacidade de resolver problemas e colaborar.
  Acho difícil que a IA substitua isso
• 95% do código que escrevi tinha 0% de cobertura de testes. Foi assim em vários países e várias empresas. Fico curioso se só eu fui assim
  • Testes automatizados são uma ferramenta que dá confiança no desenvolvimento repetitivo. Depois que você aprende, não quer mais voltar atrás
  • Comigo era parecido, mas agora estou tentando mudar. Adicionar testes depois em um projeto sem testes é realmente muito difícil
  • Testes têm, em certa medida, sua importância superestimada. Às vezes passam uma falsa sensação de segurança. Há muitos casos em que a própria linguagem não é adequada para testes
• O clima das pessoas trabalhando ao meu redor ajuda a induzir foco.
  Existe um efeito contagioso de concentração. Um espaço de trabalho compartilhado aumenta a produtividade
  • Também sou desse tipo. Mas a empresa impõe uma “política de mesa limpa”, e isso me incomoda. Preciso de um ambiente personalizado
  • Sinto algo parecido até em cafés movimentados. A produtividade dos outros me estimula
  • Isso é parecido com o conceito de “body doubling” do TDAH
  • Eu também prefiro trabalhar no escritório, mas um espaço com porta é indispensável.
    A porta é a melhor ferramenta para regular colaboração e concentração.
    É um sinal muito mais claro do que o status “away” online
  • Mas nem todo mundo trabalha bem nesse tipo de ambiente.
    Obrigar outras pessoas a irem ao escritório para preservar a concentração de alguém é desumano
• Este texto é corajoso. Mas também mostra bem o problema de generalizar experiências pessoais.
  Talvez não seja que o trabalho remoto seja ruim, e sim que a pessoa trabalhou em uma empresa com estrutura de suporte ruim
• O autor é duro demais consigo mesmo. Admitir que não sabe algo traz uma sensação de libertação.
  Eu também digo “não sei” com frequência. Isso é uma característica de pessoas com alta inteligência emocional
  • Meu chefe gostava quando eu dizia “não sei”. A honestidade gera confiança
  • No trabalho tudo bem, mas online é difícil dizer “não sei” por causa da preocupação com reputação
  • Quando perguntam sobre git rebase em entrevista, acho que mais importante do que os detalhes técnicos é a capacidade real de usar isso na prática
• Gostei da sinceridade do autor. Também passei por algo parecido.
  Enquanto fazia live coding em Kotlin, entrei em pânico porque não consegui lembrar da sintaxe de switch.
  Percebi que até uma linguagem usada todos os dias pode ser esquecida rapidamente
  • Eu também procuro a sintaxe de switch toda vez. Se não usa com frequência, é natural esquecer
  • Acho que, conforme aumente o número de desenvolvedores mais velhos, vamos ser mais tolerantes com esses “momentos de esquecimento”
  • Todo mundo erra. Até chefe às vezes esquece o atalho de colar
  • Se você não usa com frequência, a habilidade se deteriora rápido, mas volta logo quando retoma.
    Os conceitos ficam por muito tempo, mas a sintaxe detalhada some rápido
• No começo, achei que o texto fosse falar do desaparecimento dos desenvolvedores por causa da IA.
  Mas, na prática, o clima é de que é difícil até falar dessa ansiedade.
  Eu também gosto de escrever código com Claude, mas ao mesmo tempo sinto medo.
  Se somos a geração que melhor entende a natureza das mudanças que estão por vir, então precisamos discutir isso
  • O código feito pelo Claude não será melhor do que o código humano. Ele apenas aumenta a velocidade de produção.
    O problema é que isso pode acabar aumentando só a produtividade de pessoas sem habilidade
  • Nos próximos anos, continuaremos sendo team leads de agentes de IA.
    Mas, se as empresas começarem a usar IA no papel de gerente, haverá menos espaço para desenvolvedores humanos.
    Precisamos começar desde já a nos preparar para migrar para papéis como consultor de eficiência com IA
  • Eu simplesmente pretendo colaborar com IA ou fazer outra coisa interessante. Programação não é tudo
  • Uma empresa com política de “AI doomer” é uma cultura organizacional tóxica. É melhor procurar outro emprego agora mesmo