Por que todo programador deveria escrever
Os três níveis de escrita
Talvez você não tenha percebido, mas grande parte do dia de um programador é dedicado a escrever: código, comentários, emails, mensagens – seja em português, inglês, Python ou JavaScript –, estamos sempre convertendo pensamentos em caracteres. Ou, da forma como prefiro enxergar, transformando abstrações em atos concretos.
Você pode argumentar que comparar a escrita de código com texto (ou seja, linguagem natural) é forçar a barra. Eu discordo. Na verdade, repito incessantemente que os códigos mais legíveis são aqueles que se aproximam o máximo possível de como um humano leria: nomes de variáveis e funções, e até mesmo a hierarquia lógica de um programa de computador precisa se assemelhar ao que estamos habituados em textos não-técnicos.
Em 2019 publiquei um artigo chamado How to Become a Bad Developer, que se tornou meu texto mais lido desde então. Nele, enumero atitudes que contribuem para piorar a qualidade do trabalho de um programador. O último erro listado – e também o mais importante – representa bem o que quero dizer: write for machines, not humans. Eis a conclusão:
Think about what makes a text enjoyable to you. It is usually concise, clear, direct, meaningful and consistent. You won't enjoy reading when you can't understand the author, the narrative doesn't make sense, it's poorly written or weirdly formatted. Likewise, code that does not make sense and that you need to strive to grasp is an excellent form of discouraging the reader. And the same way an author who discourages their readers is a bad author, a developer who discourages their readers is a bad developer.
Mas a necessidade de escrever bem vai além de manter um código legível, coeso e acessível a outros humanos. Gostaria de explorar outros aspectos onde o hábito de escrever pode não apenas alavancar sua carreira, mas transformá-lo numa pessoa melhor.
A escrita como validação técnica
O primeiro artigo que publiquei na internet foi em 18 de Junho de 2015, há exatos 10 anos. Foi um post sobre como converter dados em formato JSON para CSV em um framework chamado Meteor. Ninguém mais tem interesse nesse assunto hoje: seja porque o Meteor perdeu apelo, qualquer IA resolve esse problema em 2 segundos, ou as bibliotecas mencionadas já não existem mais, fato é que esse texto dificilmente cumpre o propósito original de informar o leitor.
No entanto, ele cumpre um outro papel tão importante quanto: ele é a legitimação, o registro histórico de que eu estou há pelo menos 10 anos no game. Dois meses depois, eu publiquei meu primeiro artigo sobre React. Ou seja: é inegável e facilmente comprovável que eu tenho pelo menos 10 anos de experiência com React, a biblioteca mais utilizada para construção de interfaces modernas.
E qual a importância de mostrar, na internet, que você sabe o que está dizendo que sabe? Bem, esse detalhe pode ser o diferencial na hora de ser contratado, por exemplo. Como disse no artigo 3 conselhos práticos para crescer na carreira como programador, meu primeiro emprego nos Estados Unidos veio após ser cold called por uma empresa que achou um dos meus artigos online.
Nunca fui famoso, meus textos nunca foram muito repercutidos (à exceção do How to Become a Bad Developer que chegou a ser front page do HackerNews), e esse não é um caso da seleção natural em ação (quando alguém bem sucedido ensina como ser bem sucedido embora em um nicho onde poucos podem ser bem sucedidos). Não, meus textos tinham alcances medíocres, eram lidos por pouquíssimas pessoas, e mesmo assim serviram para criar uma autoridade que me credenciou à carreira internacional.
Você pode achar que não tem nada interessante para falar, mas isso não é verdade. Como programadores, todos os dias resolvemos quebra-cabeças. É uma das poucas profissões onde estamos sempre aprendendo algo novo. Cristalize esse aprendizado: isso fará bem para você, sua carreira, e seus leitores (ainda que poucos).
A escrita como forma de comunicação
Trabalhar com programação é um esforço coletivo – ainda que você seja o único a escrever código. Se você tem clientes, precisa entender suas dificuldades e comunicar a solução. Se tem stakeholders, precisa entender suas demandas e pain points e argumentar a melhor forma de resolvê-los. Se tem companheiros de time, precisa comunicar suas dúvidas, treinar novos programadores, escrever documentação.
Toda essa necessidade é ainda amplificada se você trabalha remoto. Desprovido do tête-à-tête de um escritório convencional, você precisará se comunicar de forma mais eficiente, muitas vezes por escrito (afinal, a colaboração remota é feita de forma majoritariamente assíncrona).
Existe toda uma etiqueta de trabalho remoto que é fundamental para quem deseja performar nesse modo: escrever mensagens diretas e concisas, ser claro na comunicação, não desperdiçar o tempo dos outros, etc. Mas o principal é o que ficou conhecido como rubber duck debugging.
Falei sobre essa forma inusitada de programação, além de complementar o que me proponho a explicar aqui, em um artigo da minha newsletter Ensaios:
Rubber duck debugging é um método extremamente eficaz para se debuggar um código (ou seja, tentar entender o porquê dele não funcionar adequadamente) que consiste em literalmente explicar o problema a um pato de borracha.
Esse método é eficaz pois quando tentamos explicar algo a alguém, organizamos nossos pensamentos de forma consciente, o que muitas vezes desembaralha nossa mente. É como se uma luz se acendesse durante a explicação, a solução se apresenta de forma óbvia. Mas isso só ocorre após ordenarmos os pensamentos para explicá-lo.
É por isso que sempre que alguém me procura para fazer um quick call eu peço que ela escreva primeiro qual é a dúvida. Esse requisito cumpre a função de 1) permitir que o trabalho flua de forma assíncrona e 2) servir de rubber duck para a pessoa, onde o mero ato de escrever (e por conseguinte organizar os pensamentos para perguntar) revela a solução. Já perdi as contas de quantas vezes esse método funcionou comigo.
Portanto, escrever irá ajudá-lo a entender melhor sua área. Não se preocupe com leitores, você está escrevendo para você. Se mais alguém se beneficiar, tanto melhor. Mas o objetivo principal é solidificar aquele conhecimento internamente. Não é coincidência que a maior parte das técnicas de retenção de leitura passe por anotar com suas próprias palavras o que você entendeu em um determinado capítulo (técnica famosamente compartilhada em livros como How to Take Smart Notes).
A escrita como forma de pensar
Quando falei da escrita como validação técnica, estamos no nível mais “baixo” da razão para se escrever: a mais utilitária, uma forma de “propaganda” da sua capacidade técnica.
Depois, subimos o nível para a escrita como forma de comunicação. Aqui essa habilidade transforma você num asset valioso para outros ao seu redor, e torna-o um verdadeiro team player. Se o primeiro nível te arruma um emprego, esse nível é o que te mantém nele.
Por fim, no nível mais elevado, a escrita desenvolve sua capacidade de pensar. Essa habilidade transcende seu trabalho ou a mera programação, mas expande o seu entendimento do mundo de modo que você passe a enxergar a razão por trás das coisas, a melhor forma de organizar um time, uma empresa, e em última análise, sua própria vida. Esse é o estágio que te faz progredir na carreira.
Essa, senhores, é a verdadeira razão pela qual devemos escrever. Transformar o blob de dados que povoa disformemente nossa mente em insights sobre o mundo, aquilo que permite que você trabalhe de forma mais inteligente.
Se eu não te convenci com esse argumento pseudo-filosófico, considere que na era das IAs qualquer modelo, no limite, irá programar melhor que você. Essa é uma competição que estamos fadados a perder. Porém, uma IA nunca pensará melhor que nós – pois elas não conseguem pensar. Não acredita em mim? Pois a própria Apple publicou um paper recentemente chamado The Illusion of Thinking chegando à mesma conclusão (não que tenha sido uma grande descoberta, uma vez que esse fato é facilmente observável sob uma ótica metafísica, mas deixemos isso para outro dia).
Nessa era das máquinas, vencerá aquele que conseguir exercer sua humanidade – aquilo que somente nós conseguimos. Pensar, criar, observar o mundo ao nosso redor e identificar os mecanismos por trás das coisas, concatenar ideias para resolver problemas, tudo isso são habilidades essencialmente humanas pois partem da observação humana.
Evidentemente que a IA consegue “raciocinar” no sentido de gastar mais ou menos poder computacional num problema, explorando soluções. Mas a necessidade de resolver o problema, o ímpeto de melhorar, e o julgamento se a solução proposta ou implementada é satisfatória, isso nunca deve ser delegado, pois é precisamente o que nos diferencia de ser uma simples máquina de falar.
Mas pensar é uma habilidade que como todas as outras precisa ser treinada. E a melhor forma de fazê-la é através da escrita. É nesse momento, sozinho com seus pensamentos, que você tem a revelação: será que eu sei o que acho que sei? Eu sei o que eu quero? Por que eu quero isso? Treine não ser um NPC, treine seu entendimento do mundo, seja humilde em buscar auxílio em outros textos, construa sua própria rede de conhecimento e em breve você terá se tornado indispensável não só no seu trabalho, mas também aos que estão à sua volta.
Escreva para você. Ter audiência não é uma condição sine qua non para que a escrita valha a pena. Em alguns casos, ter leitores pode até atrapalhar – escreva para os outros e terminará perdendo a autenticidade. Não utilize o fato de ser programador como desculpa para não precisar ter um trato adequado com as palavras.
Quando precisei adicionar uma bio no Substack, nada me agradava. Tudo parecia errado, forçado, sem personalidade. Por fim, cheguei numa frase que no final das contas representa essência do artigo de hoje: Escrevo para homens e máquinas.