O desenvolvedor faz parte do código: Não existe desenvolvimento objetivo. O software não é uma ferramenta, mas a impressão binária do estado mental, da pressão arterial e da raiva do programador naquele dia.

O caos é sagrado: Se um algoritmo é transparente demais, isso é suspeito. O verdadeiro código gonzo é como uma selva: perigoso, escuro, e somente seu criador sabe onde estão as armadilhas.

Testes no servidor de produção: Testes unitários são o esporte dos covardes e burocratas. O verdadeiro programador gonzo depura diretamente em produção, em meio aos gritos dos usuários.

A documentação é ficção: Os comentários anexados ao código não são explicações, mas monólogos internos, manifestos políticos ou pedidos de socorro. Quem não entende o código não é digno de usá-lo.

O ponteiro (pointer) é o senhor: Use uma linguagem de programação que não limite você! O gerenciamento direto de memória é a garantia da sua liberdade. O uso de tipos seguros é apenas uma corrente. Use endereços de memória como se não houvesse amanhã. O Memory Leak é o seu grito que ninguém ouve.

Arquitetura baseada em cafeína: A qualidade do código é diretamente proporcional à quantidade de estimulantes consumidos e inversamente proporcional ao número de horas passadas dormindo.

Mensagem de erro como arte: A mensagem de erro não deve ajudar, mas chocar. O usuário deve sentir o desprezo da máquina e de seu criador a cada Runtime Error.

Nunca limpe (Refactor): Aquilo que você escreveu uma vez em estado de transe é sagrado. Se tocar para deixá-lo “mais bonito”, você matará a alma do software.

O prazo é apenas uma sugestão: O programador gonzo não trabalha pelo relógio, mas cavalga as ondas da inspiração e do pânico. O código fica pronto quando o desenvolvedor desaba.

O software deve ser imprevisível: Um bom programa gonzo sempre contém um pouco de aleatoriedade. Se a mesma coisa acontece a cada clique de botão, é um produto industrial entediante, não arte.

Responsabilidade? Excluída: O contrato de licença deve consistir em um único item: “Se iniciar, o problema é seu.” O desenvolvedor não é Deus, apenas uma testemunha da destruição da máquina.

A estratégia de saída: Quando o projeto desmoronar, não dê explicações. Apague o histórico do Git, queime o disco rígido e encontre um lugar no México onde não haja sinal de celular.