Fogo e Movimento

From The Joel on Software Translation Project

Revision as of 17:57, 26 March 2006 by Pv (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Por Joel Spolsky
Traduzido por Daniel Parente
Editado por Joe Reis
6 de Janeiro de 2002


Artigo original em inglês: Fire and Motion


Por vezes não consigo fazer nada daquilo que me proponho.

Claro, venho para o escritório, deambulo por aí, verifico o meu correio electrónico cada 10 segundos, navego na Web, e até executo algumas tarefas insensatas, como pagar a conta do American Express. Mas, não consigo voltar ao fluxo de ideias necessárias para escrever uma única linha de código.

Bored-tetris.gif

Estes turnos de improdutividade, geralmente, duram entre dois a três dias, mas houve épocas na minha carreira em que estive semanas seguidas sem ser capaz de produzir absolutamente nada. Como dizem, não estou na onda. Não estou na zona. Não estou em parte nenhuma.

Toda a gente tem este tipo de flutuações de disposição; para alguns são muito ligeiras, para outros podem ser muito mais profundas ou até anormais. Os períodos de improdutividade podem estar relacionados com outros estados de espírito mais melancólicos.

Isto faz-me pensar naqueles investigadores que dizem que basicamente as pessoas não podem controlar o que comem. Por isso, qualquer tentativa de fazer dieta está condenada a ser uma decisão de curto prazo e voltarão sempre, qual iô-iô emocional, ao seu peso natural. Enquanto programador, talvez não possa realmente controlar quando sou produtivo e apenas tenha de aceitar os períodos lentos, conjuntamente com os mais rápidos, e esperar que em média, o número de linhas de código seja suficiente para eu conseguir ter emprego.


Bored-onion.gif






O que me põe fora de mim, é ter consciência de conseguir fazer uma média de duas ou três horas de programação produtiva, desde o meu primeiro emprego como programador. Quando tive um estágio de verão na Microsoft, um companheiro disse-me que, na realidade, trabalhava apenas entre as 12 e as 17. Cinco horas, menos o tempo para o almoço, e a sua equipa adorava-o porque, mesmo assim, ainda conseguia fazer muito mais do que a média. Comigo, verifiquei que o mesmo era verdade. Sinto-me um pouco culpado quando vejo quão duramente parecem trabalhar todos os outros, enquanto eu com duas ou três boas horas por dia, fui sempre um dos programadores mais produtivos da equipa. Este deve ser o motivo pelo qual, quando a Peopleware e a XP insistem em eliminar as horas extraordinárias e trabalhar rigorosamente semanas de 40 horas, fazem-no com a certeza de que não irão diminuir a produtividade.

Mas não são os dias em que "apenas" consigo produzir duas horas de trabalho que me preocupam, mas sim aqueles em que não consigo fazer nada.

Tenho pensado muito sobre isto. Tentei lembrar-me da época mais produtiva da minha carreira. Foi provavelmente quando a Microsoft me mudou para um novo escritório, belo e luxuoso, com grandes janelas panorâmicas com vista para um jardim repleto de cerejeiras em flor. Tudo estava em sintonia. Durante meses trabalhei sem parar, rectificando as especificações detalhadas do Excel Basic - uma monumental resma de papel, cobrindo com um incrível grau de detalhe um gigantesco modelo de objecto e ambiente de programação. Praticamente nunca parei. Quando tive de ir a Boston para o MacWorld, levei comigo um portátil e documentei uma classe do Windows, comodamente sentado numa aprazível esplanada da Harvard Business School.

Uma vez na corrente, não é difícil continuar. Muitos dos meus dias são assim: (1) chego ao trabalho (2) verifico o meu correio electrónico, consulto a Web, etc. (3) decido que bem podia almoçar antes de começar a trabalhar (4) regresso do almoço (5) verifico o meu correio electrónico, consulto a Web, etc. (6) finalmente, decido que deveria começar a trabalhar (7) verifico o meu correio electrónico, consulto a Web, etc. (8) decido outra vez que realmente devo começar a trabalhar (9) executo o maldito editor e (10) escrevo código sem parar, enquanto não descubro que já são 19 e 30.

Algures entre os passos 8 e 9 parece existir uma falha, porque nem sempre consigo atravessar esse abismo.

Bike-trip.jpgPara mim, a única coisa difícil é simplesmente começar. A tendência natural de um objecto é ficar em repouso. Existe algo incrivelmente pesado no meu cérebro que é extremamente difícil de por em movimento, mas, uma vez a rolar, não requer nenhum tipo de esforço adicional para continuar. Tal como uma bicicleta equipada para uma viagem auto-suportada através do país - Quando se começa a pedalar com todo o equipamento em cima, é difícil acreditar quanto esforço é necessário para começar a rolar, mas uma vez em andamento, tem-se a impressão de ser tão fácil de pedalar, como uma bicicleta sem qualquer carga adicional.

Talvez seja esta a chave para produtividade: apenas começar. Talvez a programação em par funcione porque, uma vez planeada uma sessão de programação com um companheiro, cada um, mutuamente, obriga o outro a começar.

ARMY-wee.JPG
Quando era pára-quedista Israelita, um general visitou-nos para nos fazer um pequeno discurso sobre estratégia. Nas batalhas de infantaria, disse-nos, só existe uma estratégia: Fogo e Movimento. Moves-te em direcção ao inimigo enquanto disparas a tua arma. O fogo obriga-o a manter a cabeça baixa, pelo que não pode disparar-te de volta. (Isto é que os soldados querem dizer quando gritam "Cobre-me." Significa, "Dispara contra o nosso inimigo para que ele tenha de se agachar e não possa disparar contra mim enquanto atravesso esta rua." Funciona.) O movimento permite-te conquistar território e aproximares-te do teu inimigo, de onde os teus disparos são muito mais susceptíveis de atingir o alvo. Se não estiveres em movimento, o inimigo tem o poder de decisão sobre os acontecimentos, o que não é uma boa coisa. Se não estiveres a disparar, o inimigo irá disparar contra ti, obrigando-te a procurar abrigo.

Lembrei-me disto durante muito tempo. Reparei como quase todas as estratégias militares, desde escaramuças aéreas até manobras navais de grande envergadura, estão baseadas no conceito de Fogo e Movimento. Levei mais 15 anos para constatar que o princípio de Fogo e Movimento é como se conseguem as coisas na vida. Tens de avançar em frente, um pouco todos os dias. Não importa se o teu código é defeituoso e ninguém o quer. Se estiveres em movimento para a frente, escrevendo código e depurando-o constantemente, o tempo está do teu lado. Cuidado quando a competição dispara contra ti. Será que o fazem para te manter ocupado a reagir às suas saraivadas, para que não possas avançar?

Pensem na história das estratégias de Acesso a Base de Dados que saíram da Microsoft. OBDC, RDO, DAO,ADO,OLEDB e agora o ADO.NET - Tudo novo! São imperativos tecnológicos? Ou, são o resultado de algum grupo de desenhadores incompetentes que necessitam de reinventar a tecnologia todos os anos? (Na realidade, talvez seja isso.) Mas, o efeito final é o de cobrir com fogo. A competição não tem escolha possível senão a de gastar todo o seu tempo a tentar acompanhar o passo, tempo esse que não podem utilizar para escrever novas funcionalidades. Reparem atentamente no panorama da criação de software. As companhias de sucesso são aquelas que dependem menos das grandes empresas e que não necessitam de passar a totalidade dos seus ciclos de criação a tentar manter o passo, re-implementar e depurar erros, que só se manifestam no Windows XP. As empresas que tropeçam são aquelas que passam demasiado tempo a ler borras de chá para tentar descobrir o caminho que a Microsoft irá seguir no futuro. As pessoas estão preocupadas pela tecnologia .NET e decidem rescrever todas as suas arquitecturas para o .NET, porque pensam que têm de o fazer. A Microsoft abriu fogo contra ti, mas é apenas fogo de cobertura para que eles possam ir em frente e tu não possas, porque é assim que o jogo está a ser jogado, meu caro. Vais suportar Hailstorm? SOAP? RDF? Suportas estas tecnologias porque os teus clientes o necessitam, ou porque alguém está a disparar contra ti e sentes-te obrigado a ripostar? As equipas de vendas das grandes empresas compreendem o fogo de cobertura. Elas vão junto dos seus clientes e afirmam, "Muito bem, não têm de comprar os nossos produtos. Comprem ao melhor vendedor. Mas atestem que compram produtos que suportam (XML/SOAP/CDE/J2EE), porque de outra forma estareis presos dentro de uma redoma de cristal." Então, quando as pequenas empresas tentam vender os seus produtos a esse comprador, só ouvem o obediente director de tecnologia papaguear, "Dispõe de J2EE?" O resultado é terem de desperdiçar todo o seu tempo a construir compatibilidade J2EE mesmo se não resultar em vendas, nem qualquer tipo de oportunidade de se distinguirem em relação ao mercado. É uma funcionalidade do tipo lista de verificação - implementam-na porque precisam de mostrar que têm essa funcionalidade na lista de verificação, mas ninguém necessita dela ou a utiliza. Isto é fogo de cobertura.

Fogo e Movimento, para as pequenas empresas como a minha, significa duas coisas. Tens de ter o tempo do teu lado e tens de ir em frente todos os dias. Mais tarde ou mais cedo ganharás. Tudo o que eu consegui fazer ontem foi melhorar um pouquinho o esquema de cores do FogBUGZ. Tudo bem. Está a melhorar a olhos vistos. O que importa é que todos os dias o nosso software está cada vez melhor e temos cada vez mais clientes. Até que tenhamos o tamanho de uma empresa como a ORACLE, não temos que pensar em grandes estratégias. Temos apenas de chegar ao escritório todos os dias e de alguma forma, arrancar o editor.

Editing.gif

Discutir

Personal tools