Zen do Gabriel de Desenvolvimento Tecnológico

Tradução do original.

1- Nenhum ser humano deveria ter que realizar um trabalho se ele pode ser realizado por uma máquina.

2- Ainda que não haja nenhuma diferença real entre humanos e tecnologia, pois tecnologia é uma parte fundamental da condição humana.

3- Tecnologia deve ser desenvolvida para superar limitações biológicas humanas.

4- Logo, o humanismo puro é contraditório, e o estágio pós-humano do desenvolvimento é um objetivo desejado.

5- A tecnologia desenvolvida deve ser utilizada para o Bem, não para o Mal.

6- Apesar de que não é realmente possível controlar se ela será utilizada para o Bem, ou se ela será utilizada para o Mal.

7- 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.

8- 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.

9- 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.

10- Ainda que ela possa se adaptar para o caso de uso específico e a individualidade do seu Usuário.

11- No caso em que ela deva se adaptar, quanto mais adaptável com a menor configuração, melhor.

12- Uma solução só pode utilizar seus recursos necessários, e reduzir a sua necessidade é um objetivo desejado.

13- Ainda que recursos não utilizados também sejam recursos desperdiçados.

14- No caso em que recursos estejam ociosos, eles podem ser utilizados para um propósito que não os desperdice. Como estoque, por exemplo.

15- Tecnologia deve ser desenvolvida de maneira sustentável.

16- Logo, o décimo-terceiro item deve ser seguido sabiamente para não levar ao Mal.

17- Se um aparato tecnológico não pode ser responsabilizado, sua falha é um erro humano.

18- Quando um aparato tecnológico puder ser responsabilizado, ele deve se tornar um cidadão da Nossa Civilização.

19- 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

B.1- 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.

B.2- Porém, caso você seja um dos últimos dois, pode querer repensar suas Escolhas de Vida.

B.3- Geralmente, há Algo errado caso Programação não traga Alegria.

B.4- E deve ser notado que Algo pode estar errado fora do Código.

B.5- Você deve entender o que certo Pedaço de Código está fazendo, mesmo que ele esteja fazendo errado.

B.6- 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.

B.7- Logo, entender o que o Código faz é a Coisa mais importante em Programação.

B.8- Ao Programar, nenhum Problema é resolvido no Editor de Texto.

B.9- Eles são resolvidos no Papel, com uma Caneta ou Lápis.

B.10- Logo, é importante saber quando deixar o Computador e pegar o Papel.

B.11- Programação de Computadores não é uma Arte manual. É uma Intelectual. Trate-a de acordo.

B.12- Programação de Computadores também é parte da Matemática. Ainda que algumas Pessoas possam ter raiva dessa Afirmação.

B.13- Você não precisa saber o funcionamento interno de Algo, exceto quando você precisa.

B.14- Você nunca é mais esperto que Compiladores, Bibliotecas, Frameworks ou qualquer outro Código escrito antes de você, exceto quando você é.

B.15- E você se surpreenderia se soubesse quantas vezes você é mais perspicaz do que pensa.

B.16- Inclusive porque Informação específica a um Contexto é muito Poderosa.

B.17- 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.

B.18- Porém os autores devem ser escolhidos cuidadosamente, e não devem incluir Robert Cecil Martin.

B.19- 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

C.1- 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.

C.2- Ainda que o Compilador possa gerar Algo completamente diferente.

C.3- O Compilador não deve ser combatido, já que ele é um Amigo.

C.4- $ find . -name "*.[c,h]" -exec clang-format -i {} \;.

C.5- C não é uma Linguagem de Programação Fortemente tipada.

C.8- Mas é uma Estática, e isso deve ser aproveitado.

C.7- -ansi -pedantic cria Caráter.

C.8- Memória é a Coisa mais importante sempre. Mais que o seu cônjuge.

C.9- 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().

C.10- A Pilha é uma Amiga. Use-a sabiamente.

C.11- "The C Programming Language" é nossa Bíblia. K&R são nossos Profetas. C não é Ciência, mas Religião.

C.12- Logo, entendê-la é um Processo Religioso.

C.13- Use o Depurador quando em dúvida e quando não.

C.14- 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.

C.15- Aprenda antes de digitar e entenda antes de compilar.

C.16- Se lidando com Problemas de Memória, goto C.8;.

C.17- Ninguém gosta de Programar em C. Objetivamos matá-la em breve.

C.18- Ainda que ainda Programemos em C, e nossos Ambientes ainda dependam dela.

C.19- C está morta. Vida longa a C!