Os melhores programadores com que trabalhei compartilhavam essas características

31 de Jan de 2022 — Diego Eis

Esse texto foi publicado primeiramente na PM Letter. A Newsletter sobre Gestão de Produto e negócios do Product Oversee.

Eu tive o prazer de trabalhar com alguns dos melhores programadores do Brasil nos últimos 20 anos. Hoje alguns deles trabalham nas maiores empresas do Brasil, mas grande parte está espalhada em outros países (Canadá, EUA, Portugal, Holanda).

O interessante era que embora eles fossem de empresas diferentes, todos compartilhavam características interessantes sobre como fazer tecnologia. Eu não sei se era coincidência da época e da escola daquela época (começo dos anos 2000) ou se isso era um padrão de bons programadores. De qualquer forma, me baseio até hoje nesses fundamentos para identificar bons programadores.

Acho que você já percebeu que eu não estou fazendo diferenciação entre front-end ou back-end, certo? Exatamente por que eu percebi que esses fundamentos se aplicam a bons programadores, pessoas que resolvem problemas com código, independente da especialização ou área que atua.

Eram disciplinados

Todos eles, sem exceção eram disciplinados quanto aos seus aprendizados, responsabilidades e principalmente execução técnica. Todos eles eram aficcionados por dados de performance do time, dados de monitoramento dos seus sistemas e impacto das suas entregas. Além dessa cultura disciplinada por resultados, eles eram disciplinados pela cultura de tecnologia e seus métodos.

Não é só ter uma cultura de coding review, parear com outros devs e se manter aos acordos do time, mas também de estar presente nas reuniões e rituais do time, de conseguir fazer trabalhos de análise e entrega de coisas que não eram necessariamente de código.

An undisciplined developer will not be able to ship on time and will not write code that is easy to maintain. A disciplined developer will not only enable the success of a project, but will raise the level of productivity in others. Software architects and developers do themselves a disservice when they attribute their success to whatever methodology they have adopted. It really boils down to how disciplined you are. Discipline Makes Strong Developers

Essa disciplina era transportada e refletida no código feito. Sem disciplina, ferramentas, linguagens, métodos são irrelevantes. Disciplina é uma forma de potencializar a produtividade. É tipo programação funcional que te obriga a seguir uma série de delimitações. De certa forma, te impõe uma disciplina. Mas essa é uma briga intensa e eu não sou programador para discutir se é melhor ou pior que orientação a objeto. :-)

Poliglotas

Era muito comum que cada um deles soubessem mais de uma ou duas linguagens de programação sem contar as comuns. Eles aprendiam os fundamentos da programação que estão presentes em qualquer uma das linguagens e depois escolhiam quais linguagens mais se adequavam ao problema e boas. Eles nem precisavam aprender a linguagem na íntegra, nem se tornar um especialista naquela linguagem.

Eu gosto de dizer que eles eram poliglotas generalistas: sabiam duas linguagens muito bem, e várias outras linguagens no limite de não serem identificados como programadores especialistas.

Todos eles tinham uma linguagem que mais gostava de codar. Óbvio que no início das carreiras eles procuravam empresas que usavam as linguagens que eles aprenderam em primeiro lugar. Ou aprendiam a mais popular na época e pronto. Mesmo assim, eles não eram agarrados à uma linguagem apenas, mas sabiam exatamente quais as linguagens eram melhores para determinados problemas.

Aprender várias linguagens não é só questão de resolver problemas mais fácil, mas de aumentar o repertório de soluções. Isso força o programador a aprender novos princípios, patterns, deixa o programador mais criativo para solucionar problemas de formas diferentes.

Tinham visão do todo, não apenas do código

Esse é até hoje um problema dessa área. Programadores medianos geralmente tem uma visão muito focada em código, no que eles estão fazendo agora, não no que irão fazer depois e quase nunca se preocupam com o impacto do trabalho deles no negócio.

Ter uma visão do todo começa entendendo que você faz parte de um time que não é formado apenas por programadores, que você faz parte de uma empresa que a estrutura é formada por outras especialidades fora da área de tecnologia. Que o negócio existe para cumprir com um propósito. Todo o código escrito, serve para deixar a empresa mais perto desse propósito, que serve para fortalecer a proposta de valor entregue para os clientes.

Ter a visão do todo ajuda a identificar os timings que a empresa e principalmente seu time está passando. Sabendo quais os momentos a empresa, produto e time está passando, traz consciência de como é possível ajudar com responsabilidades além do código. Nem toda solução vem do código, mas também de conversas e relacionamentos. E não me venha com essa de que programador não deve conversar, pelo contrário. A maioria dos melhores líderes técnicos que eu conheço passava muito tempo conversando, seja com outros programadores ou até mesmo com pessoas fora da área de tecnologia.

Ensinavam muito

Todos eles dedicavam uma parte relevante do seu tempo para treinar pessoas que tinham acabado de chegar na empresa ou até mesmo na área. Obviamente, existiam os programadores mais experientes que só gostavam de falar com outros do seu nível. Esses aí caiam facilmente no esquecimento, embora a empresa os mantivesse porque eram bons no que faziam, mas claramente tinham menos valor do que aqueles que investem seu tempo para criar novos bons programadores.

Se você é novato em programação e está sendo entrevistado em alguma empresa, pergunte como os seniors ensinam programadores novatos.

Manjavam de processos

Todos os ótimos e grandes programadores manjavam de processos. Hoje, é muito comum um programador nem saber a diferença de Kanban e Scrum. É triste. Muitos acham que o processo foi feito para atravancar seu dia.

Os melhores programadores que eu já trabalhei, não precisavam de um Agilista perguntando o que ele fez no dia anterior, que vai fazer hoje e amanhã. Eles sabiam exatamente as próximas tarefas, seus objetivos e principalmente os motivos de estarem fazendo aquilo.

Eles sabiam também quando eles estavam sendo produtivos ou improdutivos e quais os bloqueios (que eles mesmos tiravam) estavam atrapalhando o time. Eles avisavam com antecedência que a entrega iria atrasar.

Não entra na minha cabeça um programador não se interessar por processos e métodos ágeis já que o Manifesto Ágil foi feito por alguns dos melhores programadores de suas épocas. Programadores assim não apenas desatentos, mas totalmente desinteressados e desconectados do propósito e geração de resultados dos seus times.

Não precisavam de _babás PMs...

Os melhores desenvolvedores aprendem sobre o problema e queriam saber qual o objetivo deveria ser alcançado pela empresa/time. O resto é mágica. Precisar de ter alguém pra escrever histórias do que deveria ser feito, com todos os detalhes de como o software deveria funcionar era basicamente uma afronta.

Os desenvolvedores de alto nível com que trabalhei sabiam exatamente o que e por que algo precisava ser feito e ainda depois de feito o deploy eles acompanhavam esses resultados juntamente com o PM e stakeholders. O interesse pelo resultado era compartilhado.

Eu costumo dizer que os PMs são um bug no sistema, por que se os desenvolvedores realmente tivessem interesse pelo objetivo e propósito da empresa, eles não precisam de alguém ditando o que eles devem fazer todos os dias da sua vida.