Se você não refletir cuidadosamente, talvez pense que programar é apenas digitar expressões em uma linguagem de programação. Ward Cunningham, no prefácio de The Pragmatic Programmer

Desenvolvimento de software – projetar, resolver problemas, surgir com um novo algoritmo otimizado, aprender uma nova linguagem, refatorar código bagunçado em algo breve e elegante – exige trabalho duro.

Quando você está tentando fazer algo que nunca fez antes – ou que ninguém jamais fez – ou quando  já fez algo antes, mas jura por Deus que não vai cometer os mesmos erros novamente e precisa de tempo para pensar sobre como fazer as coisas de uma forma melhor; ou quando você está tentando entender código que outra pessoa escreveu para só então modificá-lo, ou quando está caçando um bug feio: tudo isso pode tomar muito tempo, mas no final você não terá muito código para mostrar.

E há todo um outro trabalho de desenvolvimento – trabalho que necessita muita digitação e nem tanta reflexão. Quando fica claro o que você precisa fazer e como fazer, mas você tem uma quantidade horrível de código para entender antes de fazer o trabalho. Você já fez isso antes e apenas precisa fazer novamente: outro script, outra tela, outro relatório e outro depois desse. Ou quando a maior parte da reflexão já foi feita para você: alguém preparou os wireframes e te disse exatamente como o aplicativo irá se comportar, se parecer e fluir; ou quando especificaram a API em detalhe, então tudo o que você precisa fazer é digitá-la e tentar não cometer muitos erros.

Debugar é pensar. Corrigir o bug, fazer com que a correção passe no teste e aplicá-la é, na maior parte, digitação. Projeto e desenvolvimento no estágio inicial, testes de estresse para checar a tecnologia e definir a arquitetura são reflexão pesada. Fazer a terceira, a quarta ou a 100ª tela ou relatório é digitação. Design de UX e prototipagem: reflexão. Fazer as telas de configuração e CRUD de manutenção: digitação. Surgir com uma ideia nova para um aplicativo móvel é pensar. Fazê-lo funcionar é digitação. Resolver problemas comuns do negócio exige digitação pesada. Otimizar processos de negócios por meio de software exige muita reflexão.

Alguém voltado para a reflexão e alguém mais voltado para a digitação são pessoas fazendo dois tipos muito diferentes de trabalho e precisam ser gerenciadas de maneira diferente.

Às vezes, programar é apenas digitar

Somos digitadores primeiro e programadores em segundo. Jeff Atwood, Programming Horror

Muitos aplicativos corporativos são essencialmente rasos. Muitas tabelas de bases de dados e muitos arquivos com muitos elementos de dados e telas de CRUD com diversos relatórios que são muito parecidos com outras telas e relatórios e, então, há restrições legais e dependências operacionais para tomar conta. Longas listas de requisitos funcionais, muitas perguntas para fazer e se certificar de que todos entendem as necessidades – muitos detalhes para serem lembrados e acompanhados.

Banking, seguro, governo, contabilidade, relatórios financeiros e de cobranças, gerenciamento de inventário, sistemas ERP e CRM, aplicativos de escritório e outros sistemas de livro-caixa e acompanhamento de registros são assim. O mesmo acontece com muitos portais e lojas online. Alguns trabalhos de manutenção – atualização de plataformas, trabalho de integração de sistemas, mudanças de impostos e taxas – também são assim.

Você está construindo uma casa, uma ponte ou um shopping e, talvez, reformando um. Grandes problemas geralmente se alongam e são difíceis de resolver. É necessário muita digitação. Mas é algo que já foi feito muitas vezes antes, e o trabalho envolve, na maior parte, problemas familiares que você pode resolver com padrões conhecidos e ferramentas e formas de trabalho já testados.

Eu vi o código do seu programa ontem. Pareceu fácil. É apenas um amontoado de digitação. E metade das palavras estavam escritas errado. Não me explique o seu uso excessivo de vírgulas.

The Pointy Haired Boss vê um código real.

Depois que o projeto já está definido, a maior parte do trabalho é entender e lidar com os detalhes, administrar e coordenar as pessoas para que elas entreguem o código. Trata-se de gerenciamento clássico de projetos/programas: orçamento e planejamento, acompanhamento dos custos e mudanças e administração sem mexer em nada. Trata-se de logística, escala, consistência, eficiência e de impedir que o trabalho saia dos trilhos.

Pense, pense, pense

Outros problemas: projetar uma engine de jogos, um algoritmo de comércio, logística ou administração de risco online, otimização em tempo real de controles de sistemas necessitam muito mais de reflexão do que de digitação. Esses sistemas possuem alta demanda por requisitos não-técnicos (escalabilidade, desempenho em tempo real, integridade de dados e precisão) e de lógica complexa, mas eles estão focados em resolver um conjunto restrito de problemas. Um pequeno grupo de pessoas espertas pode colocar suas cabeças para funcionar e resolver a maior parte deles. Ainda vai haver digitação para ser feita, especialmente ao redor: a moldura, o encanamento e a fiação, mas o cerne do trabalho é normalmente feito com uma quantidade surpreendentemente pequena de código – especialmente depois que você joga fora os experimentos e os protótipos.

É daí que vem muito da magia de um software – os algoritmos proprietários ou patenteados e as “sacadas” de design que repousam no coração do sistema. O tipo de trabalho que leva muito tempo de pesquisa e muita prototipagem, habilidade de resolução de problemas, verdadeira habilidade técnica e conhecimento aprofundado da área, ou ambos.

