Meu nome é Elton Minetto

Este post é inspirado no texto escrito pela Michelle Lim em 2020. Vou traduzir alguns pontos que achei relevante e fazer meus comentários sobre.

O eixo “Frontend/Backend” não mapeia bem as motivações dos engenheiros de software. Se você usar apenas esse eixo, pode acabar em projetos de que não gosta ou, pior ainda, desistir prematuramente da engenharia. Em vez disso, tente usar o eixo “Produto/Infraestrutura” como o primeiro eixo para entender sua preferência de carreira.

A minha primeira contribuição é sugerir uma mudança de termo. Em 2023 a tendência é usarmos o termo “Plataforma” ao invés de “Infraestrutura", pois reflete melhor o caminho que o mercado e os times estão seguindo. O pessoal da LINUXtips tem um video sobre isso que eu recomendo.

Dando continuidade ao post da Michelle, a seguir ela detalha um pouco mais a ideia:

“Produto/Plataforma” mapeia perfeitamente a psicologia de como os engenheiros escolhem projetos e suas motivações para aprender a codificar. De um modo geral, existem 2 tipos de engenheiros:

1. Engenheiros “Product-first” são obcecados em usar o código para resolver um problema do usuário e veem o código apenas como um meio para um fim.

2. Engenheiros “Code-first” são obcecados com as abstrações, arquitetura, ferramentas e bibliotecas no código. Código elegante é o fim.

Não tenho certeza se concordo com o trecho “Código elegante é o fim”, mas o restante do texto faz bastante sentido para mim.

Devs “product-first” estão […] construindo, lançando e mantendo recursos que resolvem os problemas do usuário. Eles geralmente adoram estar na mesma sala que designers e gerentes de produto para aprender sobre os usuários e adoram encontrar oportunidades técnicas que possam melhorar o produto.

Por outro lado, devs “code-first”, ou “de plataforma” são aqueles que vão construir plataformas de infraestrutura que suportam aplicativos, seja por meio da construção de pipelines de CI/CD, implementação de logs ou suporte a alto tráfego, arquitetura de código, etc.

Mas e quanto a dicotomia “backend” x “frontend”? Onde se encaixa nesse contexto? O argumento é que dentro de cada eixo “produto” x “plataforma” você vai precisar entender tanto de backend quanto de frontend. Não digo que o ideal é sermos full-stack (eu não acredito em full-stack, como comentei neste outro post) mas sim que devemos nos especializar no pensamento voltado para produto ou plataforma. Eu me vejo muito mais no lado de plataforma, onde me especializei em backend. Mas eu participo de discussões que envolvem decisões de frontend, sempre pensando no tipo de cliente que plataforma atende (outros devs).

Eu li o post da Michelle poucos meses depois da sua publicação, em 2020. Desde então eu liderei e participei de times tanto de produto quanto de plataforma e tenho validado este conceito no meu dia a dia. É muito visível a insatisfação de uma pessoa quando ela está na área onde ela não se sente desafiada. Pessoas de produto podem se frustrar muito em um time de plataforma, e vice-versa.

Por isso, se você é liderança de algum time, recomendo fazer essa análise com seus liderados para entender se eles estão trabalhando nas tarefas que fazem mais sentido para eles. E se você for dev, se pergunte que tipo de projeto traria maior satisfação para o seu dia a dia. E lembre-se que muitas vezes satisfação aumenta muito a produtividade, enquanto que o inverso também é uma verdade.