Durante cerca de quatro meses, fiz parte de um grupo de estudos centrado no livro “The Pragmatic Programmer”, de David Thomas e Andrew Hunt. O grupo fazia reuniões remotas semanais para discutir a seção planejada para aquela semana. Nessas reuniões, geralmente eram cerca de cinco pessoas e discutíamos tópico por tópico. Depois de várias semanas, terminamos o livro.

Antes do início do grupo de estudo, este livro me foi recomendado por algumas pessoas que conheço. No entanto, eu tinha minhas dúvidas se ser um programador “pragmático” era bom, pois discordo do pragmatismo na filosofia. Portanto, minha primeira pergunta ao entrar neste livro foi sobre o significado de “pragmático”. E os autores abordam essa questão logo no prefácio. Aqui está uma citação que mostra como os autores veem o pragmatismo neste contexto:

“Não existem respostas fáceis. Não existe a melhor solução, seja uma ferramenta, uma linguagem ou um sistema operacional. Só pode haver sistemas que sejam mais apropriados em um determinado conjunto de circunstâncias.

É aqui que entra o pragmatismo. Você não deve se apegar a nenhuma tecnologia em particular, mas ter um histórico e uma base de experiência amplos o suficiente para permitir que você escolha boas soluções em situações específicas.”

Concordo que você não deve se limitar a uma tecnologia específica e aplicá-la a todos os problemas que encontrar. Na verdade, concordo com a maior parte desta citação. Só não concordo com o uso da palavra “pragmatismo” aqui. Posso ver alguma semelhança com os pragmáticos na ética, mas não acho que seja uma boa comparação. De acordo com os pragmatistas, você não deve confiar em princípios ou padrões ou valores absolutos, não existe realidade objetiva ou verdade permanente, a verdade é “o que funciona”. No entanto, para decidir se algo “funciona” ou não, você precisa de uma forma de julgar, então você precisa de um conjunto de valores, e os pragmáticos são contra um conjunto “rígido” de valores. Por exemplo, compartilhar seu conhecimento com outras pessoas em sua empresa é algo que funciona? Isso depende dos seus valores. Se você valoriza que sua empresa possa produzir mais e melhor para os clientes, sim. Se você valoriza ser a única pessoa que pode fazer esse trabalho para manter seu emprego, então não. O pragmatismo não oferece nenhuma orientação sobre quais deveriam ser seus valores. Olhando desta forma, a ética pragmática é basicamente sem conteúdo e não oferece orientação alguma. A primeira dica numerada do livro já vai na contramão do pragmatismo: “Cuide do seu ofício”. Isso indica explicitamente que você deve valorizar seu ofício.

Assim, para que a definição de pragmatismo dos autores esteja correta, basear-se em princípios éticos deveria ser equivalente a confiar em uma determinada tecnologia no desenvolvimento de software. Mas um princípio e uma tecnologia particular são completamente diferentes. Um princípio oferece orientação, não uma solução, e uma tecnologia específica oferece uma solução ou parte de uma solução, não orientação. E, depois de ler o livro, pude ver claramente que os autores oferecem princípios e se preocupam muito em segui-los. Sim, esses princípios foram derivados de suas experiências, mas uma abordagem pragmática seria não generalizar e sempre pensar que cada contexto é completamente diferente e não adiantaria princípios generalizados.

Tudo isso para dizer que, como vejo a palavra pragmatismo como algo inútil que não oferece nenhuma orientação e discordo do que os autores chamam de pragmatismo, isso significa que acho que os autores podem me fornecer uma boa orientação neste livro. Em outras palavras, estou feliz por discordar deles nesse termo, caso contrário, não acharia este livro útil. Agora posso falar sobre o que realmente gosto nele, que é todo o resto.

Eu não classificaria “The Pragmatic Programmer” como um livro técnico. Claro, existem assuntos técnicos e exemplos de código, mas é muito mais do que isso. É mais uma filosofia de trabalho para desenvolvedores. Isso fica claro logo no prefácio, onde encontramos as duas primeiras dicas numeradas: “Cuide do seu ofício” e “Pense! No seu trabalho”. Isso é filosofia, e isso é bom. A filosofia é necessária a todo ser humano. E essas duas dicas estão muito integradas. Afinal, se você se preocupa com o seu ofício, pensará nele constantemente. E se você está pensando em seu trabalho constantemente, isso significa que você se importa com ele. Essa integração é muito prevalente ao longo do livro. Todos os tópicos se relacionam de alguma forma. E é assim que uma filosofia deve ser.