Digitação e reflexão são tipos diferentes de trabalho

A necessidade de reflexão ou digitação dita, em sua maioria, quantas pessoas você precisa e quer ter no time e que tipo de pessoa você quer que faça o trabalho. Isso muda a forma como as pessoas trabalham juntas e como é preciso gerenciá-las. Digitação pode ser terceirizada. Reflexão não. Você precisa distinguir quais problemas podem ser resolvidos com digitação e o que não pode, e quando reflexão vira digitação.

Trabalho reflexivo pode e deve ser feito por pequenos times de especialistas que trabalham juntos – ou por um gênio trabalhando sozinho. Você não precisa, ou não quer, muitas pessoas ao tentar criar um projeto ou resolver um problema difícil, executar experimentos e iterar. Quem quer que esteja trabalhando no problema precisa estar imerso no contexto do problema, com tempo para aprender e explorar alternativas, chances de cometer erros ou de apenas olhar pela janela quando ficarem “empacados”.

É neste momento que erros fundamentais podem ser cometidos: quebras de arquitetura, cancelamento de projetos e erros que encerram uma carreira. Escolha errada da plataforma tecnológica. Tolerância errada de tempo real. Levar muito tempo para encontrar (ou nunca encontrar) problemas de confiabilidade. Escolher mal as pessoas ou tentar resolver o problema errado. Errar o alvo.

Administrar esse tipo de problema envolve ter as melhores pessoas que você puder encontrar, certificar-se de que elas têm as informações e as ferramentas certas, fazer com que elas fiquem focadas, olhar para os riscos com distância e manter os problemas fora do caminho.

Pensar não é previsível. Não há “copiar e colar” porque não há de onde “copiar e colar”. Não dá para estimar, porque você não sabe aquilo que precisa saber. Mas é possível colocar limites – tentar conseguir a melhor solução no tempo disponível.

Digitar é previsível. Você pode estimar – e precisa. O truque é incluir todas as coisas que precisam ser digitadas e contabilizar todos os pequenos erros e variações ao longo do caminho – porque eles irão se acumular rápido. Negligência, atalhos, má compreensão dos requisitos, pular os testes, copiar e colar, os tipos de coisas que aumentam os custos agora e no futuro.

Digitar é trabalho de jornada. Você não precisa de experts, apenas de pessoas que são competentes, que entendem os fundamentos da linguagem e das ferramentas e que sejam cuidadosas, sigam as instruções e possam pacientemente lidar com todo o código que é necessário – apesar de alguns desenvolvedores seniores poderem superar um time muito maior, pelo menos até que eles fiquem entediados. Gerenciar um bando de digitadores necessita de outras habilidades e abordagem: você precisa ser político e diplomático, ter tino logístico, ser aquele que define as metas, um administrador e um economista. Você está administrando riscos humanos e do projeto, não riscos técnicos.

Ao longo do tempo, o projeto vai mudando de reflexão para digitação – quando a maior parte do duro trabalho de “não tenho certeza do que precisamos ou como vamos fazer isso” estiver resolvida e as incertezas forem na maior parte conhecidas, é hora de preencher os detalhes e correr com as coisas.

A quantidade de digitação que precisa ser feita aumenta na medida em que você consegue mais clientes e precisa lidar com mais interfaces, lugares, personalizações e mais questões de administração, restrições administrativas e suporte. O sistema continua a crescer, mas a maior parte dos problemas são familiares e resolvíveis. Há muito código para olhar, entender e copiar. Você precisa de pessoas que consigam pegar o jeito e digitar rápido.

Refletindo e digitando

Reflexão e digitação são ambas partes importantes do desenvolvimento de software.

Em “Programming is Not Just Typing”, Brendan Enrick explica que a razão pela qual a programação pareada (pair programming) funciona é porque ela permite que as pessoas foquem em digitar e em pensar ao mesmo tempo.

Ambas as pessoas estão pensando, mas sobre coisas diferentes. Um desenvolvedor tem o teclado em um determinado momento e mantém sua cabeça nesse sentido. (Esse cara está preocupado com a velocidade da digitação). Ele digita ao longo do tempo, pensando no código que está atualmente escrevendo, não na estrutura do aplicativo, mas no código que ele está digitando naquele momento. Por um curto período de tempo, a velocidade de sua digitação é importante.

O programador da dupla que não está digitando está gastando todo o seu tempo em pensar. Ele mantém em mente o caminho que digitador está seguindo sem se preocupar com a sintaxe da linguagem de programação. É o outro cara que está pensando na sintaxe da linguagem. O outro, sentado atrás dele sem o teclado, é o guia. Ele precisa ter certeza de que a dupla está no caminho certo e usando a rota mais eficiente para ser bem-sucedido.

É necessário mais do que digitar para ser um bom desenvolvedor – e é preciso mais do que ser capaz de pressionar algumas teclas no tocante à digitação. Isso significa ser bom nos fundamentos: saber bem a linguagem, conhecer as suas ferramentas e como utilizá-las, como se guiar pelo código, saber escrever código – tanto quanto ser rápido no teclado. Dominar a mecânica, conhecer as ferramentas e ser capaz de digitar rápido, para que você seja fluente e fluido, são características essenciais para ser bem-sucedido como um desenvolvedor. Não deprecie a importância de um digitador. E não deixe que a digitação (não ser capaz de digitar) fique no caminho da reflexão.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://www.swreflections.blogspot.com.br/2013/10/programming-thinking-or-typing-thinking.html