Os programas dentro do trem
Programação: quem escreve as instruções exatas que fazem o sistema agir
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.
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
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.
“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.
O Edson passou dez dias conversando e dois dias programando. Quem só quer escrever código se frustra com os dez dias de conversa.
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.
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.
práticaLevar para a entrevista
Três perguntas que mostram se você entende o que quem programa faz de verdade.abrir
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.
- Que escrever é só uma parte
- Que entender e testar tomam muito tempo
- Um caso seu, com números
- Dizer que é o tempo todo, e que é isso que você gosta
- Achar que conversa é perda de tempo
- Não ter nenhum caso para contar
“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.”
“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.
- 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
- Dizer que abre a tela e vê se funciona
- Dizer que quem testa é outra área
- Citar ferramenta de teste sem dizer o que testa
“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.”
“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ô.
- 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
- 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
“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.”
“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.
práticaLevar para o trabalho
Três situações do dia a dia de quem escreve o código.abrir
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.
- 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
- 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
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.
- 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
- Que você escreva um manual comprido
- Que você explique como o código funciona por dentro
- Que você deixe o suporte descobrir pelo cliente
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.
- 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
- 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
“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
O Edson levou dois dias escrevendo o programa da estação nova, e dez dias combinando com o resto do metrô.