A alegria e o poder de compreender

• Quando você entende software em profundidade, não é arrastado pelas ferramentas e pode ter controle e propriedade sobre o sistema pelo qual é responsável
• Busca e LLMs dão respostas rápidas, mas o hábito de copiar soluções que você não consegue explicar pode enfraquecer sua capacidade de corrigir problemas e sua competência essencial
• Em scripts descartáveis ou UIs internas de baixo risco, gerar e copiar/colar pode ser razoável, mas código que será mantido por muito tempo deve ser feito com uma tecnologia que você conheça a fundo
• Medir produtividade apenas por output, como linhas de código ou número de PRs, distorce facilmente a realidade; outcomes como releases estáveis, simplificação, automação e testes estão mais próximos do valor de longo prazo
• O software moderno ficou mais complexo, de runtime, rede, segurança e banco de dados até IA, mas aprender os princípios fundamentais permite entender novas ferramentas e abordagens mais rapidamente

---

O controle e a alegria que vêm da compreensão

• Compreensão profunda é uma condição prática para corrigir e mudar código e sistemas
• É difícil corrigir ou alterar algo que você não entende e, no fim, isso também enfraquece seu controle e senso de propriedade sobre o código pelo qual você é responsável
• Compreender não só faz de você o dono das ferramentas, como também traz satisfação psicológica
• É natural ver uma ligação entre emoções positivas e ações que permitem controlar melhor o próprio ambiente

A preguiça humana e a dependência de LLMs

• O ser humano tende a reduzir o gasto de energia e maximizar a recompensa em relação ao investimento
• Essa preguiça motiva a automação de tarefas tediosas e caras, mas pode se tornar uma fraqueza em aprendizado e desenvolvimento de habilidade
• Com a internet e os LLMs, ficou fácil obter respostas para problemas parecidos no formato desejado, o que facilita pular o processo de compreensão
• Em vez de aprender SQL de fato, você pode dizer ao LLM quais são as tabelas e quais dados deseja, copiar o resultado e seguir em frente; no curto prazo é mais fácil, mas a capacidade real de lidar com isso não se acumula
• Mesmo que o LLM produza SQL mais rápido, a capacidade de leitura e compreensão construída no passado por repetição direta diminui se não for usada
• LLMs e mecanismos de busca são, no melhor cenário, um amplificador de capacidade (force multiplier), mas isso exige uma base forte antes
• Habilidades e conhecimentos centrais são difíceis de manter apenas com busca, prompts e validação manual; é preciso participar diretamente do processo de construir e criar
• É preciso combater regularmente essa tendência à preguiça: ler documentação e código-fonte, entender por que a solução funciona e quais são os trade-offs das ferramentas, além de projetar você mesmo soluções e algoritmos

Equilíbrio entre produtividade de curto prazo e compreensão de longo prazo

• Nem todo código e toda solução precisam ser entendidos completamente, e o critério pode variar conforme o contexto
• Scripts descartáveis de baixa importância e baixo risco podem ser copiados ou gerados sem problema
• O mesmo pode valer para uma UI ou página interna usada por duas ou três pessoas
• Já o código que você vai possuir, manter e evoluir por meses ou anos deve ser feito com linguagens e tecnologias que você conhece profundamente
  • Você deve entender cada linha, palavra, caractere e opção de configuração, ou caminhar nessa direção
  • Mais importante do que produzir muito agora é otimizar a compreensão, a manutenibilidade e a produtividade de longo prazo
• Em casos como MVPs ou funcionalidades experimentais dentro de um produto existente, quando o sucesso ainda é incerto, é possível baixar um pouco o padrão de qualidade e compreensão
• Essa escolha se parece com assumir uma dívida cognitiva
  • Agora você consegue se mover mais rápido
  • Mas, quando o produto ou a funcionalidade precisar funcionar de verdade ou passar por correções e mudanças, o custo a pagar depois será maior
• Ainda assim, no mínimo, é preciso entender e validar o suficiente para poder dizer com confiança: “funciona”
• Em alguns casos, pode ser razoável gerar primeiro, validar e depois reescrever do zero

