Fogo E Movimento

From The Joel on Software Translation Project

Revision as of 18:26, 23 May 2009 by Setatakahashi (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Por Joel Spolsky da Fog Creek Software
Domingo, 06 de Janeiro de 2002
Artigo original: Fire And Motion
Traduzido por: Willian Cruz

Artigo

Há momentos em que eu simplesmente não consigo fazer nada.

Eu chego no trabalho, fico circulando pelo escritório, checo meu e-mail a cada dez segundos, leio alguma coisa na Internet, chego até a fazer algumas tarefas que não requerem esforço mental como pagar a conta do cartão de crédito. Mas entrar de novo no ritmo de escrever código simplesmente não acontece.

Bored-tetris.gif

Esses ataques de falta de produtividade geralmente duram um dia ou dois. Mas tem havido momentos em minha carreira como programador em que eu passei semanas sem ser capaz de terminar alguma coisa. Como costumam dizer, eu não estou no ritmo. Eu não estou em concentração total. Eu não estou em lugar nenhum.

Todo mundo tem variações de humor; para algumas pessoas elas são suaves, para outras elas podem ser mais fortes ou mesmo incapacitadoras. E os períodos improdutivos parecem estar de algum modo relacionados com humor depressivo.

Isso me faz pensar naqueles pesquisadores que dizem que as pessoas basicamente não conseguem controlar o que comem, por isso qualquer tentativa de dieta está fadada a ter curta duração e essas pessoas sempre continuarão retornando ao seu peso anterior em um efeito ioiô. Talvez como um programador de software eu realmente não consiga controlar quando estou produtivo, tendo apenas que suportar a sucessão de períodos de baixa produtividade e períodos de alta produtividade e esperar que na média eles resultem em um número de linhas de código suficiente para manter minha empregabilidade.

Bored-onion.gif

O que me deixa louco é que desde meu primeiro emprego como programador eu percebi que costumo ter uma média de duas ou três horas por dia de programação produtiva. Quando eu fiz um estágio na Microsoft, um colega estagiário me contou que ele estava trabalhando só das 12 às 17 todos os dias. Cinco horas, menos almoço, e a equipe dele o adorava porque ele conseguia produzir muito mais do que a média. Eu descobri que isso também acontece comigo. Eu me sinto um pouco culpado quando vejo o quanto os outros parecem estar trabalhando duro, enquanto eu consigo produzir duas ou três horas de trabalho com qualidade no dia, e mesmo assim sempre fui um dos membros mais produtivos da equipe. Provavelmente é por isso que as pessoas de Peopleware e XP insistem em eliminar horas extras e trabalhar estritamente 40 horas semanais. Eles fazem isso com segurança, cientes de que isso não vai reduzir a produção da equipe.

Mas não são só os dias em que eu faço "apenas" duas horas de trabalho que me preocupam. São os dias em que eu não consigo fazer nada.

Eu tenho pensado bastante sobre isso. Eu tentei me lembrar qual foi a época mais produtiva da minha carreira. Provavelmente foi quando a Microsoft me colocou em um escritório novinho, bonito e luxuoso, com janelas amplas e uma vista panorâmica de um lindo jardim cheio de cerejeiras em flor. Tudo estava indo bem. Por meses eu trabalhei sem parar, produzindo com esforço a especificação detalhada do Excel Basic -- um pacote monumental de papel que entrava em um nível de detalhe incrível, cobrindo um modelo de objeto e ambiente de programação gigante. Eu literalmente nunca parei. Quando eu tive que ir para Boston para a MacWorld, eu levei um laptop comigo, e documentei a classe Window sentado em um confortável terraço da Harvard.

Uma vez que você entra no ritmo, não é muito difícil continuar nele. Muitos de meus dias são assim: (1) chego no trabalho (2) checo o e-mail, navego na Internet, etc. (3) decido que eu posso ir almoçar antes de começar a trabalhar (4) volto do almoço (5) checo o e-mail, navego na Internet, etc. (6) finalmente decido que eu tenho que começar (7) checo o e-mail, navego na Internet, etc. (8) decido de novo que eu tenho mesmo que começar (9) carrego o maldito editor e (10) escrevo código sem parar até perceber que já são 19:30.

Em algum lugar entre o passo 8 e o passo 9 parece haver algum bug, porque não é sempre que eu consigo transpor esse abismo.

Bike-trip.jpg

Para mim, começar é que é a única coisa difícil. Um objeto em repouso tende a permanecer em repouso. Há alguma coisa incrivelmente pesada no meu cérebro que é extremamente difícil de ser colocada em movimento, mas uma vez que está em velocidade máxima, não exige esforço algum para manter-se em movimento. É como uma bicicleta equipada para uma viagem independente em que se vai cruzar o país -- quando você começa a pedalar com todo aquele equipamento, é difícil acreditar no esforço necessário para colocá-la em movimento, mas uma vez que você está andando parece tão fácil quanto andar em uma bicicleta sem equipamento algum.

Talvez essa seja a chave para a produtividade: apenas começar. Talvez quando a programação em duplas funciona, ela funcione porque quando você combina uma sessão de programação em dupla com o seu colega vocês forçam um ao outro a começar.

ARMY-wee.JPG

Quando eu era um paraquedista Israelense, um general nos fez uma visita para dar um pequeno discurso sobre estratégia. Em batalhas de infantaria, ele nos disse, há apenas uma estratégia: Fogo e Movimento. Você se move em direção ao inimigo enquanto atira. O fogo faz o inimigo manter a cabeça abaixada, de modo que ele não pode atirar em você. (é isso que os soldados querem dizer quando gritam "me cubra". Isso quer dizer "atire no inimigo para que ele tenha que abaixar a cabeça e não possa atirar em mim enquanto eu atravesso correndo essa rua aqui". Funciona.) O movimento permite que você conquiste território e se aproxime mais do seu inimigo, onde seus tiros têm uma probabilidade muito maior de acertar o alvo. Se você não está se movendo o inimigo consegue decidir o que acontece, o que não é uma boa coisa. Se você não está atirando, o inimigo vai atirar em você e te derrubar.

Eu me lembrei desse discurso por um longo tempo. Eu percebi como quase todo tipo de estratégia militar, de batalhas aéreas até manobras navais de larga escala, são baseadas na idéia de Fogo e Movimento. Eu levei outros quinze anos para perceber que o princípio de Fogo e Movimento é como você consegue fazer as coisas na sua vida. Você precisa avançar um pouquinho todo dia. Não importa se seu código é amador, cheio de bugs e ninguém quer. Se você está avançando, escrevendo código e consertando bugs constantemente, o tempo está ao seu lado. Preste atenção quando a concorrência atira em você. Será que eles só querem forçar você a continuar ocupado reagindo aos tiros para que você não consiga avançar?

Pense na história das estratégias de acesso a dados que vêm da Microsoft. ODBC, RDO, DAO, ADO, OLEDB e agora ADO.NET – Todas novas! Essas tecnologias são necessárias? Seriam elas o resultado de um grupo de design incompetente que precisa reinventar o acesso a dados todo bendito ano? (Na verdade, provavelmente é isso.) Mas o resultado final é apenas cobrir fogo. A concorrência não tem escolha além de gastar todo seu tempo portando e mantendo, tempo que não conseguem gastar desenvolvendo novas funcionalidades para os produtos. Olhe com atenção para o cenário de desenvolvimento de software. As empresas que vão bem são as que dependem menos das grandes companhias e não precisam gastar todos os seus ciclos atualizando, re-implementando e consertando bugs que só acontecem no Windows XP. As companhias que tropeçam são as que gastam muito tempo lendo folhas de chá tentando descobrir a direção que a Microsoft vai seguir. As pessoas se preocupam com .NET e decidem rescrever toda sua arquitetura para .NET porque pensam que precisam fazer isso. A Microsoft está atirando em você, e é só fogo de cobertura para que eles possam avançar e você não, porque essa é a regra do jogo, companheiro. Você vai oferecer suporte para Hailstorm? SOAP? RDF? Você vai oferecer esse suporte porque seus clientes precisam ou porque alguém está atirando em você e você acha que tem que responder? Os times de vendas de grandes companhias entendem fogo de cobertura. Eles vão até seus clientes e dizem, "Tudo bem, você não precisa comprar da gente. Compre do melhor fornecedor. Mas tenha certeza de que o produto tem suporte a (XML / SOAP / CDE / J2EE) porque senão você vai ficar amarrado a eles." Então quando as pequenas empresas tentam vender para aquela conta, tudo que eles ouvem são CTOs e diretores obedientes repetindo como papagaios "Você tem J2EE?" E eles tem que gastar um monte de tempo desenvolvendo em J2EE mesmo que isso não resulte em nenhuma venda e não lhes traga nenhuma vantagem competitiva no mercado. É uma funcionalidade do tipo "checkbox" -- você a faz porque precisa do tick no checkbox dizendo que você a tem, mas ninguém vai usar ou precisa dela. Isso é fogo de cobertura.

Fogo e Movimento, para empresas pequenas como a minha, significa duas coisas: você tem que ter o tempo ao seu lado e você tem que avançar a cada dia. Mais cedo ou mais tarde você vai vencer. Tudo que eu consegui fazer ontem foi melhorar um pouquinho o esquema de cores no FogBUGZ. Tudo bem. Está ficando melhor a cada dia que passa. A cada dia nosso software está melhor e melhor e nós temos mais e mais clientes, isso é tudo que importa. Até que sejamos uma empresa do tamanho da Oracle, nós não precisaremos pensar em grandes estratégias. Nós só precisamos vir para cá toda manhã e de alguma forma abrir o editor e começar.

Editing.gif

Personal tools