As horas em que a máquina trabalha sozinha

Há uma parte deste ofício que não é ofício nenhum. É fila de espera. Ninguém escreve sobre isso porque não há nada a dizer sobre isso, o que é sensivelmente a razão pela qual quisemos fazê-lo.

Um mapa temporal de um episódio

Seis semanas, dispostas pelo que realmente acontece nelas, produzem três categorias em vez das duas que se esperaria.

Decidir. Talvez uma semana disso, espalhada finamente pelas seis. Baixo esforço, alta consequência, e quase impossível de agendar.

Trabalhar. Cerca de cento e cinquenta horas de mãos na coisa. Desenhar, sobrepor camadas, gravar, misturar, montar.

Esperar. Entre quarenta e noventa horas de tempo de máquina só na passagem final, mais todas as renderizações de teste antes disso, mais as codificações, mais o carregamento. O episódio de floresta descrito em o episódio que apagámos demorou noventa horas na passagem final e foi depois apagado, que é o exemplo mais puro disponível do que é esta categoria.

Por isso, cerca de um décimo da vida decorrida de um episódio é a máquina a trabalhar sem nós; numa semana má, um quarto. É a única parte do processo que não conseguimos comprimir importando-nos mais, trabalhando até mais tarde, ou sendo melhores no que fazemos.

Não se pode querer que uma renderização vá mais depressa. É a única parte do trabalho que é completamente indiferente a si.

As coisas erradas a fazer enquanto corre

Já fizemos todas estas, a maioria repetidamente.

1. 1

   Vigiá-la

   O desperdício mais puro. Uma barra de progresso recompensa a atenção com nada, e é especificamente concebida para parecer que pode recompensar. Alguma parte do cérebro trata-a como uma tarefa em curso e recusa-se a libertar o serão. Já perdemos noites inteiras assim, acordados numa divisão onde o único acontecimento era um número a subir.

2. 2

   Fazer pequenas edições numa cópia

   Parece produtivo. Foi assim que acabámos, duas vezes, com dois ficheiros de projeto que tinham ambos avançado e nenhuma resposta clara sobre qual era o verdadeiro. Reconciliá-los custou mais tempo do que a renderização poupou. Agora o projeto fica bloqueado quando a fila começa, e bloqueado significa bloqueado.

3. 3

   Começar a próxima coisa à uma da manhã

   A mais sedutora, porque parece disciplina. A nossa contagem informal é que aproximadamente três em cada quatro decisões tomadas depois da meia-noite durante uma renderização foram revertidas até às dez da manhã seguinte — uma cor, uma divisão, um assunto inteiro. A hora tardia não produz exatamente ideias más. Produz ideias confiantes, o que é pior, porque uma ideia má e confiante sobrevive até à semana seguinte.

4. 4

   Cutucar a máquina

   Abrir uma pré-visualização. Verificar um fotograma. Cada uma destas ações rouba trabalho ao processo que está a verificar, por isso a renderização fica mais lenta na proporção direta de quanto a quer terminada. Isto é quase engraçado e nunca é engraçado às duas da manhã.

A única coisa certa é embaraçosamente simples e demorou anos a realmente fazer: sair. Programar a fila, fechar a porta, ir estar noutro lugar. É certa pela mesma razão que é difícil — não há nenhuma versão de ficar que ajude, e a mente não aceita isso facilmente sobre uma coisa que ela própria começou.

Confiar na fila, e a manhã em que falha

O arranjo inteiro depende de uma aposta: que a coisa que pôs a correr à meia-noite estará correta às nove.

A aposta perde vezes suficientes para ser um custo real. O nosso pior caso foi um ficheiro longo que correu durante quarenta e uma horas com a camada de chuva desligada — o interruptor tinha ficado virado durante uma verificação dez minutos antes de a fila começar, e ninguém voltou a olhar para o painel de camadas porque o ficheiro estava terminado há dois dias. Descobrimos num domingo de manhã. Quarenta e uma horas de tempo de máquina, um dia e meio de calendário, e uma das quatro vagas de publicação perdidas descritas em trabalhar devagar numa plataforma rápida remonta diretamente a isto.

A correção não foi uma lista de verificação melhor, embora tenhamos escrito uma. Foi uma renderização de teste de noventa segundos — vinte fotogramas, espalhados por todo o ficheiro — que tem de terminar e ser vista por um humano antes de o trabalho longo poder começar. Custa um minuto e meio. Já apanhou quatro erros em dois anos, pelo menos um dos quais teria custado outro fim de semana.

Para que serve realmente o intervalo

Aqui está o único benefício genuíno, e queremos ter cuidado para não o vender demais, porque a tentação de fazer esperar soar sensato é exatamente o que este texto está a tentar evitar.

Uma reprodução completa no fim de um dia de trabalho diz muito pouco. Esteve dentro do ficheiro durante semanas; o seu olho concordou com tudo o que lá está. Uma reprodução depois de quarenta horas sem o poder abrir é um instrumento inteiramente diferente. Coisas que eram invisíveis na quinta-feira são óbvias no sábado — uma cor que se infiltrou, um ritmo demasiado regular, um objeto que revela demasiado.

Essa distância é real e vale alguma coisa. É também inteiramente um acidente das nossas ferramentas. Se as renderizações fossem instantâneas, teríamos de inventar uma razão para deixar o ficheiro em paz durante dois dias, e, a conhecermo-nos, não a inventaríamos.

A fatura por não fazer nada

Uma coisa que nunca aparece nos relatos de trabalho tranquilo: a máquina não é grátis enquanto espera.

Uma renderização de noventa horas na nossa configuração consome aproximadamente o que um pequeno aquecedor consome, continuamente, durante quatro dias — algo à volta de trinta e cinco a quarenta quilowatt-hora por episódio longo, cerca do que o nosso frigorífico usa num mês, gasto antes de alguém ter visto um único segundo dele. Multiplique pelas passagens de teste, pelas versões abandonadas e pelo episódio de floresta apagado, e uma parte significativa do que custa manter este canal a funcionar é eletricidade a transformar-se em calor numa divisão onde ninguém está sentado.

Comprámos uma segunda máquina em parte para encurtar isto e ajudou menos do que esperávamos. A longa passagem final não se divide tão bem quanto a página de vendas dava a entender; a fila passou de cerca de noventa horas para cerca de cinquenta e cinco, não a metade que tínhamos orçamentado. Agora duas máquinas aquecem a mesma divisão, há dois conjuntos de atualizações para manter alinhados, e mais uma coisa que pode ser mal configurada à meia-noite. Provavelmente ainda a compraríamos. Não foi a compra que pensávamos que era.

Não resolvemos isto

Não há final para este. A maior parte da espera é simplesmente aborrecida, e o aborrecimento não é uma virtude escondida — é exatamente o que diz que é. As noites passadas a vigiar uma barra não foram contemplativas; foram desperdiçadas, e gostávamos de as recuperar.

O que temos é um ficheiro de projeto bloqueado, uma renderização de teste de noventa segundos, e uma regra sobre ir para a cama que cumprimos cerca de dois terços das vezes. É esse o total do nosso progresso em três anos na parte do trabalho que ocupa mais calendário do que qualquer outra fase isolada.

O argumento sobre porque ver algo em que quase nada acontece é diferente de ver uma barra de progresso — uma distinção que agora levamos a peito — está em o gato de quatro minutos. A diferença é se a espera vai a algum lado.

O serão está quente aqui.