O efeito composto da stack tecnológica e da proficiência

• Se for uma linguagem de programação, biblioteca ou ferramenta que você usa só de vez em quando, não é necessário investir muito tempo em aprendizado profundo e proficiência
• Se você consegue validar o resultado, às vezes também é aceitável copiar ou gerar algo entendido apenas em parte
• Mas, ao pular a etapa de aprendizado e esforço, você reduz por conta própria a chance de se tornar realmente proficiente e produtivo com aquela tecnologia
• Na stack tecnológica central que você usa com frequência, a proficiência pode ser recompensada centenas ou milhares de vezes
• Conhecimento e habilidade têm efeito composto
  • Quanto mais você sabe, mais rápido consegue construir por conta própria
  • Também consegue aprender novas habilidades e conhecimentos cada vez mais rápido
  • À medida que sua capacidade cresce, você passa a imaginar novas soluções e ideias

Produtividade orientada a outcome, não apenas a output

• As formas de entender e medir produtividade se dividem, em grande parte, entre uma visão centrada em output e outra centrada em outcome
• Medir output é fácil e simples de contar em números
  • Linhas de código produzidas
  • Número de PRs abertos e mesclados
  • Número de funcionalidades implementadas
  • Número de bugs encontrados e corrigidos
  • Número de tarefas concluídas
• Métricas centradas em output podem ser manipuladas com facilidade
  • Dá para escrever código verboso
  • Dá para criar muitos PRs pequenos
  • Dá para dividir tarefas artificialmente
  • Dá para adicionar funcionalidades inúteis
• Mesmo que os números cresçam, é difícil garantir que a direção seja a correta
  • Mais PRs não significa necessariamente algo melhor
  • Um codebase maior nem sempre é desejável
  • Em vez de adicionar funcionalidades, pode ser melhor remover as que ninguém usa
• Exemplos centrados em outcome se conectam mais diretamente ao valor de longo prazo
  • Um novo processo de CI/CD torna os releases em produção mais estáveis
  • Refatoração e simplificação facilitam manutenção e mudanças futuras
  • O redesenho de uma solução de integração acelera a entrada de novos parceiros e economiza recursos computacionais
  • Aumentar os testes ajuda a detectar bugs antes e evita regressões
  • Adicionar métricas e alertas permite encontrar preventivamente problemas e bugs em potencial
  • Automatizar trabalho manual e tedioso economiza tempo e reduz a chance de erros críticos
• Produtividade e compreensão de longo prazo combinam melhor com métricas centradas em outcome, e mais output nem sempre significa algo melhor

Software cada vez mais complexo e princípios fundamentais

• O teorema fundamental da engenharia de software costuma ser resumido assim: “qualquer problema da ciência da computação pode ser resolvido com outra camada de indireção, exceto o problema de camadas demais de indireção”
• O desenvolvimento moderno de software é extremamente complexo por causa de suas muitas camadas e elementos
  • Runtime e plataformas: navegador, servidor, nuvem, mobile, desktop, embarcado
  • Redes: HTTP, DNS, TLS, TCP, UDP, IP, WebSockets, WebRTC, protocolos de bancos de dados e brokers de mensagens
  • Segurança, autenticação e autorização
  • Sistemas operacionais
  • Virtualização, conteinerização, orquestração da família Kubernetes
  • Bancos de dados: SQL, NoSQL, local, remoto, distribuído
  • Linguagens de programação de alto nível e pipelines de compiladores, interpretadores e transpilers
  • Bibliotecas, frameworks, gerenciadores de pacotes
  • APIs e serviços externos
  • CI/CD, TDD, BDD, GitOps, IaC, DDD, EDA, Event Sourcing, CQRS, SSR, CSR, Clean Architecture, Hexagonal Architecture, Modular Monolith, Microservices, Microfrontends
  • LLMs e IA
