Inspirada no livro The Clean Coder, de Robert C. Martin (o famoso Uncle Bob), esse conteúdo traz uma reflexão que vai muito além de frameworks, linguagens ou arquitetura. Falamos de postura. De responsabilidade. De caráter profissional.
E talvez da pergunta mais desconfortável de todas:
👉 Você está apenas escrevendo código ou está construindo uma carreira?
O livro que muda a forma como você se enxerga
Diferente de obras técnicas, The Clean Coder foca em comportamento. É o tipo de leitura que provoca um efeito curioso: você se reconhece em várias situações… e nem sempre gosta do que vê.
Isso acontece porque o livro expõe uma verdade simples:
Profissionalismo não está no discurso. Está nas atitudes diárias.
Quase todo mundo quer ser respeitado, reconhecido e bem pago. Mas existe um preço invisível que acompanha esses desejos: responsabilidade real pelo que você entrega.
Responsabilidade anda de mãos dadas com qualidade
Ninguém acorda pensando “quero ser um profissional medíocre”. Ainda assim, a diferença entre quem cresce e quem estagna costuma aparecer quando algo dá errado.
Imagine o cenário:
- Você sobe uma alteração.
- Todos os testes passam.
- Code review aprovado.
- Deploy feito.
Horas depois, alertas começam a disparar.
O problema só aparece em produção por causa da alta concorrência. O impacto se espalha para outros sistemas. Clientes são afetados.
E agora?
O profissional não diz:
“Já reverti. Não é mais comigo.”
Ele pergunta:
👉 Como posso ajudar a resolver?
Mesmo que a correção já tenha sido aplicada, assumir responsabilidade significa investigar, apoiar outros times, extrair dados, entender impactos e participar da solução.
Não é sobre pagar pelo prejuízo.
É sobre sentir o peso dele como se fosse seu.
Quando isso acontece, algo muda na sua mentalidade.
Atitudes práticas de quem assume responsabilidade
1. Antecipar problemas
Se você sabe que uma biblioteca ficará obsoleta em seis meses, não é um problema futuro. Já é um problema presente.
Adiar só transforma um ajuste planejado em um incêndio.
Profissionais alertam cedo, apresentam impactos e sugerem caminhos.
2. Ser realista
Estimativas erradas acontecem. O erro está em esconder a realidade.
Se aquela tarefa de três dias virou uma armadilha no legado, sinalize.
Transparência constrói confiança.
3. Ter senso de dono (sem clichê)
Ownership não é bater no peito. É não desaparecer quando o sistema quebra.
As partes boas e ruins do software também são suas.
“Primeiro, não cause dano”
Uncle Bob faz uma analogia poderosa com o juramento médico.
Claro, software não salva vidas na maioria dos casos. Mas ele impacta negócios, carreiras e a rotina de milhares de pessoas.
Por isso, existem dois tipos principais de dano.
⚠️ Dano à função: os famosos bugs
Em sistemas grandes, bugs são inevitáveis. O trabalho do profissional é reduzir ao máximo essa probabilidade.
Como?
- Testando cenários reais
- Revisando com atenção
- Escrevendo código legível
- Garantindo rastreabilidade de problemas
Se um bug não está documentado, ele não existe para o planejamento. E o que não existe não pode ser priorizado.
⚠️ Dano à estrutura: o perigo silencioso
Aqui mora um dos maiores riscos de longo prazo.
Um software rígido vira uma prisão.
Se mudar uma pequena regra leva meses, o problema deixou de ser técnico. Virou risco de negócio.
A recomendação é simples:
👉 Trate o software como argila, não como vidro.
Argila é moldável. Vidro precisa quebrar para mudar.
Refatorar não é luxo. É estratégia de sobrevivência.
E esperar “o momento perfeito” para melhorar código é uma fantasia. Ele nunca chega.
Quando melhorar o código acelera o negócio
Um caso real ilustra bem isso.
Um time precisava adicionar um filtro em uma pipeline que processava milhões de eventos por hora.
O prazo era apertado.
A tentação era clara: só encaixar a solução e seguir.
Mas havia um problema: a estrutura já era complexa. Adicionar mais camadas aumentaria o risco.
A decisão foi investir um pouco mais de tempo para simplificar o fluxo.
Resultado?
Quando surgiu uma nova necessidade semanas depois, a alteração levou duas semanas, não três meses.
Velocidade não vem de atalhos.
Vem de estruturas flexíveis.
Sua carreira é sua responsabilidade
Essa parte costuma gerar silêncio na sala.
Seu empregador pode apoiar seu desenvolvimento, mas não é obrigação dele.
A carreira é sua.
Isso significa dominar o próprio campo:
- Design patterns
- Princípios de design
- Metodologias
- Integração contínua
- TDD
- Modelagem
- Diagramas
O básico precisa ser… básico.
Tecnologia evolui rápido, mas os fundamentos permanecem.
Ainda escrevemos software com condicionais e loops, como décadas atrás.
Nada é tão novo quanto parece.
Aprendizado contínuo não é opcional
Existe uma diferença importante:
👉 Trabalho é performance. Prática é evolução.
Uma banda não sobe ao palco para treinar.
Ela treina antes.
Seu dia de trabalho resolve problemas da empresa.
Seu tempo de estudo resolve o maior problema de todos: sua própria evolução.
A provocação do livro é forte:
Profissionais deveriam dedicar cerca de 20 horas semanais à prática.
Parece muito. Mas é investimento direto na sua capacidade de gerar valor.
E tem um detalhe importante: Aprender precisa ser divertido.
Quando deixa de ser, vira peso. E peso leva ao burnout.
Curiosamente, manter-se afiado é justamente o que ajuda a evitá-lo.
Outros traços que definem um profissional
Colaboração
Ensinar e aprender acontecem ao mesmo tempo. Times fortes não surgem por acaso.
Conhecimento do domínio
Quem desenvolve software para marketing precisa entender marketing. Sem contexto, decisões técnicas viram apostas.
Identificação com o problema
Os desafios da empresa também são seus. Esse vínculo muda o nível do seu comprometimento.
Humildade
O código não é seu. Ele pertence ao time.
Mas isso não diminui sua responsabilidade de cuidar bem dele.
No fim das contas…
Ser um programador profissional não é sobre nunca errar.
É sobre:
- assumir erros
- melhorar sistemas
- comunicar riscos
- estudar continuamente
- colaborar
- construir software que sobreviva ao tempo
É trocar a mentalidade de “entregar rápido” por “entregar certo e continuar rápido amanhã”.
Porque carreira sólida não se constrói só com deploys.
Se constrói com postura.
Uma reflexão para levar com você
Todo mundo gosta de reconhecimento, salário maior e crescimento.
Mas essas coisas costumam seguir quem faz uma escolha simples diariamente:
👉 agir como profissional, mesmo quando ninguém está olhando.
E talvez essa seja a verdadeira pergunta:
Você quer apenas escrever código… ou quer ser o tipo de pessoa que a engenharia confia para construir o futuro?
