Zen do Gabriel de Desenvolvimento Tecnológico

Tradução do original.

Nenhum ser humano deveria ter que realizar um trabalho se ele pode ser realizado por uma máquina.
Ainda que não haja nenhuma diferença real entre humanos e tecnologia, pois tecnologia é uma parte fundamental da condição humana.
Tecnologia deve ser desenvolvida para superar limitações biológicas humanas.
Logo, o humanismo puro é contraditório, e o estágio pós-humano do desenvolvimento é um objetivo desejado.
A tecnologia desenvolvida deve ser utilizada para o Bem, não para o Mal.
Apesar de que não é realmente possível controlar se ela será utilizada para o Bem, ou se ela será utilizada para o Mal.
Caso o desenvolvimento tecnológico surja do Mal, ou a luta contra o Mal leve ao desenvolvimento tecnológico, então que seja. A tecnologia desenvolvida deve seguir sendo utilizada, sem arrependimentos ou limitações exceto seu uso, que deve ser para o Bem.
Ferramentas tem um caso de uso intrínseco e genérico. Elas podem ser utilizadas para outra coisa, se possível, porém sempre carregam seu caso de uso intrínseco.
Logo, a interface de um aparato tecnológico deve empoderar o Usuário para realizar seu caso de uso intrínseco genérico. Nem mais, nem menos.
Ainda que ela possa se adaptar para o caso de uso específico e a individualidade do seu Usuário.
No caso em que ela deva se adaptar, quanto mais adaptável com a menor configuração, melhor.
Uma solução só pode utilizar seus recursos necessários, e reduzir a sua necessidade é um objetivo desejado.
Ainda que recursos não utilizados também sejam recursos desperdiçados.
No caso em que recursos estejam ociosos, eles podem ser utilizados para um propósito que não os desperdice. Como estoque, por exemplo.
Tecnologia deve ser desenvolvida de maneira sustentável.
Logo, o décimo-terceiro item deve ser seguido sabiamente para não levar ao Mal.
Se um aparato tecnológico não pode ser responsabilizado, sua falha é um erro humano.
Quando um aparato tecnológico puder ser responsabilizado, ele deve se tornar um cidadão da Nossa Civilização.
Ainda que você possa não gostar disso se for religioso o suficiente.

Apêndice A: Design de Computadores e Programas

A.1. Computação é Arte. Trate-a de acordo.

A.2. Listas ligadas são boas para o Programador.

A.3. Ainda que elas não sejam boas para a Máquina.

A.4. O mesmo se aplica a abstrações e programação funcional.

A.5. Boa é a Convenção. Ela leva a Coesão e Coerência.

A.6. Porém uma má Convenção geralmente é pior que nenhuma Convenção.

A.7. Sistemas não devem esconder a si. Esconder um sistema Leão em uma abstração Felino pode levar o Programador a acreditar que ele é um Gato.

A.8. Ou pior, pode levar o Usuário a acreditar que é só Magia.

A.9. Programadores muitas vezes implementam mais e mais genéricas funcionalidades do que deveriam, só porque podem. Isso deve ser evitado.

A.10. Uma maneira de mitigar esse problema é dando menos poder a eles.

A.11. Porém isso deve ser feito sabiamente para não levar a Sistemas Inúteis.

A.12. Simplicidade e Minimalismo devem ser utilizados com pouca moderação.

A.13. Ainda que você possa não saber quanto é pouca moderação exceto que você programe em Go.

A.14. A Arquitetura do Conjunto de Instruções ("Instruction Set Architecture") deve ser simples o suficiente para que o Aluno consiga programar em seu Assembly.

A.15. Sintaxe importa, porém Semântica é muito mais importante.

A.16. Coisas diferentes devem ser visivelmente diferentes.

A.17. Coisas Importantes devem ser rapidamente acessíveis, e Informação Importante deve ser visível. Semelhantemente, Coisas e Informação não-importantes devem ser escondidas, porém acessíveis quando necessário.

A.18. Um Computador deve minimizar a quantidade de computação que o cérebro do Usuário precisa fazer.

A.19. Não se esqueça da Alegria da Computação.

Apêndice B: Programação de Computadores

Os únicos programadores que devem se importar com datilografia veloz são aqueles que competem, programam em Java ou ganham mais por programarem mais linhas de Código.
Porém, caso você seja um dos últimos dois, pode querer repensar suas Escolhas de Vida.
Geralmente, há Algo errado caso Programação não traga Alegria.
E deve ser notado que Algo pode estar errado fora do Código.
Você deve entender o que certo Pedaço de Código está fazendo, mesmo que ele esteja fazendo errado.
E caso um Pedaço de Código esteja fazendo Algo certo e você não entende como, o Código está errado de qualquer forma.
Logo, entender o que o Código faz é a Coisa mais importante em Programação.
Ao Programar, nenhum Problema é resolvido no Editor de Texto.
Eles são resolvidos no Papel, com uma Caneta ou Lápis.
Logo, é importante saber quando deixar o Computador e pegar o Papel.
Programação de Computadores não é uma Arte manual. É uma Intelectual. Trate-a de acordo.
Programação de Computadores também é parte da Matemática. Ainda que algumas Pessoas possam ter raiva dessa Afirmação.
Você não precisa saber o funcionamento interno de Algo, exceto quando você precisa.
Você nunca é mais esperto que Compiladores, Bibliotecas, Frameworks ou qualquer outro Código escrito antes de você, exceto quando você é.
E você se surpreenderia se soubesse quantas vezes você é mais perspicaz do que pensa.
Inclusive porque Informação específica a um Contexto é muito Poderosa.
Programar um Computador é mais sobre Ler que Escrever. É melhor gastar 2 horas lendo Cormen ou Knuth e 1 hora Programando Algo do que as mesmas 3 horas apenas Programando o exato mesmo Algo.
Porém os autores devem ser escolhidos cuidadosamente, e não devem incluir Robert Cecil Martin.
Nenhuma das Afirmações acima farão algo caso você não vá Programar Algo.

Apêndice C: Programação na Linguagem de Programação C

Se você tem alguma Ideia, por menor que seja, de como implementar um Pedaço de Código específico em Assembly, esse Pedaço de Código provavelmente é uma boa ideia.
Ainda que o Compilador possa gerar Algo completamente diferente.
O Compilador não deve ser combatido, já que ele é um Amigo.
$ find . -name "*.[c,h]" -exec clang-format -i {} \;.
C não é uma Linguagem de Programação Fortemente tipada.
Mas é uma Estática, e isso deve ser aproveitado.
-ansi -pedantic cria Caráter.
Memória é a Coisa mais importante sempre. Mais que o seu cônjuge.
Se você não consegue ter certeza de quantas vezes um malloc() será chamado em um Lugar específico, esse Lugar não deve ter uma chamada para malloc().
A Pilha é uma Amiga. Use-a sabiamente.
"The C Programming Language" é nossa Bíblia. K&R são nossos Profetas. C não é Ciência, mas Religião.
Logo, entendê-la é um Processo Religioso.
Use o Depurador quando em dúvida e quando não.
Não tenha medo de fazer Algo na mão ou utilizar uma Técnica Proibida, exceto que seu Professor vá te dar uma nota pior por isso.
Aprenda antes de digitar e entenda antes de compilar.
Se lidando com Problemas de Memória, goto C;.
Ninguém gosta de Programar em C. Objetivamos matá-la em breve.
Ainda que ainda Programemos em C, e nossos Ambientes ainda dependam dela.
C está morta. Vida longa a C!