# Os programas dentro do trem **Programação: quem escreve as instruções exatas que fazem o sistema agir** > Capítulo 6.7 de *Antes do Código*, livro aberto e gratuito de Marcelo Castelo Branco. > > Leia esta página no site: https://marcelocastelo.io/livros/antes-do-codigo/secao-6/capitulo-6-7 --- ![O programa que abre as portas cabe numa placa. A conversa para escrever o programa passou pelo metrô inteiro.](https://marcelocastelo.io/assets/livros/antes-do-codigo/6-7-o-computador-de-bordo.webp) *O programa que abre as portas cabe numa placa. A conversa para escrever o programa passou pelo metrô inteiro.* O capítulo da sala das regras terminou com o passageiro que deu o nome para ter o cartão, e não para receber propaganda. Alguém escreveu o programa que guarda o nome do passageiro, e este capítulo chega à área de quem escreve os programas, a que quase todo leitor deste livro imagina para si. Você estuda programação há meses e imagina que, no emprego, vai passar o dia escrevendo código. Quase ninguém conta quanto do dia vai para entender o que precisa ser escrito, e para combinar com as outras áreas. > — Programador de verdade passa o dia inteiro escrevendo código. > > — Se o meu código funciona, o resto é problema dos outros. > > — Com a inteligência artificial escrevendo código, a minha área vai acabar. > > — Quanto mais linhas eu escrevo, mais eu produzo. > Escrever o código é a parte do trabalho que mais aparece, e é a menor parte do trabalho. ## O computador embaixo do painel Na cabine da imagem que abre este capítulo, uma tampa embaixo do painel do condutor está aberta, e mostra o computador de bordo, em verde, com as placas de circuito lado a lado. No banco do condutor fica um notebook aberto, ligado ao computador de bordo por um cabo. Pelo vidro da frente aparece o túnel. O Edson programa o computador de bordo dos trens do mesmo metrô há nove anos. O programa do Edson decide quanto tempo a porta fica aberta em cada estação, quando o trem começa a frear antes da plataforma e quando toca o aviso de porta fechando. O passageiro nunca vê o programa do Edson, e sente o programa em cada parada. Numa segunda-feira, o Edson recebe um pedido: uma estação nova vai abrir em um mês, e a plataforma dessa estação é em curva. No meio do trem, o vão entre o trem e a plataforma fica maior. Nessa estação, o trem precisa avisar sobre o vão e abrir as portas do meio dois segundos depois das outras. Pare aqui um segundo e responda como se você fosse o Edson. Dos doze dias de trabalho até a mudança ficar pronta, quantos você acha que foram escrevendo o programa? ## Dez dias de conversa e dois de programa O Edson escreveu o programa em dois dias. Os outros dez dias foram de conversa. O Edson pediu à equipe que planejou a estação as medidas do vão em cada porta, e perguntou à equipe que desenha os avisos qual frase o alto-falante devia dizer. O Edson combinou com o centro de controle os dois segundos a mais, porque dois segundos em cada viagem mudam o horário da linha. E o Edson pediu ao pátio três madrugadas para testar no trem parado. Na terceira madrugada, o teste achou um erro. O programa atrasava as portas do meio também quando o trem parava num desvio de emergência, fora da plataforma, onde não existe vão e a saída das pessoas precisa ser rápida. O Edson corrigiu em uma hora. **Quem programa passa a maior parte do tempo entendendo o que escrever, e testando o que escreveu**. > O programa do Edson coube em dois dias porque os outros dez dias disseram exatamente o que escrever. ## A fila virtual da venda Na empresa de ingressos, a Sueli é programadora. O cargo, em inglês, se chama software developer. **Programar é escrever as instruções exatas que fazem o sistema agir**, e no trabalho isso quase sempre começa muito antes da primeira linha. Para a venda do show, a Sueli fez a fila virtual: quando chegam cinquenta mil pessoas ao mesmo tempo, cada pessoa entra numa fila, vê a própria posição, e entra na compra na sua vez. O código levou quatro dias. Antes dos quatro dias, a Sueli conversou com quase todas as áreas deste livro. A Sueli perguntou à Ivone quantos computadores a Ivone já tinha separado para a fila, ao Celso que números vigiar, à Dirce como impedir que um robô guardasse lugar na fila, e ao Nilton o que podia guardar de cada pessoa na espera. A designer da empresa desenhou o que a pessoa vê enquanto espera, e o suporte recebeu antes a resposta para quem perguntasse da fila. ## O que a ferramenta acelera Hoje a inteligência artificial escreveria a primeira versão da fila virtual da Sueli mais depressa que a Sueli. Essa primeira versão sairia sem os computadores que a Ivone separou, sem a regra do Nilton sobre o que guardar de cada pessoa e sem a tela de espera da designer, porque essas respostas estavam nas conversas, e não no pedido. No metrô, a mesma ajuda encurtaria os dois dias de programa do Edson, e os dez dias de conversa continuariam do mesmo tamanho. **A conversa que diz o que escrever continua sendo trabalho de quem programa**. > Quem programa fica no meio do metrô, e todas as outras salas passam pelo código. ## Como saber se a eletrônica do trem combina com você ### Quatro perguntas para saber se escrever o programa é o seu lugar *Se você pensa em programar* As quatro perguntas cabem numa conversa curta, e mostram se você gosta do trabalho de quem programa como ele é, e não como parece de fora. **1. Você gosta de transformar um pedido vago numa instrução exata?** “Avisar sobre o vão” virou um número de segundos, uma frase e uma lista de portas. **Programar é tirar a dúvida de cada palavra do pedido**. **2. Você aguenta passar mais tempo entendendo do que escrevendo?** O Edson passou dez dias conversando e dois dias programando. Quem só quer escrever código se frustra com os dez dias de conversa. **3. Você testa o caso que dá errado, e não só o caso normal?** O erro do desvio de emergência só apareceu porque alguém testou a parada fora da plataforma. A parada normal, na plataforma, funcionava desde o primeiro dia. **4. Você conversa com as outras áreas antes de começar?** O Edson e a Sueli falaram com quase todas as salas do metrô. O código que nasce sem essa conversa volta para ser refeito. > O código bom nasce depois que todo mundo que o código afeta foi ouvido. ## Levar para a entrevista *Três perguntas que mostram se você entende o que quem programa faz de verdade.* Nas três perguntas abaixo existe a mesma tentação: falar só das linguagens que você conhece e dos projetos que você escreveu sozinho. Só que nenhuma das três perguntas está medindo quantas linguagens você domina. As três estão medindo se você entende que o código fica no meio de um metrô inteiro. ### “Quanto do tempo de um programador você acha que vai para escrever código?” A pergunta parece curiosidade, e é sobre o quanto você conhece o trabalho de verdade. **O que quem entrevista quer ouvir** - Que escrever é só uma parte - Que entender e testar tomam muito tempo - Um caso seu, com números **O que derruba** - Dizer que é o tempo todo, e que é isso que você gosta - Achar que conversa é perda de tempo - Não ter nenhum caso para contar **Boa resposta** “No meu projeto de fim de curso, uma agenda para um salão, eu marquei o tempo. Das quarenta horas, umas doze foram escrevendo código. O resto foi entender como o salão marcava horário, testar com a dona e refazer a tela duas vezes. Eu esperava o contrário, e entender o salão foi o que mais me ensinou.” **Resposta ruim** “Quase o tempo todo, e é por isso que eu gosto tanto.” **Quem entrevista ouve uma pessoa que vai se frustrar na primeira semana de reunião**, e que talvez escreva antes de entender. ### “Como você testa o que escreveu?” Esta pergunta procura alguém que testa o caso que dá errado. **Boa direção** - Contar os casos que você testa, e por quê - Dar um exemplo de erro que o teste achou - Dizer quanto o teste custou e o que poupou **Direção ruim** - Dizer que abre a tela e vê se funciona - Dizer que quem testa é outra área - Citar ferramenta de teste sem dizer o que testa **Boa resposta** “Na agenda do salão, eu testava cada mudança com três casos: um horário normal, dois clientes no mesmo horário e um horário depois do fechamento. O terceiro caso achou um erro que deixava marcar às onze da noite. Escrever os testes dobrou o tempo da primeira semana, e as semanas seguintes ficaram mais rápidas.” **Resposta ruim** “Eu abro a tela e vejo se funciona.” Abrir a tela testa o caso normal. O desvio de emergência do Edson nunca aparece no caso normal. ### “Além de outros programadores, com quem você acha que vai conversar no trabalho?” A pergunta mede se você enxerga as outras salas do metrô. **O avaliador técnico quer ver** - Que você sabe que o código roda em algum lugar preparado por alguém - Que você lembra de segurança e de dados - Que você pensa em como saber se o código funciona depois **O avaliador de pessoas quer ver** - Que você lembra de quem atende o cliente - Que você conversa antes, e não só quando dá problema - Que você trata as outras áreas como parte do trabalho **Boa resposta** “No estágio numa loja virtual, para mudar o cálculo do frete eu conversei com o estoque, com o atendimento e com quem cuidava do site no ar. O atendimento me contou que metade das reclamações era de frete para o interior, e eu comecei por ali. Programei em três dias, e conversei por uma semana.” **Resposta ruim** “Com o meu chefe, que passa as tarefas.” A resposta põe uma pessoa só entre você e o resto da empresa, e o código feito assim chega às outras salas como surpresa. ## Levar para o trabalho *Três situações do dia a dia de quem escreve o código.* ### A sua mudança depende de uma área que ainda não sabe dela Essa situação é o dia a dia de quem programa. O erro comum é terminar o código e só então avisar a outra área, quando mudar já custa caro. **Esperam de você** - Que você avise a outra área antes de terminar - Que você diga o que a sua mudança muda para essa área - Que você combine um teste junto **Não esperam de você** - Que você descubra a dependência no dia de pôr no ar - Que você mexa na parte da outra área sem falar - Que você atrase tudo esperando uma reunião grande **O que dizer** Para a Ivone: “A fila virtual que eu estou fazendo vai segurar até cinquenta mil pessoas ao mesmo tempo na espera. Essa espera muda alguma coisa nos computadores da venda de segunda? Eu termino o código na quinta, e queria ensaiar com você na sexta.” A fala chega antes do código pronto, como o pedido de três madrugadas do Edson ao pátio. ### O seu código vai mudar o que o cliente vê, e o suporte ainda não sabe Essa situação parece detalhe, e enche o atendimento de perguntas no dia seguinte. O erro comum é achar que quem programa não precisa falar com o suporte. **Esperam de você** - Que você conte ao suporte o que muda para quem usa - Que você sugira a resposta para a pergunta mais provável - Que você mostre a tela nova antes **Não esperam de você** - Que você escreva um manual comprido - Que você explique como o código funciona por dentro - Que você deixe o suporte descobrir pelo cliente **O que dizer** Para o Beto, do suporte: “Na segunda entra a fila virtual. Quem chegar depois das dez vai ver uma tela de espera com a posição na fila. Se alguém perguntar, a resposta é que a página atualiza sozinha, e que a pessoa não deve fechar a página. Te mando a tela por aqui.” Uma mensagem de quatro frases poupa o suporte de inventar a resposta na frente de um cliente nervoso. ### Pediram uma mudança pequena, e a mudança mexe em muita coisa Essa situação engana quem está começando. O erro comum é medir a mudança pelo tamanho do pedido, e não pelo número de lugares que ela toca. **Esperam de você** - Que você procure onde mais o código depende do que vai mudar - Que você diga o prazo real, com o motivo - Que você fale com as áreas afetadas **Não esperam de você** - Que você troque o número num lugar só e entregue - Que você diga que é rápido sem procurar - Que você transforme a mudança pequena num projeto enorme **O que dizer** “A mudança parece pequena, trocar o limite de quatro para seis ingressos por pessoa. Só que esse número aparece em três lugares: no pagamento, na regra contra robôs da Dirce e no e-mail do ingresso. Consigo fazer em um dia, e preciso antes de meia hora com a Dirce.” > No código, o tamanho de uma mudança é o número de lugares que ela toca, e não o tamanho do pedido. ## O que muda daqui em diante **Programar** - Antes: Escrever código o dia inteiro - Agora: Entender, combinar e então escrever **Linhas de código** - Antes: A medida do quanto você produziu - Agora: Uma parte pequena do trabalho **As outras áreas** - Antes: Quem atrapalha a entrega - Agora: As outras salas do metrô, por onde o código passa antes de chegar a alguém **A inteligência artificial** - Antes: O fim da área - Agora: Uma ajuda na parte de escrever, que deixa mais tempo para perguntar - Perguntar a quem a mudança afeta antes de escrever - Testar o caso que dá errado, e não só o caso normal - Contar ao suporte o que muda para quem usa - Combinar o ensaio com quem cuida da infraestrutura - Procurar onde mais aparece o que você vai mudar > O Edson levou dois dias escrevendo o programa da estação nova, e dez dias combinando com o resto do metrô. --- *Capítulo 6.7 de **Antes do Código** — O guia para quem quer entender a tecnologia — e não só usá-la.* *O livro inteiro, de graça: https://marcelocastelo.io/livros/antes-do-codigo*