• Também há motivos para acreditar que essa complexidade pode ser enfrentada
  • Muitos sistemas são excessivamente projetados e podem ser simplificados de forma significativa
  • Em um determinado período, normalmente basta dominar com profundidade apenas uma pequena parte do cenário de desenvolvimento de software
  • Para o restante, um nível de familiaridade já pode ser suficiente
  • Aprender os padrões e princípios gerais por trás das ferramentas cria alavancagem para aprender novas ferramentas, abordagens e tecnologias

O alcance e o efeito dos princípios fundamentais

• Princípios fundamentais são as regras, restrições e mecanismos básicos e relativamente estáveis que estão por baixo de ferramentas, bibliotecas, frameworks, protocolos e componentes usados no desenvolvimento de software
• O escopo central inclui várias áreas
  • Arquitetura de computadores e hardware: estrutura de CPU, execução de instruções, hierarquia de memória, registradores, cache, dispositivos de armazenamento
  • Linguagem de máquina, assembly e linguagens de alto nível: por que assemblers, compiladores e interpretadores são necessários e quais são os trade-offs entre tipos de linguagem
  • Sistemas operacionais: processos, threads, escalonamento, locks, sincronização, memória virtual, sistemas de arquivos, IPC, system calls, I/O
  • Algoritmos, estruturas de dados e análise de complexidade
  • Redes: comunicação entre computadores, confiabilidade, throughput, latência, estrutura em camadas
  • Bancos de dados e sistemas de dados: ACID, transações, níveis de isolamento, índices, formas de armazenamento, relacionamentos, modelagem de dados
  • Design e arquitetura de software: modularidade, gestão de dependências e responsabilidades, ocultação de informação, encapsulamento, camadas, cliente-servidor, eventos, acoplamento e coesão
  • Estado e fluxo de dados: identidade, fonte única da verdade, resolução de conflitos, cache e memoization, invalidação de estado, máquinas de estado, consistência e sincronização
  • Sistemas distribuídos: teorema CAP, replicação, latência, partições, consenso, service discovery, consistência eventual
  • Concorrência e paralelismo: locks, sincronização, potencial de paralelização, condições de corrida, deadlocks
• Não é necessário, e talvez nem possível, dominar todas essas áreas, mas o objetivo deve ser conhecer um pouco de cada uma e se destacar em algumas escolhidas
• Focar nos princípios fundamentais gera, com o tempo, a meta-habilidade de uma intuição universal
• Quando você entende profundamente como computação e computadores funcionam sozinhos e em cluster, passa a ser menos levado pelos detalhes de ferramentas e frameworks que mudam o tempo todo
• Nesse nível, aprender uma nova ferramenta da moda também se torna muito mais fácil

A alegria da compreensão e seu impacto

• Como disse Leonardo da Vinci, “o mais nobre prazer é a alegria de compreender”
• No desenvolvimento de software, compreender não traz apenas prazer, mas também influência prática e poder
• O campo da engenharia de software é muito amplo, mas, ao focar nos princípios fundamentais, a área que você consegue dominar se expande
• A postura de empurrar continuamente os próprios limites cognitivos leva a uma alegria recorrente e a uma ampliação de impacto

[GN⁺]

Comentários do Lobste.rs

• Gostei muito do tom geral deste post do blog
  Hoje em dia vejo com frequência demais textos no estilo “construí uma ferramenta sem nem saber o que está acontecendo por dentro”, e cansei desse clima de tratar isso como motivo de orgulho

  • Concordo. Compreensão profunda é o que realmente cria vantagem e leva a novas ideias e insights
    Além disso, o próprio processo é muito prazeroso

• Foi um texto interessante, e acho que essa tendência de pressionar as pessoas a produzir resultados que elas não entendem é até certo ponto intencional
  Do ponto de vista dos laboratórios de IA, há motivos econômicos claros. Se as pessoas passarem a depender dos produtos deles, aí sim podem começar a justificar suas valuations, e enfraquecer a capacidade dos usuários é uma das formas de fazer isso
  Coincidentemente escrevi hoje um texto parecido, compartilhando a mesma premissa central sobre a alegria de realmente aprender algo e dominá-lo: https://hgrsd.nl/blog/simplicity-agency-and-mastery/

  • Obrigado por compartilhar o texto. O ponto sobre autonomia e efeito bola de neve foi especialmente bom
    Nunca devemos abrir mão da autonomia, e quanto mais sabemos e conseguimos fazer, mais passamos a saber e conseguir fazer. Isso cria um ciclo virtuoso realmente bonito e positivo

