O engenheiro full-stack é um engenheiro de sistemas

O termo full stack foi diluído em um cargo que significa 'sabe React e consegue escrever um endpoint'. Quero defender o significado original, porque acho que ele descreve uma pessoa diferente e mais valiosa.

Um engenheiro full-stack é alguém que recebe um produto quebrado e encontra a falha onde quer que ela esteja: em um layout shift de CSS, em um header de cache mal configurado, em uma query N+1, em um TTL de DNS, em uma condição de corrida entre dois workers. Não porque é especialista em cada camada, mas porque se recusa a parar na fronteira da camada e dizer 'não é problema meu'.

Isso é um engenheiro de sistemas. A stack é só onde o sistema por acaso mora.

A fronteira é onde o bug se esconde

Em mais de seiscentos projetos, quase nunca encontrei uma falha séria que vivesse limpa dentro de uma única camada. Ela vive entre elas. O frontend assume que a API retorna uma lista ordenada e o banco parou de garantir isso depois de uma mudança de índice. A API assume que a fila é at-least-once e o consumidor assume exactly-once. O cache acha que a sessão é válida e o servidor de auth revogou dois minutos atrás.

Um especialista em cada camada pode olhar sua parte, confirmar que está correta, e estar certo. O bug continua. É preciso alguém disposto a segurar o caminho inteiro da requisição na cabeça para ver que as peças estão individualmente corretas e coletivamente erradas.

Essa é a habilidade de verdade. Não amplitude de sintaxe. Amplitude de responsabilidade.

O que o trabalho realmente exige

Consigo nomear as competências, porque vi engenheiros crescerem nelas. Você precisa ler um waterfall de rede e saber qual requisição é o gargalo. Precisa ler um plano de query e saber por que o índice não foi usado. Precisa saber o que um load balancer faz com sticky sessions, o que um CDN faz com Set-Cookie, e o que acontece com sua Server Action quando o deploy termina no meio da requisição.

Precisa saber infraestrutura o bastante para fazer a pergunta certa a quem sabe mais. Isso inclui as partes chatas: variáveis de ambiente, terminação TLS, envio de logs, o que um health check deveria de fato checar.

E precisa de senso de produto, porque um sistema correto e inutilizável ainda é uma falha, e o engenheiro full-stack costuma ser a pessoa mais próxima do usuário e do banco ao mesmo tempo.

Por que os times deveriam querer essa pessoa

O argumento econômico é simples. Handoffs são onde o tempo vai embora. Uma feature que precisa de um engenheiro de frontend, um de backend e um de infra para coordenar exige três agendas para marcar e três modelos mentais para alinhar. Uma pessoa que consegue assumir tudo de ponta a ponta entrega em uma fração do tempo corrido, e não há ninguém para culpar do outro lado de uma fronteira.

O argumento de qualidade é mais forte. Quando uma pessoa é dona do caminho da requisição, os modos de falha são desenhados em vez de descobertos. Ela sabe que o formulário será reenviado, porque escreveu o handler. Sabe que a query vai ficar lenta em escala, porque escreveu o schema. O ciclo de feedback está dentro de uma cabeça só.

Isso não é um argumento contra especialistas. Um produto sério precisa de um especialista em banco, um em segurança, um designer. É um argumento de que quem integra o trabalho deles precisa entender tudo bem o bastante para saber quando não encaixa.

Como se tornar um

Você não vira engenheiro de sistemas aprendendo mais um framework. Vira seguindo um bug para além do ponto em que ele deixou de ser sua função. Da próxima vez que uma requisição estiver lenta, não abra ticket para o time de backend. Abra o plano da query. Da próxima vez que o deploy quebrar, não espere a infra. Leia o pipeline.

Sou autodidata, e o jeito como aprendi cada camada foi sendo a única pessoa disponível quando ela falhou. Não é um plano que recomendo, mas o princípio vale: a stack não é uma lista de tecnologias. É o conjunto de lugares onde seu produto pode quebrar, e seu trabalho são todos eles.