Os autores mostram que a independência e a individualidade são muito valiosas. Você pode agir por conta própria. Se você está infeliz onde está, tem a capacidade de mudar isso. Você será capaz de mudar sua situação com mais facilidade se melhorar continuamente. E os programadores podem trabalhar em projetos que podem mudar a vida de outras pessoas ou até mesmo o mundo. Os desenvolvedores podem ser um catalisador para a mudança. Se você vê a si mesmo e ao seu trabalho dessa maneira, perceberá que possui grande independência e grande poder. “Mas com grandes poderes, vêm grandes responsabilidades”. Outras pessoas precisam confiar em você para lhe dar esse tipo de responsabilidade, e sua equipe também precisa confiar em você. Portanto, ser honesto, reconhecer seus erros e assumir responsabilidades são essenciais. Não dê desculpas. E além de confiar que você é responsável, as pessoas precisam confiar que você vai entregar algo com qualidade e que as encante. E como você se preocupa com o seu ofício, vai querer se orgulhar do seu trabalho e, com isso, fará do seu nome um atestado de qualidade.

Esses foram os pontos centrais do livro a meu ver, porque todo o resto visa ajudar os leitores a serem mais independentes, dignos de confiança, orgulhosos do que estão fazendo e continuam fazendo. E há muitas dicas e orientações úteis para conseguir isso e não posso citar todas neste post. Mas posso listar alguns de uma forma muito inter-relacionada:

Trabalhe com etapas incrementais. Forneça uma pequena coisa que funcione de ponta a ponta para obter feedback de seus usuários rapidamente e garantir que você esteja “atingindo o alvo” (isso é chamado de abordagem “marcador”). Dessa forma, todo o seu projeto é um processo de levantamento de requisitos. E para poder mudar o que foi entregue após receber o feedback, o design deve ser Easy To Change (princípio ETC). Se houver uma crise e você precisar mudar algo em uma emergência, você ainda não deve quebrar o princípio ETC ou outros princípios de bom design. Resolver uma crise não significa que você deva tolerar facilmente danos colaterais, caso contrário, as pessoas deixarão de se preocupar em ter um bom design no projeto e você não poderá alterá-lo facilmente em resposta ao feedback. Outro fator que ajuda você a responder ao feedback é a capacidade de implantar suas alterações rapidamente para os usuários, o que torna a automação e a entrega contínua importantes.

Também houve alguns tópicos que foram levantados durante a reunião de encerramento do grupo de estudo. Uma delas foi a ideia de escrever diários. Todos os dias, escreva sobre o que está trabalhando, decisões que tomou, ideias que não pode explorar naquele momento, entre outras coisas. Ao fazer isso, você pode se lembrar de algumas coisas importantes no futuro e também sentir alguma nostalgia. Outro assunto foi sobre comunicação. Você deve se comunicar de forma que outras pessoas possam entender a mensagem. Isso envolve dizer a mesma coisa de maneiras diferentes, dependendo do seu público. Se for por escrito, faça bem formatado, bem escrito, sem erros ortográficos. Seja um bom ouvinte. E sempre responda, mesmo que seja algo como “eu ligo para você”.

Novamente, há muito mais dicas úteis neste livro. Eu não conseguiria explicá-los todos da maneira que os autores fizeram, principalmente porque não tenho tanta experiência quanto eles. Então, minha sugestão é: leia “The Pragmatic Programmer” de David Thomas e Andrew Hunt para se tornar um melhor solucionador de problemas, programador, desenvolvedor ou como você quiser chamar esse ofício. Esses dois autores têm mais de vinte anos de experiência e estão entre os autores originais do Manifesto Ágil. Eles escreveram as conclusões e opiniões que formaram com toda essa experiência em uma linguagem muito acessível. Portanto, leia este livro para obter um atalho que economiza muito tempo.