• Fiquei feliz de este texto não ter recebido a assustadora tag vibecoding. Na verdade, esse tipo de assunto vem sendo discutido há décadas em versões mais curtas e geralmente mais resmungonas
  Software é assustadoramente complexo, então existem muitos atalhos cognitivos, e em certo ponto eles são até necessários para sobreviver. Mas as pessoas tendem a ficar mais preguiçosas do que deveriam justamente quando precisariam ter mais cuidado. Computadores combinam bem com modularização rígida, mas pessoas não
  Gostei que o texto enfatiza a compreensão não como uma simples “obrigação”, mas como o quanto é divertido entender como algo funciona. Talvez existam pessoas que não gostem de entender o mundo, mas isso é tão central para a minha personalidade que quase soa apenas teórico. Sem esse prazer, talvez valha repensar antes de começar uma carreira em software

  • Eu vejo a tag vibecoding neste texto
    Hoje em dia quase todo texto acaba recebendo a tag vibecoding, então talvez fizesse mais sentido inverter a ideia e introduzir uma tag non-vibecoding. Ela seria usada para textos que não são sobre vibe coding ou que falam das vantagens de vibe coding, e o resto ficaria como está. Infelizmente isso parece o novo padrão
    É um bom texto que também combina com o “vibe” dos meus sentimentos

• Eu realmente gosto de aprender, e o texto trata dessa situação de “gerar algo que você só entende parcialmente e depois precisar gastar mais tempo para compreendê-lo”, e pessoalmente eu não desgosto desse tipo de dívida cognitiva
  Se for uma área de problema que me interessa, estou disposto a investir tempo para pagar essa dívida e chegar à compreensão. No fim, isso parece apenas outro caminho para chegar ao mesmo entendimento
  Também me lembra o conceito de lean startup. Quando há algo visível, você pode começar examinando um objeto concreto, em vez de ficar diante de uma tela em branco tentando adivinhar o que importa. Não saber por onde começar é pior, e a IA pode ajudar a dar a partida rapidamente
  A parte que ainda não consigo organizar bem é como juniores com pouca experiência desenvolvem intuição para perceber maus cheiros e contestá-los. Minha forma de usar IA é muito iterativa, e trato isso como um questionamento socrático para melhorar. É bem diferente do mundo do vibe coding one-shot possível com as ferramentas atuais

  • Sobre a parte “como juniores com pouca experiência desenvolvem intuição para perceber maus cheiros e contestá-los”, tenho amigos próximos e familiares que entraram na área no fim do ano passado
    Na prática, acho que não é tão diferente de antes. Pessoas mais seniores vão orientar e contestar, e a maioria das empresas de tecnologia também tem revisão por pares. Então o júnior não está completamente sozinho. Na verdade, ainda há bastante tempo para errar e se adaptar

• Gostei que ele listou bastante vários temas fundamentais
  É fácil para o leitor imaginar isso como uma técnica retórica tipo Gish gallop ou parading of horribles, mas na realidade acho que existem dezenas de teorias fundamentais se cruzando em cada momento das nossas vidas
  Computadores também não são programados a partir de uma teoria unificada; estão mais para um diagrama de inclusão de conjuntos sobrepostos, com muitas pequenas teorias remendadas umas às outras

• Li o texto com muito prazer e atenção, e também o compartilhei com alguns amigos
  Como está cada vez mais difícil desacelerar, também escrevi https://writing.tidefield.dev/hello-world-again/#honing-my-focus sobre meu compromisso público com o aprendizado fundamental no ano novo
  Fico contente de ver a mesma direção em “depois de 2026, vou estudar coisas fundamentais e que não passem de moda rapidamente...”