Uma visão mais abrangente sobre o ato de programar
Olá!
Hoje eu gostaria de abordar o ato de desenvolver sistemas do ponto de vista ético-moral-filosófico.
Pessoalmente, eu sempre senti falta na profissão de desenvolvedor de algum tipo de tratado filosófico que fornecesse algum tipo de guia nas decisões do dia-a-dia. Assim como um médico faz o Juramento de Hipócrates ao se formar que — ao menos, em teoria — serve como uma espécie de limite ético que orienta os futuros médicos, acho que poderíamos ter algo similar para novas pessoas desenvolvedoras. Acredito que não exista nada desse tipo dado que a profissão é relativamente nova, mas nada nos impede de tentar encontrar algo na internet, certo?
O material mais próximo que encontrei e irei comentar é o Programmer’s Oath, do Uncle Bob, disponível aqui na língua original. Vou comentar brevemente sobre, pois acredito que tenha uma mensagem legal nesse material (a tradução é minha mesmo):
No intuito de defender e preservar a minha integridade na profissão de desenvolvedor(a), eu juro, no melhor da minha capacidade e julgamento que:
No original, o termo usado é honra ao invés de integridade. Particularmente eu não gosto da palavra honra como é comumente empregada, principalmente pela quantidade de atrocidades cometidas por uma suposta defesa da honra. Esse termo passa uma ideia que devemos ser vistos pelos outros de uma determinada forma ou gozamos de algum privilégio na sociedade agindo de uma determinada forma. Como não acho que isso é o mais importante, eu optei por usar o termo integridade. A minha premissa aqui é que o que importa é sermos coerentes e éticos independendo de fatores externos.
Com isso dito, vamos a primeira regra proposta no juramento:
1. Eu não irei produzir código prejudicial.
Nesse ponto, eu gosto da ideia de refletir se um código é prejudicial ou não. Porém, eu deixo aqui uma questão moral: Imagine um código muito bem escrito, com uma arquitetura bem pensada, com testes e com bons padrões de qualidade. Você poderia dizer que a pessoa desenvolvedora cumpriu seu papel, certo? Porém, imagine que esse código é usado em um sistema bélico, em que sua única função é matar pessoas (ex: sistema de controle de mísseis ou algo similar). Esse código é prejudicial ou não?
Agora, inverta as variáveis. Um código mal-feito (porém, funcional) de um sistema crítico de suporte a vida (como de um equipamento hospitalar). Em caso de falha, esse código pode matar alguém. Ele é prejudicial?
Eu me recuso a cravar uma definição de prejudicial com 100% de certeza, dado que existem múltiplas variáveis que não é possível mensurar em um exercício dessa natureza. Portanto, vamos as próximas regras para avaliar se encontramos alguma resposta:
2. O código que eu irei produzir sempre será o meu melhor trabalho. Eu não permitirei de forma consciente que código com defeito em estrutura ou comportamento se acumule.
Eu conheço essa passagem pelo nome de regra do escoteiro. Basicamente envolve deixar algo em um estado melhor do que você encontrou. Seja limpar sua mesa de trabalho que alguém deixou suja ou refatorar algum código ruim do passado, dado que você está mexendo nele. Você pode estar pensando: Mas se eu gastar energia corrigindo cagada alheia, as pessoas me farão de trouxa!
Você pode pensar assim, afinal, a grande maioria dos brasileiros pensa. A resposta para isso é um ditado chinês que diz: Antes de querer mudar o mundo, dê três voltas ao redor da sua casa. Ou seja, comece melhorando pelo que tá perto de você, um passo de cada vez. Quem sabe você através do exemplo não inspira outras pessoas a serem melhores? Afinal, se todos forem honestos, não precisaremos temer que os outros sejam desonestos.
E antes que você entre em um mindest de produtividade tóxica ao ouvir sempre produzir o melhor, pense o seguinte: Dar o seu melhor envolve respeitar os seus próprios limites, seja cansaço, conhecimento naquele momento ou sua saúde mental. Você não precisa passar por cima do que é aceitável e saudável para isso.
3. Produzirei, a cada lançamento, uma prova rápida, segura e repetível de que cada elemento do código funciona como deveria.
Em outros termos, escrever testes do jeito certo é uma prova de que você fez o seu trabalho direito. Ênfase no repetível: Código que só funciona na sua máquina ou algo similar é algo que está aquém do que poderia em termos de qualidade. Em última instância, é possível concluir dado essas premissas que quem usa Docker é mais ético que quem não usa, por mais incrível que pareça.
4. Farei releases frequentes e pequenas, para não impedir o progresso dos outros.
Aqui tem mais valor do que parece a primeira vista. O conceito da agilidade de trabalhar com lotes de trabalho de tamanho menor geralmente produzem melhores resultados e pode ser vista como uma otimização real que gera de fato um ótimo global consistente. Aqui tem uma boa referência para entender esses termos referentes a otimização se você quiser entender melhor.
Porém, eu nunca tinha pensado que fazer pull-requests pequenas e frequentes além de ser uma forma de se trabalhar mais rápido, é algo que demonstra que você se importa com o seu impacto no trabalho alheio. Afinal, com um commit muito grande você demanda mais tempo de code review dos seus pares e gera mais problemas de integração, que atrapalha o fluxo de trabalho deles também.
Aqui também tem uma conclusão interessante: Lotes pequenos aumentam a sinergia do trabalho em equipe, dado que cada indivíduo diminui seu impacto negativo trabalhando dessa forma.
5. Vou melhorar sem medo e implacavelmente minhas criações em todas as oportunidades. Eu nunca vou degradá-las.
Essa regra é basicamente a regra do escoteiro escrita de outra forma. Porém, na expressão nunca degradar envolve um conhecimento de técnicas de medição. Afinal, para provar que não piorou, você tem que ter medido a performance primeiro, certo? Afinal, o que não pode ser medido não pode ser melhorado (ou evitado que degrade). Ou seja, meça a performance e a qualidade do seu código!
E não acredite que você vai diminuir a qualidade agora para corrigir depois, pois você sabe que não vai. Acreditar nisso é proferir um Na volta a gente compra! para si e o seu time. Eu já escrevi sobre as armadilhas de dívida técnica aqui se você quiser mais detalhes sobre.
6. Farei tudo o que puder para manter a minha produtividade e dos outros a mais alta possível. Não farei nada que diminua essa produtividade.
É quase um complemento da regra 2. Ações como: Evitar ser tóxico(a), cuidar da própria saúde mental, respeitar seus próprios limites, saber dizer não, melhorar suas próprias soft skills e até mesmo continuar estudando, em última instância, todas elas te ajudam a não diminuir a sua produtividade e a de outras pessoas. Em outros termos: É ético pensar no impacto que suas ações trarão para outras pessoas. Eu questionaria até algo mais: O que te faz pensar que você tem o direito de atrapalhar o fluxo de trabalho de outras pessoas?
7. Garantirei continuamente que os outros saibam o que estou fazendo e vice-versa.
Nessa regra eu tomei a liberdade de mexer bastante no significado original, que traduzindo mais literalmente seria algo como: Garantirei continuamente que os outros possam me cobrir e que eu possa cobri-los.
Se você olhar a frase original como uma recomendação e incentivo para transmissão de conhecimento, eu concordo. Porém, pode ser facilmente interpretada como vamos fazer um clubinho aqui e que ninguém aponta os erros de ninguém e cada um encobre os erros dos outros. Portanto, para evitar esse tipo de distorção achei melhor reescrever essa regra de outra forma.
Por essa nova ótica, alguém que não sabe comunicar sobre o próprio trabalho e não traz outras pessoas para perto do que está fazendo, está limitando o progresso de si e de outras pessoas, centralizando conhecimento.
Moral da história: Seja generoso com o seu conhecimento.
8. Produzirei estimativas honestas tanto em magnitude quanto em precisão. Não farei promessas sem certeza.
A questão toda das estimativas eu acho um tópico um pouco mais delicado. Existem algumas vertentes que acham que alguns tipos de estimativas são ruins por definição:
Além disso, humanos são ruins em estimar de uma maneira geral, é meio que um bug cerebral. Além de falácias, temos muito vieses (para começar, temos por volta de 50 deles), que atrapalham nosso julgamento. Então, de uma maneira geral, é melhor não estimar do que tentar acertar.
Caso você não tenha escolha e seja obrigado a estimar, seja responsável.
9. Eu nunca vou parar de aprender e melhorar meu ofício.
Concordo e acho que vale para tudo. Se até para nossa evolução espiritual temos que nos manter estudando, porque para nossa carreira e profissão seria diferente, não é mesmo?
Certa vez ouvi de uma pessoa próxima a mim algo que não consigo entender até hoje: Para que aprender coisas novas? Eu já aprendi coisa demais nessa vida.
Detalhe: A pessoa cometia erros crassos e muito básicos em diversas áreas da vida… com certeza tinha como causa essa posição de arrogância.
Caso você esteja se sentindo desanimado(a) e não esteja com vontade de aprender mais nada, procure um profissional de saúde mental. Já aconteceu comigo esse desânimo e fui descobrir que estava doente.
Para mim, eu só irei parar de aprender quando for impossível fisicamente. Até lá, estamos aí!
E você, o que achou desse juramento como uma base filosófica para o exercício da profissão de pessoa desenvolvedora?
Até!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
