jorativo, o que implica que o rotulado não tem o foco para realmente mergulhar em um assunto e dominá-lo. Mas, quando sua loja online está fora do ar e você está
perdendo centenas de vendas conforme o tempo passa, é o conhece um pouco de
tudo que não só sabe como funciona o código do aplicativo, mas também pode fazer debug dos processos no servidor web rodando em UNIX, analisar a configuração do
seu banco de dados para possíveis gargalos de performance, e verificar a configura-
ção de seu roteador de rede para encontrar problemas difíceis. E, mais importante, depois de encontrar o problema, o conhece um pouco de tudo pode rapidamente
tomar decisões de arquitetura e de design, implementar correções de código, e implantar uma correção para o sistema em produção. Neste cenário, a ideia de fábrica parece bem antiquada na melhor das hipóteses e terrivelmente falha na pior.
Outro ponto em que a fábrica de software não funciona é que, em contraste com
uma linha de montagem em que o trabalho continua vindo em um fluxo constante,
projetos de software são geralmente cíclicos. Não só o fluxo dos projetos são cíclicos, mas o trabalho dentro de um projeto também é. Um programador fica lá sentado na
28
Casa do Código
Capítulo 7. Seja generalista
cadeira enquanto os requisitos estão sendo especificados, arquitetados e projetados, ou o programador trabalha ao mesmo tempo em vários projetos. O problema com
os programadores multitarefa é que, apesar das intenções da fábrica de software, quando o bicho pega, os programadores se baseiam bastante no contexto e na experiência para concluir seus trabalhos. Requisitos, arquitetura e documentos de design podem ser um começo, mas no final, se os programadores não entenderem o que o
sistema deve fazer, eles não serão capazes de implementá-lo bem.
Claro que aqui eu não estou pegando no pé só de programadores. O mesmo
é verdade em quase todas os pontos da linha de montagem de software. Contexto
importa, e ser multitarefa não funciona. Como resultado, temos um sistema de pro-dução ineficiente.
Já houve várias tentativas de resolver este problema de ineficiência, sem sair do sistema de produção de inspiração em fábricas, mas ainda não descobrimos como otimizar nossas fábricas de software a um nível aceitável.
Se você é apenas um programador, ou um testador, ou um designer, ou um
arquiteto, você vai se encontrar ocioso ou fazendo trabalho pesado e sem importância durante vários momentos do seu projeto. Se você é apenas um programador
J2EE, ou um programador .NET, ou um programador de sistemas UNIX, você não
vai ter muito a contribuir quando o foco de um projeto ou de uma empresa de mu-
dar, mesmo que temporariamente, da sua área de foco. Não é sobre onde você está
na cadeia de valor de trabalho percebido do projeto (onde o arquiteto tem o posto mais alto da realeza). É sobre o quão útil você é.
Se seu objetivo é ser a última pessoa de pé em meio a rodadas de demissões ou
terceirização de trabalho, é melhor se tornar genericamente útil. Se você tem medo de que o seu escritório de desenvolvimento, que antes era lotado, vire a casa de um bando de gente estranha, ajudaria se você percebesse que quando o time tem apenas algumas vagas, o só testador ou o apenas codificador não serão requisitados.
Melhor, se você só quer se destacar e ser notável, envolver-se no todo é o melhor que você faz.
Generalistas são raros...e por isso, preciosos.
O caminho para se tornar um generalista é não se rotular com um papel especí-
fico ou tecnologia. Podemos nos tornar flexíveis em nossas carreiras de muitas maneiras. Para entender o que significa ser um generalista, podemos dar uma olhada em como está o cenário das carreiras de TI, em diferentes aspectos independentes.
29
Casa do Código
Eu consigo pensar em cinco, mas é claro que há uma infinidade (tudo depende de
como você separa os assuntos):
Degrau na escada da carreira;
Plataforma / OS;
Código x dados;
Sistemas x aplicações;
Negócio x TI.
Essas são diferentes formas pelas quais você poderia abordar o problema de se
tornar um generalista. Esta é apenas uma maneira de pensar sobre toda a sua car-
reira, e você provavelmente pode ter uma lista melhor para si próprio. Por agora, vamos discutir esses pontos.
Primeiro, você pode optar por ser um líder ou gerente, ou ser uma pessoa téc-
nica. Ou, você pode se autoclassificar um arquiteto em vez de ser um programador ou testador. A capacidade de ser flexível nos papéis que você pode e vai ter é um atributo cujo valor muitas pessoas não compreendem. Por exemplo, enquanto um
líder forte deve evitar ao máximo se intrometer, esse novo mundo de equipes de
desenvolvedores terceirizados pode se beneficiar de uma pessoa que sabe como li-
derar pessoas e projetos, mas também pode arregaçar as mangas e corrigir alguns
bugs críticos de última hora, enquanto a equipe offshore está dormindo. O mesmo
vale para um arquiteto de software que possa acelerar dramaticamente o progresso em um projeto se ele escrever um pouco de código. Quando se trata de atravessar