O crachá chegou. Cinco anos de AWS, seis meses depois da data que ele comemora — a marca foi em janeiro; o objeto só chegou ao Brasil agora. Um marcador que aparece atrasado é um gatilho melhor que um número redondo: ele te faz contar quando você não estava esperando contar.

Então eu contei. E o que eu quero escrever aqui não são os cinco anos. É a virada embaixo deles.

2021: o que eu fui buscar

Eu tinha acabado de sair da Accenture depois de treze anos — a carreira começou lá, em 2008 — e ido para a Globo, para ir para um ambiente onde eu achava que ia aprender muito sobre engenharia de software.

O que eu encontrei lá não foi decepção; foi informação. Entrei como DevOps e, em algum momento, virei referência em aplicação — fora da vaga em que eu tinha entrado. Foi assim que eu descobri que gostava de aplicação e que sentia falta disso. Ninguém me alocou nesse papel. Ele aconteceu ao lado da alocação.

E o que eu quis da AWS depois disso era específico: hiperexposição a tecnologia de ponta, me tornar cloud native, trabalhar com cloud pública todos os dias. Era isso que eu buscava na ida.

Agora a parte menos elegante e mais útil. Quando eu fui para a AWS e para o ProServe, eu não sabia a diferença entre as vagas de Solution Architect e de ProServe Cloud Application Architect. O que eu vi foi uma vantagem: eu tinha anos de business de consultoria nas costas, e dava para perceber que aquilo seria um diferencial para o ProServe. Ou seja, escolhi pelo lugar onde meu histórico valia mais, não por entender a vaga.

Se você está lendo isto no meio da sua própria virada, é provável que esteja exatamente aí — olhando portas que você não consegue diferenciar e decidindo pela porta em que você tem chance. Isso não é falta de pesquisa. É o que a informação disponível para um candidato realmente sustenta.

O que eu encontrei

Funcionou, e eu falo isso sem rodeio, porque a versão honesta de uma virada precisa incluir a parte que deu certo.

Eu pude realmente ter contato com tecnologia de ponta, finalmente sedimentar meus conhecimentos em AWS, construir coisas novas e ter uma prática bem maior de Terraform. Esses eram meus objetivos, e era o que me dava prazer naquele momento.

Lê de novo essa última expressão, porque eu escolhi ela de propósito. Naquele momento. Tudo ali era verdade, e continuou sendo verdade por anos. O assunto deste texto é o que mudou depois.

O que mudou, e por que isso é estrutural

Com o tempo eu fui vendo que os projetos de cloud enablement são muito parecidos no geral. Eu acabava pegando clientes em primeiro contato com cloud pública, logo depois de estabilizar a landing zone da AWS.

Essa frase parece reclamação e não é. É a descrição de uma curva. Os engajamentos se repetem porque os clientes estão no mesmo ponto dela — mesmo problema, nomes de empresa diferentes. A variação está nas logomarcas e nos organogramas, não no problema que está sendo resolvido.

E é essa distinção que importa, porque as duas coisas são idênticas por dentro e pedem respostas opostas. Cansaço é sobre você. Você está cansado, precisa de uma pausa, e em três meses o trabalho volta a ser interessante. Repetição estrutural é sobre o trabalho. Descanso nenhum resolve, porque não havia nada ali que fosse variar.

A hiperexposição entregou exatamente o que eu pedi dela: profundidade. O que ela parou de entregar foi problema novo. Foi assim que eu cheguei a um ponto em que não via mais desenvolvimento técnico para mim como application architect — depois de um tempo nos tipos de engajamento em que eu geralmente estou envolvido. Não o papel esgotado no abstrato. O papel, dentro daquele tipo de engajamento.

A segunda vez, não a primeira

Escrevendo isso, a forma é familiar — e essa é a parte que eu não enxerguei enquanto estava acontecendo.

A Globo foi um teto dentro de um papel, e o caminho para além dele estava fora da vaga em que eu entrei. A AWS é um teto dentro de um papel, e o trabalho que me leva além dele está, de novo, fora do que eu estou alocado para fazer. Duas vezes, o crescimento técnico veio de um lugar onde ninguém me alocou.

Nas duas eu percebi antes de virar ressentimento, e nas duas o que eu mudei foi o objeto do trabalho, não a empresa — eu não passei dois anos reclamando e chamando isso de plano. Não tenho certeza de que isso qualifica como método. Pode ser só o que acontece quando você presta atenção no que realmente te interessa. Mas é um padrão, e ele se repetiu limpo o bastante para eu sugerir a um par que procure por ele no próprio histórico.

O desafio de agora

Eu vejo muitos problemas parecidos ao longo do tempo, e quero continuar me desenvolvendo tecnicamente.

AI engineering é o que está me permitindo ir além. E eu quero ser exato sobre o que isso significa, porque é fácil fazer soar mais do que é: não é a minha atividade principal em projetos. É essa a afirmação inteira. Não é escondido, não é à revelia de nada — simplesmente não é sobre isso que os engajamentos em que eu estou tratam.

E o motivo de acontecer assim mesmo é bem mais simples que uma estratégia. Eu estou indo além do horário comercial ao longo de vários dias porque me empolguei com as possibilidades de trabalho com IA. É esse o motor — entusiasmo passando na frente da alocação, que foi exatamente o que aconteceu da primeira vez também.

O que eu não tenho

Eu não tenho o final. Estou empregado, não estou anunciando nada, e não tomei a decisão que este texto parece estar construindo.

O que eu tenho é um teto que eu consigo descrever com precisão, uma prática paralela que é real, sem glamour e que acontece quase sempre fora do horário, e dezoito anos embaixo das duas coisas que fazem da novidade uma extensão e não um recomeço.

Se você está em algum lugar parecido — o papel está ok, o problema parou de variar, e o trabalho interessante está acontecendo ao lado da sua alocação em vez de dentro dela —, vale nomear isso em voz alta antes que vire outra coisa pior. Você não precisa ter decidido nada ainda. Eu não decidi.