Em uma empresa de tecnologia, as ferramentas são essenciais para viabilizar as plataformas, que possam ser reutilizadas de modo intencional, economizando recursos e potencializando a eficiência da organização. E os reflexos disso se estendem à cultura de aprendizagem da companhia e ao fomento da excelência técnica.
Para que plataformas possam ser usadas múltiplas vezes ou, para servir de alicerce para sistemas mais específicos, elas precisam ser encontráveis em algum repositório. Não adianta investir em uma plataforma reutilizável se ninguém conseguir localizá-la.
Quando o código é compartilhado por vários grupos da empresa, há diretórios e cada um deles possui um arquivo com o nome dos donos do código, as pessoas-chave que precisam autorizar modificações ali. As ferramentas que funcionam bem e de fato proporcionam ganho de produtividade são integradas, de modo que se possa fazer uma pesquisa (os diretórios são gigantes, há milhões e milhões de linhas de código em uma empresa) em uma ferramenta de busca para achar o que se quer.
Um dos usos para essa funcionalidade é a correção em série de erros de código, o que pode evitar incidentes. Mas o ponto mais importante é que ferramentas potencializam o aprendizado e a cultura de testes. Quando um desenvolvedor acha no repositório um arquivo que tem mais ou menos o que procura (uma plataforma, ou um módulo, que é algo menor) e lê o código, já tem acesso também aos testes que foram realizados, e que não só validam aquele código como servem de demonstração de sua funcionalidade. Um teste para validar uma aplicação demonstra como aquelas APIs são usadas, e o desenvolvedor consegue ler os testes e entender cada vez mais profundamente o sistema, de maneira independente.
A solução que um profissional criou, através da experimentação, vira parte do arcabouço computacional da engenharia para todos os times e passa a ser usada daquela forma dali em diante, reduzindo duplicidades futuras. Assim, as bibliotecas vão ficando cada vez mais completas conforme soluções novas vão sendo incorporadas, deixando os desenvolvedores mais disponíveis para se concentrar no diferencial do negócio.
Atuação e formação das lideranças técnicas
A padronização das ferramentas é essencial para que os engenheiros que avançaram no braço técnico da trilha de carreira em Y consigam exercer sua atividade de liderança de forma plena e decisiva, atuando diretamente no código, em vez de trabalhar apenas em cima de abstrações em uma lousa ou quadro branco.
Quando um engenheiro chega a staff (título usado em algumas empresas para contribuidores individuais, profissionais técnicos que não fazem gestão), já entende muito do sistema dele e passa a trabalhar em questões que envolvem várias áreas da empresa. Seu papel é definir padrões arquiteturais, tendo ideias de projetos estruturantes – um exemplo seria um sistema único de identidade de cliente para a empresa inteira, independentemente do produto –, cuja execução deve ser delegada a desenvolvedores mais júniores. O engenheiro especialista fica responsável então por mentorear essas pessoas e passa mais tempo revisando o código.
Quando alguém é recrutado no mercado, a uniformidade das ferramentas significa que esse profissional conseguirá se aclimatar mais rápido depois da contratação, tendo a capacidade de intervir prontamente em áreas diversas. Uma liderança de tecnologia que chega a uma empresa nova necessariamente tem muito o que aprender, e um alicerce de engenharia padronizado facilitará muito essa adaptação.
Existe mais de um caminho para contribuidores individuais em uma organização. A trajetória pode ser focada em uma atuação mais específica – alguém que escolha um pedaço complexo do negócio e vire um expert, passando a maior parte do tempo escrevendo e revisando código –, ou pode ser mais ampla, como a de alguém que deixou de escrever código há muito tempo e é o tipo engenheiro de quadro negro, que dá o direcionamento, integra equipes e faz com que as coisas funcionem, o tipo “arquiteto”.
Sem ferramentas de engenharia uniformizadas, a tendência é que a empresa fique com uma quantidade desproporcional de arquitetos e o código fique relegado a colaboradores muito júniores.
É positivo ter uma quantidade significativa de desenvolvedores sêniores que, mesmo em altos níveis de liderança, tenham um trabalho cotidiano de mão na massa, ou melhor, mão no código, lidando com códigos complicados e direcionando os desenvolvedores mais inexperientes.
Na concepção da gestão de empresa de tecnologia de forma intencional, é preferível que os profissionais sigam escrevendo código ao longo de seu percurso, conforme se aventuram em áreas diferentes da companhia, e isso só é possível quando existe um ferramental que facilite esse trânsito.
Uma organização pode ter sim os chamados arquitetos de software que não programam muito. São aqueles profissionais que estão pensando em tecnologias novas, focados em horizontes de inovação de mais longo prazo. Têm perfil para isso, uma visão macro e vocação para conduzir reuniões relevantes, convencer a cúpula da companhia das necessidades da área de tecnologia, falar publicamente em nome da empresa. A questão é que uma companhia precisa de pouquíssimos profissionais desse tipo, porque é em código que as coisas acontecem.
Assim, a existência e o uso cotidiano de ferramentas padronizadas é um fator determinante para que a trilha de carreira em Y seja efetiva em produzir especialistas técnicos para o topo da liderança e que participem diretamente no código, mantendo sua qualidade.

Marcus Fontoura
Marcus Fontoura é atualmente technical fellow na Microsoft e CTO do Azure Core. Iniciou a carreira na área de pesquisa da IBM em 2000, depois de concluir o doutorado na PUC-Rio e o pós-doutorado na Universidade de Princeton, nos Estados Unidos. Teve passagens pelo Yahoo! e pelo Google, e promoveu uma transformação digital na fintech brasileira StoneCo, onde atuou como CTO. É autor do livro Tecnologia Intencional e publisher da plataforma com o mesmo nome.