O que é ser Dev?

Introdução

Recentemente, eu tirei um tempo para refletir sobre algumas coisas que, relendo livros como "The Mythical Man-Month", "A Philosophy of Software Design" e outros, me fizeram pensar bastante sobre o nosso trabalho como desenvolvedores e quero compartilhar com você um pouco das conclusões que cheguei.

A Reflexão

É comum pensar que o trabalho de um desenvolvedor de software se resume a escrever código. Damos comandos, a máquina obedece, e funcionalidades surgem na tela. Mas essa percepção, embora tecnicamente correta, é superficial. Ela ignora a essência do nosso trabalho de fato, a verdadeira matéria-prima com que trabalhamos.

Assim como um poeta, o programador lida com conceitos abstratos, com a pura matéria do pensamento. Frederick Brooks, autor de The Mythical Man-Month, capturou essa ideia de forma brilhante:

"O programador, como o poeta, trabalha apenas um pouco afastado da pura matéria do pensamento. Ele constrói seus castelos no ar, a partir do ar, criando pelo esforço da imaginação."

O código que escrevemos é apenas a ferramenta visível, o andaime de nossos castelos. O que realmente construímos é muito mais profundo, complexo e duradouro. Vamos desconstruir nosso trabalho para revelar as cinco fundações invisíveis que realmente sustentam os "castelos no ar" que construímos: as abstrações, os sistemas vivos, o conhecimento compartilhado, as culturas de equipe e a integridade conceitual.

1. Construímos Abstrações, Não Apenas Funcionalidades

Uma das lições mais difíceis que aprendemos ao longo da carreira é que nossa verdadeira tarefa não é apenas entregar funcionalidades, mas sim domar a complexidade. E a ferramenta mais poderosa que temos para isso é a abstração, cujo principal objetivo é o ocultamento de informação (information hiding).

John Ousterhout, em A Philosophy of Software Design, introduz a distinção entre "módulos profundos" e "módulos rasos".

• Módulos profundos possuem interfaces simples, mas encapsulam implementações complexas e poderosas. Pense no sistema de arquivos de um sistema operacional Unix. Ele esconde uma enorme quantidade de detalhes e complexidade, oferecendo uma interface limpa e de alto nível.
• Módulos rasos, por outro lado, têm interfaces complexas que expõem muitos detalhes da implementação. Em vez de esconder a complexidade, eles a vazam para o resto do sistema. Ousterhout adverte contra um antipadrão comum que leva a isso: a "classite" (classitis), a tendência de criar classes pequenas e rasas em excesso, que acabam por aumentar a complexidade geral.

O verdadeiro valor de um bom desenvolvedor não está na velocidade com que ele entrega funcionalidades, mas em sua capacidade de criar essas abstrações profundas. É essa prática de ocultamento de informação que nos permite alcançar o que Ousterhout descreve como o estado ideal do design de software:

"Uma das técnicas mais importantes para gerenciar a complexidade do software é projetar sistemas de modo que os desenvolvedores precisem enfrentar apenas uma pequena fração da complexidade geral a qualquer momento."

Portanto, nosso primeiro produto não é a funcionalidade em si, mas a simplicidade e a clareza que uma boa abstração proporciona. Este ato de construir abstrações profundas e atemporais é precisamente o que nos permite gerenciar a próxima dimensão crítica do nosso trabalho: o tempo.

2. Construímos Sistemas Para o Futuro, Gerenciando o Tempo

Qual a diferença entre "programação" e "engenharia de software"? O livro Software Engineering at Google oferece uma definição sucinta e poderosa que coloca o tempo no centro da questão.

"Engenharia de software é programação integrada ao longo do tempo."

Nós não criamos artefatos estáticos. Construímos sistemas vivos que devem ser mantidos, adaptados e escalados por anos, talvez décadas. Ignorar a dimensão do tempo é ignorar a essência da engenharia. O nosso verdadeiro desafio é garantir a sustentabilidade do software, que, como define o livro do Google, é a nossa capacidade de responder a mudanças ao longo da vida útil esperada do código. Podemos até escolher não mudar algo, mas precisamos ter a capacidade de fazê-lo.

Para ilustrar a responsabilidade que temos com o futuro, basta lembrar da "Lei de Hyrum": com um número suficiente de usuários, todos os comportamentos observáveis do seu sistema se tornarão dependentes de alguém, independentemente do que você prometeu no contrato da sua API.

Um exemplo da "Lei de Hyrum":

Formato de Saída de API: Imagine que uma API prometa uma lista ordenada alfabeticamente, mas, por coincidência, ela sempre a devolve em letras minúsculas. Se os usuários começarem a contar com esse resultado em minúsculas (mesmo que não esteja no contrato), quando o código for "consertado" para retornar maiúsculas e minúsculas (o que seria tecnicamente correto), o código de terceiros quebra.

Isso significa que, mesmo os detalhes de implementação que considerávamos irrelevantes podem se tornar, com o tempo, parte do contrato implícito com nossos usuários, tornando as mudanças futuras exponencialmente mais custosas.

