No dia 1° de julho de 2002, por volta de 19 horas, momento em que esse post será publicado, eu estava chegando em casa do meu primeiro dia de trabalho na Petrobras.

Hoje contarei um pouco desse início, os primeiros anos da minha carreira foram decisivos para o resto dessa jornada.

O Brasil estava de ressaca, eu também. Era dia 1° de Julho de 2002, e na véspera a seleção brasileira havia recebido o caneco pelo pentacampeonato, após vencer a Alemanha.

Como eu morava em Campos dos Goytacazes, minha cidade natal, que fica ao norte do estado do Rio de Janeiro, me dirigi, por volta das 5:30 da manhã para o ponto de encontro de onde saiam os ônibus para a Petrobras. Por volta das 6 os ônibus partiriam em comboio para a Petrobras, em Macaé, cidade próxima onde ficava a sede. Cheguei por volta das 7:30.

Que lugar absurdamente grande! Nunca havia visto uma empresa tão grande.

Em menos de 1 hora eu estava sentado em uma estação de trabalho. Ainda sem saber o que tinha de fazer. Sem saber nada. Eu só sabia que estava empregado, mas ainda tinha muito medo pois eu não conhecia nada. E ao meu lado coexistiam desenvolvedores com 10, 15, 20 anos de experiência.

Do ponto de vista de tecnologia era um playground. Tudo ali era megalomaníaco. Servidor de banco? Um mega cluster, da nasa! Infraestrutura de servidores de aplicação. Idem!

Tudo, por onde você pensar era desenhado para ser best in class.

Minha estratégia

A sensação que eu tinha era a de que eu era um espião. Minha missão, aprender o máximo possível sobre tudo que havia naquele lugar antes de ser descoberto.

Na prática, eu estava inseguro, sabia ser meu primeiro trabalho como desenvolvedor, e não tinha experiência prévia em grandes times. Julgando todos ao meu redor melhores que eu, ficou fácil desenhar uma estratégia.

De trabalho a escola

Não demorou muito para eu começar a me entender, a curiosidade de saber como todos faziam tudo, me permitiu crescer muito rápido.

Eu não parei! Eu trabalhava, e quando chegava em casa estudava algo que havia visto durante o dia. Eu tentava entender termos que nunca havia visto e assim transformei meu trabalho em uma grande escola.

Projeção

Minha forma de estudar sempre foi peculiar. Eu gostava de física, matemática, havia tirado ótimas notas alguns anos atrás, mas sem nunca me dedicar profundamente a estudar.

A mágica para isso era simples: precisa fazer sentido.

Minha “definition of done” quando o assunto é estudar, consiste em só parar de estudar quando aquilo fizer tanto sentido quanto o básico de física newtoniana, que aprendemos nos primeiros anos de vida, e confirmamos o entendimento na escola.

Ou seja: se cuspir para cima, cairá no olho!

Brincadeiras à parte, isso é muito sério. Somente quando um assunto faz sentido, tem sentido lógico, é quando eu me dou por satisfeito.

E para isso é preciso cortar pontas soltas. É preciso preencher lacunas e gaps de desconhecimento.

Isso foi absolutamente fantástico para aprender a programar, mas também para aprender diversas outras coisas.

Eu não entendia como modelar banco: então eu queria entender o porquê das coisas. Eu fazia as perguntas para conseguir alcançar o entendimento necessário para fazer sentido.

Ao mesmo tempo, tendo uma equipe de DBA’s ao lado, poderia perguntar coisas sobre o Oracle. Especificidades que poderia perguntar se eram do Oracle ou daquela instalação em específico.

Fiz isso com Javascript, com banco de dados, com Windows server, IIS, e uma zilhão de outras tecnologias, conceitos e ferramentas.

Aquilo era um parque de diversões.

Além de pentelhar e perguntar eu também fazia muito. Era especialmente dedicado a não passar um dia sequer sem algo novo. Sem aprender algo novo, sem tentar fazer algo novo. Mesmo naquele ambiente cheio de regras.

Então eu dediquei algum tempo a entender quais eram as regras. E graças a pessoas com absoluta paciência, como Mario Muller, Mauricio Sellis e Nelson Mansur essas regras foram fazendo sentido.

E eu fui aprendendo a jogar no limite da minha competência.

