Conselhos para novos devs de software que leram todos aqueles outros ensaios de conselhos

Confiar em Conselhos e “Especialistas”

• Muitos comentários ecoam o ponto do ensaio: as pessoas são seguidas porque escrevem ou falam bem, não porque estejam certas.
• Isso se aplica a posts de blog, livros, YouTube e até saídas de LLMs; apresentação confiante ≠ correção.
• Vários pedem ceticismo sem cinismo: entenda o raciocínio e a “história de horror” por trás de qualquer boa prática (a analogia da Cerca de Chesterton).

Software, Valor de Negócio e Vendas

• Um debate recorrente: “software nunca gera dinheiro, apenas vendas geram.”
  • Os defensores dizem que software é um centro de custo e o lucro vem de transações e aquisição de clientes.
  • Os críticos respondem que software cria valor que é vendido ou alugado; em muitas empresas, o software claramente impulsiona a receita e a remuneração dos desenvolvedores reflete isso.
• Nuance de consenso: o contexto de negócio importa; a tecnologia existe para servir ao negócio, mas subvalorizar a engenharia leva a maus resultados e, com o tempo, à perda de pessoas.

Propósito do Software

• Surge uma afirmação forte: “o único propósito do software é automação.”
  • Os defensores estendem isso até videogames como imposição automatizada de regras.
  • Os opositores citam jogos, arte e usos não relacionados à automação como propósitos válidos; veem isso como um exagero dogmático.

Trabalho de um Desenvolvedor

• Tema popular: seu verdadeiro trabalho é resolver problemas de negócio/usuário, não “escrever código” ou “escrever mensagens no Slack”.
• Alguns argumentam que isso é exagero retórico; frequentemente é seu trabalho escrever código, mas o foco deve ser resolver o problema certo, às vezes não adicionando mais código.

Docs, Specs e Código-Fonte

• Um grupo defende ler a documentação “de ponta a ponta” e estudar o código-fonte das ferramentas principais; afirma que isso traz velocidade de longo prazo e “consciência do mapa”.
• Há forte reação contrária:
  • Specs/bibliotecas modernas têm milhares de páginas; é impossível ler ou reter tudo.
  • As pessoas têm estilos de aprendizado diferentes; muitas preferem leitura iterativa, guiada por problemas, ou uma passada rápida pelos sumários.
  • Compromisso sugerido: aprender profundamente um pequeno conjunto central de ferramentas, fazer uma leitura ampla e saber “onde procurar” depois.

Simplicidade vs Complexidade e o “Jeito Certo”

• Forte apoio a “não torne as coisas mais complicadas do que o necessário” (KISS).
  • Críticas à sobre-abstractização, à generalização prematura e a frameworks elaborados para projetos pequenos.
  • Histórias de “Caras do Jeito Certo” que impõem factories/builders/ORMs/staging para código trivial, ou enormes frameworks internos como garantia de emprego.
• Contraponto: projetos pequenos paralelos podem ser um lugar seguro para praticar infra e ferramentas “corretas”; o que parece exagero pode ser aprendizado deliberado.

Qualidade de Código, Manutenibilidade e Excelência

• Muitos preferem “código claro, funcional e fácil de depurar” em vez de código “inteligente” ou “excelente”.
• Divergência sobre “excelência”:
  • Alguns dizem que ela é real, mas perigosa (arrogância, over-engineering).
  • Outros argumentam que descartar a excelência é abraçar a mediocridade; o ponto é mirar soluções funcionais e mantíveis, não o ego.

Debugging, Leitura de Código e Ferramentas

• Vários comentários elogiam um certo livro de debugging e enfatizam debugging como habilidade profissional central.
• Conselho: aprenda a ler código bem (incluindo segui-lo passo a passo), não apenas escrevê-lo.
  • Uma visão: depuradores são uma ferramenta de aprendizado poderosa, como exercícios em um livro didático.
  • Outra visão: depender demais de depuradores é muleta; engenheiros seniores devem raciocinar sobre o código sem sempre executá-lo.

Colaboração, Revisões e Humildade

• Code reviews são vistas como de alto impacto: melhoram o código, ensinam habilidades de leitura e expõem problemas de design.
• Conselho para juniores:
  • Deixe o ego de lado, aceite críticas diretas, faça perguntas e admita erros cedo.
  • Entenda que “boas práticas” e decisões de arquitetura são contextuais; seniores podem estar certos por motivos não óbvios.

Saúde, Caminhadas e Carga Cognitiva

• O conselho de “fazer caminhadas” ressoa fortemente.
  • Pessoas relatam que caminhadas ou simplesmente olhar para um lago são poderosos para depurar mentalmente e lidar com o estresse.
• Ponto mais amplo: gerencie o “estado” na sua cabeça; externalize com anotações/wikis e proteja sua energia (evitando complexidade desnecessária).