Nosso trabalho nunca está "finalizado". Estamos em um estado constante de manutenção e evolução. A sustentabilidade de um sistema a longo prazo, sua capacidade de mudar, é um produto muito mais importante do que o seu conjunto inicial de features.

3. Construímos Valor e Conhecimento, Não Apenas Código

É preciso mudar o foco do "o quê" (o código) para o "porquê" (o valor). Como defende John Sonmez em Soft Skills, o objetivo principal de um desenvolvedor é "agregar valor aos outros". Essa ideia é a base de como devemos nos posicionar e "vender" nosso trabalho como profissionais: o valor que geramos é o nosso verdadeiro produto. O código é o meio, não o fim.

Nesse contexto, é fundamental lembrar de uma máxima repetida em Software Engineering at Google: "o código é lido muito mais vezes do que é escrito". Isso significa que nosso público principal não é o compilador, mas outros seres humanos, incluindo nosso eu do futuro.

A clareza, a consistência e a escolha de bons nomes não são apenas "boas práticas". Elas são a essência do nosso trabalho. Ao escrever código claro e "óbvio", como Ousterhout defende, estamos, na verdade, construindo um corpo de conhecimento compartilhado. Estamos documentando a lógica do negócio e as decisões de design de uma forma que pode ser compreendida e evoluída por outros.

O produto real que entregamos é a capacidade de outra pessoa entender, manter e estender o sistema. O valor reside nessa continuidade e colaboração, não em linhas de código isoladas.

4. Construímos Equipes e Cultura, Não Apenas Soluções Individuais

A indústria de software é assombrada pelo "Mito do Gênio" solitário, o programador brilhante que, trancado em uma sala, resolve problemas complexos sozinho. O livro Software Engineering at Google desmistifica essa ideia, afirmando que, embora o trabalho raramente exija um intelecto genial, "100% do trabalho requer um nível mínimo de habilidades sociais".

O maior gargalo em projetos de software não é a velocidade de codificação individual, mas a comunicação entre os membros da equipe. Frederick Brooks formulou essa observação em sua famosa lei:

"Adicionar mais pessoas a um projeto de software atrasado o torna ainda mais atrasado."

Ao projetarmos sistemas, estamos, indiretamente, projetando a forma como as equipes interagem com eles e entre si. A estrutura do nosso software, seus módulos, interfaces e limites, define os canais de comunicação e as dependências entre as pessoas. Um ambiente de "segurança psicológica", onde os membros da equipe se sentem seguros para perguntar, errar e aprender, é crucial para o sucesso.

Um sistema de software bem-sucedido é, em última análise, o subproduto de uma equipe bem-sucedida e funcional. Portanto, parte do nosso trabalho é construir o ambiente, a cultura e as estruturas técnicas que permitem essa colaboração eficaz. Quando uma equipe atinge esse nível de harmonia funcional e segurança psicológica, ela se torna capaz de buscar o objetivo final e mais difícil do nosso trabalho: a integridade conceitual.

5. Construímos Integridade Conceitual, Não Apenas um Conjunto de Partes

O ápice do nosso trabalho talvez seja a busca pela "integridade conceitual", um termo cunhado por Frederick Brooks. Ele representa a ideia de que um sistema deve ser guiado por uma visão unificada e coesa, em vez de ser uma colcha de retalhos de boas ideias desconexas.

Brooks usa a poderosa analogia da Catedral de Reims. A beleza e a longevidade da catedral não vêm de ornamentos individuais brilhantes, mas da autonegação de gerações de construtores que sacrificaram suas próprias ideias para manter uma visão arquitetônica unificada e pura.

"É melhor omitir alguns recursos e melhorias anômalas em favor da integridade conceitual de um sistema, do que ter um sistema que contém muitas ideias boas, mas independentes e não coordenadas." - Frederick Brooks

É aqui que nosso trabalho atinge a maturidade: aprendemos que nosso papel, muitas vezes, não é adicionar mais, mas garantir que o que já existe forme um todo coeso e elegante. Isso significa saber dizer "não". Significa fazer as difíceis escolhas de design que servem à visão de longo prazo do sistema, e não a um recurso específico ou a uma pressão momentânea. É a defesa dessa integridade que transforma um amontoado de funcionalidades em um sistema robusto.

Conclusão: O Que Você Está Construindo Hoje?

O ato de escrever código é apenas a ponta do iceberg. Somos muito mais do que digitadores de instruções. Assumimos papéis muito mais importantes: somos arquitetos de abstrações, guardiões de sistemas que evoluem com o tempo, curadores de valor e conhecimento compartilhado, construtores de comunidades colaborativas e, acima de tudo, defensores da integridade conceitual. Essa é a nossa verdadeira identidade profissional.

Da próxima vez que você abrir seu editor, pergunte a si mesmo: além do código, o que você está realmente construindo hoje?