E não é que saíram coisas legais?

Me lembro que por conta da falta de atenção, correções bobas como trocar um nome de coluna produzia uma dúzia de bugs chatos.

Eu alterava em um lugar esquecia do outro, do outro , do outro.

Isso me irritava em um nível absurdo, porque eu falhava em fazer meu trabalho quando esses erros ocorriam.

Foi então que tive a ideia de simplificar esse processo, utilizando a estratégia de criar uma forma mais simples de propagar esse nome nas malditas telas de CRUD.

Eram tantas, tantas…

Enfim, eu criei um grid que simplificava a forma de desenvolver.

Ao mesmo tempo, eu brincava com javascript, colocando novas propriedades em cada TR do html, possibilitando ter uma tela interativa, e dinâmica. Poucas configurações faziam a mágica acontecer. E assim eu desenvolvia muito mais rápido e com muito menos erros.

Ao mesmo passo um erro era centralizado e uma vez corrigida a grid, todo o sistema se beneficiaria da correção ou da evolução.

Ao mesmo, com poucos meses eu já ajudava outros desenvolvedores, mais experientes que eu até.

E eu fazia isso compartilhando cada novidade com Mario e Maurício, até que de tanto pentelhar eles resolveram me chamar para o time.

Eu não havia dito até agora mas era o time de suporte ao desenvolvimento. Um time de arquitetura. Eu era “o estagiário” ali.

Ok, não era um estágio, mas era meio que assim que eu me sentia no meio de Titãs.

Entender o motivo pelo qual decisões estratégicas são tomadas muda muito como você percebe qualidade.

Normalmente o dev considera o arquiteto quase que um tirando limitador. Sem ter em mente que a liberdade absoluta produz caos que é impossível de reverter sem ter de quebrar tudo.

A dose certa dessas duas forças: Liberdade e Governança é a alquimia que se tenta obter para que o projeto tenha sucesso.

Nem só liberdade, nem só governança.

Um trabalho bem conduzido, é silencioso

O trabalho do arquiteto, se bem feito, tem como resultado bugs simples, do dia-a-dia, coisas bobas pegas geralmente bem antes de chegar em produção.

Erros encontrados em produção são em geral erros de negócio, e raramente graves, ou que requererem restruturação de toda uma funcionalidade por questões técnicas. Se precisar restruturar tudo, deveria ser por conta de algo relacionado ao negócio, não pela arquitetura.

O papel do arquiteto é facilitar a vida dos devs permitindo com que eles sejam mais eficientes, sem limitar muito sua autonomia criativa, mas sem deixar aquilo virar um caos onde cada um faz o que quer e bem entende.

Por isso é importante ter meios de rastrear aquilo que foi feito, quais os desafios, quais as questões envolvidas para se chegar até aquele estado. Daí nasceu a ideia de um decision log. Que hoje vocês podem ver, que me acompanha em diversos projetos.

Há momentos em que é necessário expressar o caminho por onde você passou. De um lado é fácil esquecer, de outro é fácil não entenderem o que você faz dia-a-dia. Ter algo estruturado ajuda a dar clareza.

Muito aprendizado

Foi sem sombra de dúvidas o momento de maior aprendizado da minha carreira. Aprendi muito, com muita gente.

Agradeço ao Allan Costa que além de primo da minha namorada na época, levou meu currículo para a Petrobras e a outras dezenas de nomes que me ajudaram nesse processo.

Em 2005 foi o momento de dizer adeus à Unidade de Negócios Bacia de Campos, UNBC, e vir para o Rio. Decisão da qual sou muito feliz de ter tomado.

Nessa saída, uma coisa inusitada aconteceu.

O Ivancleber, um dos meus melhores amigos na época, gravou uma série de depoimentos no estilo arquivo confidencial.

Alguns deles estão aqui abaixo:

Muitos outros eu perdi em um HD velho que se corrompeu.

E não faz mais de 1 ano que me dei conta que o trabalho de ajudar a comunidade sempre esteve no meu DNA. Desde quando a comunidade que eu estava inserido era naniquinha, regional, local.

Hoje somos milhares!

Se esse post te ajudou de alguma forma, comente. Se você fez parte de algum desses momentos, comente também. Ficarei muito feliz em ver seu comentário!