Sim, o código vence os argumentos. Mas por que? (E como ser educado).

Ok, então quando parar de se reunir e escrever algum código?

Isso surgiu recentemente ao trabalhar com um engenheiro de software sênior. Ele foi diligentemente às reuniões do projeto, tentou fazer as coisas avançarem, tentou gerar consenso, mas as coisas estavam travadas. Ele sabia em seus ossos que mais reuniões não ajudariam, mas uma semana dele codificando um protótipo ajudaria. Mas ele não queria “tirar o projeto” ou parecer arrogante e agressivo. (Boas preocupações …).

O que fazer?

“Code Wins Arguments” já existe há algum tempo. Isto é do arquivo do Facebook S1:

“Em vez de debater por dias se uma nova ideia é possível ou qual é a melhor maneira de construir algo, os hackers preferem apenas fazer um protótipo de algo e ver o que funciona”.

Clássico! “Os hackers preferem…”. Claro que sim! Chega de reuniões estúpidas, vamos apenas construir e vocês podem resolver isso mais tarde! Legal! O contexto implícito é um argumento e o resultado é uma vitória para os hackers – o que significa uma derrota para outra pessoa.

O problema é o seguinte: “Code Wins Arguments” é uma abreviação para um processo muito mais sutil. Software é um ato criativo. Quando pensamos em construir um software, não sabemos como isso vai acabar. Nós realmente não sabemos. Podemos especular, esboçar estruturas potenciais e contornos coletivos do que pensamos que vamos construir, mas até que comecemos a construir, não saberemos.

A melhor maneira de colocar isso veio de um jovem empresário com quem trabalhei há algum tempo. Estávamos olhando para o design de um novo produto. Parecia bom, mas algo estava incomodando a nós dois. Finalmente, ele disse: “precisamos construí-lo. Não sabemos o que ele quer ser ”.

Em todo processo criativo que conheço, há um equilíbrio entre os detalhes sutis e sutis do trabalho real e a elegância e a estrutura do objetivo final que temos em mente. Eles se informam. Você pode analisar a estrutura de uma sinfonia de Mozart o quanto quiser – se você não tiver o comando de Mozart sobre os detalhes, não vai escrever uma. E se você começar um romance ou um projeto de software sem uma boa idéia da estrutura, quando chegar a cerca de um terço do caminho, você se verá em um poço de piche – muitas possibilidades, muitos tópicos que não t amarrar juntos. Uma bagunça.

Portanto, a frase “Code Wins Arguments” é, eu acho, uma abreviatura de engenharia para “precisamos ir e criar agora, e ver o que essa coisa que estamos construindo quer ser”. É uma etapa necessária no processo criativo

Isso significa que, por algum período, o projeto não é mais um esporte de equipe – está nas mãos de alguns (talvez um) engenheiros. Portanto, é necessário deixar ir aqui. O resto da equipe precisa entender que o produto não aparecerá até que algum código seja escrito.

Mas também é verdade que a equipe mais ampla não fica fora de cena para sempre ou perde a propriedade. A etapa depois de codificar um protótipo é voltar a reunir, ver o que está começando a se mostrar e encaixá-lo na estrutura mais ampla do negócio.

Idealmente, em uma empresa de software, a ideia de que o software precisa de períodos de “apenas descobrir” está embutida. Se for assim, ótimo. “Precisamos ir e codificar nosso caminho através disso” é um estágio aceito no processo. Se não, você precisa chegar lá – mudar a cultura, o que sabemos que leva um tempo e muita repetição.

Então, como comunicar isso à equipe? Como o engenheiro com quem eu trabalhava poderia sair da enrascada?

Bem, podemos fazer a pergunta mágica: “o que eles querem?”. Meu palpite é que eles não querem se sentar em reuniões infrutíferas por horas. Meu palpite é que eles gostariam que o projeto avançasse, tipo, agora. Meu palpite é que eles não querem perder a propriedade. Então, comunique uma solução: “em uma semana, posso mostrar a vocês um protótipo que faz X e saberemos para onde ir”. Ou: “em dois, esse recurso estará pronto e funcionando e podemos ver se alguém deseja”. Defina o tempo, deixe claro que é uma exploração e que apóia o projeto como um todo.

“O código ganha argumentos” implica um argumento e uma derrota. “O código move todos nós para a frente” pode ser uma abordagem melhor, embora menos enérgica, a ser aplicada ao trabalho.

Software é um processo criativo. Às vezes, ele precisa nos dizer o que deseja ser. Sua cultura de desenvolvimento precisa reconhecer isso.