Programador backend

CRUD, validação, serialização, chamar um serviço a partir de outro, e os testes de tudo isso.

Transações, idempotência, novas tentativas, ordem — decidir o que nunca pode ser verdade e garantir que nunca é.

Desenhar o que é guardado, e migrá-lo mais tarde sem parar o serviço nem perder nada.

Autorização, fronteiras entre clientes, o que escapa numa mensagem de erro, e o que um endpoint interno expõe se alguém o encontrar.

Planos de consulta, cache, a fatura, e o pedido que ficou lento porque algo a montante mudou.

Prevenção: decidir sob pressão de tempo o que reverter, o que degradar, e o que dizer às pessoas enquanto ainda está partido.

Uma estimativa interna da Amazon sobre a própria engenharia da Amazon, publicada pela empresa que vende a ferramenta — quem faz o trabalho, quem o mede e quem o vende são a mesma parte, o que é dito aqui porque não pode ser verificado de fora. A empresa publica também o seu método: o tempo poupado foi estimado a partir do número de dependências Java migradas, assumindo um dia ou mais de tempo de programador por dependência feita à mão. Repara no que a migração é: uma subida de versão de linguagem tem um compilador e uma bateria de testes existente como árbitro, por isso o sucesso é verificável por máquina em cada passo — a forma mais favorável possível para este género de automatização e não um resultado geral sobre o trabalho de backend. E repara no que é afirmado e no que não é: 4.500 anos é trabalho não feito, mais de mil programadores, sem que em lado nenhum se diga que algum deles saiu ou que um lugar foi eliminado.

Uma empresa pô-lo em produção. Pode mover a linha de base, ponderado pela escala e por quanto esse contexto se parece com o teu.

A metade visível deste trabalho — endpoints e canalização — é a metade exposta, e é aquilo para que terias sido contratado. As partes que se aguentam são sobre o que nunca pode acontecer, e isso aprende-se estando presente quando alguma coisa aconteceu. Chega-te a uma escala de prevenção mais cedo do que é confortável.

A tua posição é mais forte do que a da página de frontend na tarefa mais exposta, e a razão não é o trabalho ser mais difícil — é estar errado sair caro e não se ver, por isso a responsabilidade está concentrada. Repara no modo de falha que isso cria: rever alterações geradas em sistemas onde um erro fica silencioso durante meses.

Ficar e reforçar-te

Ir para onde um erro sai caro

Pagamentos, contabilidade, identidade, tudo o que tenha um regulador — domínios onde uma alteração sem vigilância não é permitida, por isso a revisão e a responsabilidade são financiadas em vez de assumidas.

Refazer o posto

Ser dono da fronteira que os agentes podem atravessar

Alguém tem de decidir o que uma alteração automatizada pode tocar num serviço onde um erro é silencioso. Na maioria das equipas isso não foi dado a ninguém, e é por isso que aparece nas revisões de incidentes em vez das descrições de funções.

Movimento lateral

Passar para trabalho de dados ou de plataforma

O raciocínio sobre coerência, falha e custo transfere-se diretamente, e ambos são sítios onde o mesmo critério é aplicado a uma superfície mais larga.

As partes movem-se a velocidades diferentes, por isso um único número esconderia aquilo de que precisas. Escrever endpoints é já em grande medida trabalho de máquina. Decidir o que nunca pode acontecer quando dois pedidos chegam ao mesmo tempo, ou o que uma mensagem de erro pode revelar, não se moveu, porque são posições pelas quais se responde e não de escrever. Um sinal que consegues verificar: quando algo se partiu no trimestre passado, a parte difícil foi encontrá-lo ou decidir o que fazer com ele?

Na sua tarefa mais visível está menos exposto, e a razão vale a pena ser percebida em vez de tomada como consolo: a correção no backend é muitas vezes invisível e cara quando falha, por isso mais parte do trabalho é responsabilidade. É uma diferença estrutural, e não uma ordenação de dificuldade, e pode mudar — a metade de endpoints deste trabalho está exposta exatamente nos mesmos termos que a metade de frontend.

Para as entrevistas, isso ainda não mudou. Para o trabalho, a divisão honesta é que lembrar-se de um algoritmo conta menos do que contava, enquanto raciocinar sobre falhas conta mais — saber o que uma nova tentativa faz a um sistema que já está a sofrer é a mesma competência que as perguntas de desenho de sistemas tentam testar, aplicada a algo real. Aprende-a com os teus próprios incidentes e não com uma lista.

Já consegue escrever um rascunho, e não é essa a restrição. A restrição é alguém ter de garantir o que ele nunca pode fazer, migrar os dados dele anos mais tarde sem perder nada, e estar acordado quando ele falhar. São posições de responsabilidade, e a responsabilidade não ficou mais barata — nos domínios regulados tornou-se mais explicitamente obrigatória.