Minha (longa) jornada para a senioridade

Tentando ser “Júnior”

Minha carreira como amador remunerado em programação começou em 1992. Eu tinha quase 13 anos e era menor aprendiz em uma pequena empresa na cidade onde nasci. Eu ajudava, como podia e sabia, a migrar um sistema escrito em Clipper para Joiner. Era, inquestionavelmente, o aprendiz do time. Todo mundo sabia mais do que eu e meu sonho era, um dia, programar tão bem quanto meus colegas.

Foi naquela época que eu entendi que, para ser um programador melhor, teria que saber mais sobre como as coisas funcionam. Simplesmente adorava os livros do Antônio Geraldo da Rocha Vidal (se alguém tiver notícias dele, me avise) e do Ramalho.

Também nessa época, era fascinado pelos livros do Peter Norton (caramba, ele já está com 76 anos), especialmente pelo “Guia de programação para PC e PS/2”. Passava horas tentando entender os códigos do Renato Degiovani nas edições antigas da revista Micro Sistemas.

Para mim, na época, programadores bons sabiam C e Assembly. Lembro-me de ter lido “C” Completo e Total incontáveis vezes em 1997.

Será que sou “pleno”?!

Foi só em 1998 (com quase 6 anos de “estrada”) que entendi que “saber mais” não me tornaria o melhor programador da sala. Afinal, mesmo “sabendo mais” do que meu chefe (sênior), não conseguia fazer coisas que ele conseguia. Entendi, de forma contundente, que não importa o quanto você conhece sobre programação, mas sim, o que você consegue fazer com o que sabe.

Foi necessário muito esforço, principalmente fora do horário de trabalho, para superar minhas deficiências e conseguir “ligar os pontos”. Precisei de muito tempo para melhorar meu conhecimento sobre o domínio. Durante anos, fui orientado sobre o “o quê” e o “como” precisava ser feito – mesmo com conhecimento, definitvamente não tinha autonomia.

Aos poucos, entretanto, fui “pegando o jeito”. Eventualmente, comecei a ter condições de ajudar colegas novos no time, com segurança, indicando como evitar “dores de cabeça”.

Naturalmente, consegui tornar-me contra-ponto honesto para meu “chefe-sênior” – alcançava, na minha avaliação, a plenitude. Não sabia muito mais sobre programação, mas definitivamente, entregava muito mais valor com o que eu sabia.

E a tal “senioridade”?

Como quase todos os programadores da minha época, fui fortemente influenciado por Design Patterns do GoF. Bastou a leitura das primeiras páginas para que eu fosse contaminado pelo vírus da “Patternite”. Escrevi infindáveis implementações de Singleton e só entendi que isso era errado muito mais tarde.

Lembro-me de ser obcecado com a ideia de seguir boas práticas. Queria “refatorar” , muitas vezes, tudo o que já havia escrito porque entendi, lendo Refactoring (do Martin Fowler) que o que eu tinha feito, defitivamente, não estava bom.

Por volta de 2002, eu era um pleno com embasamento raso que achava que tinha atingido a senioridade. Meu “mundo caiu” quando, em um embate com meu “chefe-sênior”, tentei apontar uma “melhor prática” como caminho a seguir. Ele me “quebrou” com duas perguntas: 1) Essa tal “melhor prática” vai reduzir nosso custo de implementação? e; 2) Essa tal “melhor prática” vai reduzir nosso custo de manutenção? …

Eu sabia que não tinha base suficiente para responder que “sim” para ele. Embora soubesse que minha linha de pensamento estava correta, não tinha desenvolvido solidez suficiente para sustentar minha posição.

Enfim, “sênior”!

Em 2008, quase 16 anos depois de começar a ser pago para escrever código, acredito ter, finalmente, atingido a senioridade. Considero esse ano como referência porque foi, até onde eu lembre, quando desenvolvi solidez para minhas argumentações. Curiosamente, foi quando entendi que jogar by the book não é sempre necessário. Aliás, chega a ser contraindicado!

De muitas formas, passei a entender boa parte das decisões do meu “chefe-senior” que considerava equivocadas. Vez ou outra, ainda me pego surpreso repetindo para alguém algo que ele me disse.

Só depois de mais de 15 anos diferentes (e não 1 ano repetido mais de 15 vezes), aprendi como fazer as “coisas certas do jeito certo”. Também aprendi a fazer as “coisas necessárias do jeito errado” … e está tudo bem!

Vez ou outra, vejo gente jovem, com menos de cinco anos de experiência argumentando já terem, também, atingido a senioridade. Essas novas gerações devem ter desenvolvido habilidades que os mais velhos, como eu, não conhecemos.


Já falamos nos “Drops da EximiaCo” sobre a “Qual a diferença entre um profissional ‘Pleno’ e um ‘Sênior’“. Confere lá.

Aproveita e deixa também seu feedback.

Compartilhe este insight:

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

Compete ao arquiteto corporativo a responsabilidade de descrever, analisar e comunicar os diversos aspectos da arquitetura corporativa, bem como registrar...
A palestra que ministrei no ano passado, na QCON, sobre compiladores, está disponível online. Fato curioso: Nesse dia, estava com...
Já está disponível o registro da conversa com os meninos da Lambda3, meus amigos Giovanni Bassi e Victor Cavalcante, sobre...
Como você pode se considerar um profissional se você não sabe se todo seu código funciona? Como você pode saber...
Eventualmente, é bom revisitar alguns temas clássicos de ciências da computação. Nesse post, vamos ver como detectar o nodo de...
Um dos benefícios mais bacanas do programa MVP é o direito a participação no MVP Global Summit – evento anual,...
Oferta de pré-venda!

Mentoria em
Arquitetura de Software

Práticas, padrões & técnicas para Arquitetura de Software, de maneira efetiva, com base em cenários reais para profissionais envolvidos no projeto e implantação de software.

× Precisa de ajuda?