A Síndrome do Programador Herói

Algumas frases que publiquei semana passada no twitter fizeram algum sucesso. A  idéia veio de vários lugares: juntei com o que ouvi de alguém, com aquele velho e-mail sobre a carreira Y, entre outros episódios da nossa área; mas o problema é real e se chama: Síndrome do Programador Herói (SPH). Provavelmente todos da área de TI com alguns anos de carreira já viram alguém ser acometido pela SPH, alguns são afetados pelo resto da vida, enquantos outros conseguem se libertar ou serem libertos por alguém que lhes dê um chacoalhão. Acontece é que o desenvolvimento de software é um dos segmentos de trabalho mais propícios para adquirir essa síndrome.

A maneira mais fácil de contrair SPH é o programador participar de vários projetos de sucesso, principalmente se ele buscar os desafios, e todos darem extremamente certo! OK, sabemos que todo projeto tem seus problemas, mas muitas vezes os executivos não enxergam esses “problemas”. Para eles é apenas um programador que não consegue chegar no horário, um outro que não tem certificação; mas sempre tem aquele cara que gosta de matar no peito, por mais que isso vá arder no dia seguinte, ele quer comprar latinhas de energético e virar a noite na empresa, lógico que depois de pedir aquela pizza, e codar, codar, codar. O trabalho é gerar linhas de código, centenas delas, talvez milhares; ele vai ser o cara que vai carregar o projeto, o cara que vai dar o sangue… E por aí vai. Esse cara é cumprimentado pelo gerente, vai almoçar com ele, alguns colegas querem ser como ele, “o cara que coda pra baralho”, “o cara ali é o único que sabe como funciona essa regra de negócio”, “ele que sabe como esse framework funciona”.

Apesar da gerência adorar e,  talvez a sua existência seja devido ao modelo capitalista, ainda mais em contratações acordadas por valor/hora, esse tipo de profissional deve ser evitado! A qualquer custo. Parece loucura não apoiar um profissional que dê o sangue pela empresa, mas não é, essa é a atitude mais saudável que alguém poderia tomar em um projeto. O projeto deve ser feito pelo time, o mérito da execução deve ser do time, os bugs são criados pelo time; é muito fácil verificar se isso ocorre, é quando se ouve “nós falhamos na implementação de determinada tarefa”, “nós conseguimos fazer um refactoring e melhorar o código para a implementação de determinada funcionalidade acontecer”, “nós automatizamos os testes de integração”, “nós não vamos conseguir completar as tarefas a tempo para lançar essa release na data pré-determinada”.

Quando o time funciona de maneira homogênea o conhecimento técnico ou de negócio é passado para todos, todos irão saber como agir quando algo der problema, todos vão assumir os problemas, todos vão cooperar.

As frases:

  • “programador ninja = programador mercenário, q usa práticas não ortodoxas, sabotagem, espionagem… veja def.: http://ht.ly/5ejDE”
  • “programador jedi = trabalha com ficção, projetos q de uma galáxia muito distante da nossa, único empregador: LucasArts.Com”
  • “programador highlander = vai detonar todos os seus colegas, única maneira de sobreviver no projeto… afinal: só pode haver um!!”
  • “programador Daileon = resolve o seu problema mas devasta todo o ambiente…”
  • “programador AstroBoy = é bonitinho… mas vc não quer um brinquedo de crianças cuidando do sistema crítico da sua emrpesa…”

O pessoal também criou algumas:

  • @wjat777 Ninja: vem armado até os dentes (varias ferramentas), pode até resolver o problema, mas (cont.)
  • @wjat777 mas tem a capacidade de desaparecer se a situaçao pioara.. normalmente cobra caro!
  • @alistonCarlos Programador Power Ranger: junta com mais quatro pra fazer uma bazuca que mata até formiga!
  • @marcelotozzi e o rockstar?
    • Aí vai Marcelo: “tem twitter e fica falando sobre um monte de coisas e escreve um blog sobre assuntos diversos, até mesmo sobre programação, falando como deve ser a coisa”  … #bazinga, ok? 😉

5 Replies to “A Síndrome do Programador Herói”

  1. Pra mim esse treco de “queremos/sou um ninja/jedi/Mestre pokemon” é uma questão de marketing da galera que é conhecida, nem é questão do “programador Jesus” ai que vc disse no post.
    Já trabalhei em um esquema assim numa empresa que tinha seu próprio framework, todo mundo dizia que alguns caras lá eram os #souFoda e tal, e como eu era mais juvenil ainda do que sou agora eu ficava quieto né, pq eles sabia do framework lá, OK.
    Depois que sai da empresa e estudei fora daquele ambiente, vi que aqueles caras sabiam aquilo, e só aquilo, e isso é triste na minha opinião. Eram jedis do seu planeta árido de traficantes e escravos e ficavam ali, em vez de pegar uma Millennium Falcon e se juntar a Aliança.
    Mas eu sou um mero programador Java Jr sem trampo, ou “xaveiro” como diz o Quaiato, então minha opinião de merda não conta muito, rsrs :P.

    Abras

  2. Não concordo com o fato desse tipo de profissional ser evitado. Mas concordo com o fato do conhecimento ter que ser homogeneo em um equipe.

    É muito mais produtivo quando o profissional fodão puxa os outros para cima e não se torna uma estrela solitária que faz tudo sozinho

    1. Não é bem ser evitado, o problema é que esse profissional as vezes pode parecer muito bom e ofuscar o time como um todo, que se sente desvalorizado. Ser inteligente, ótimo profissional, entregar-se ao projeto, é tudo muito bom. Mas que tal o profissional aparecer menos e deixar outros também brilharem? Ser um coach para o time, compartilhando conhecimento? Colaborando?

  3. Acho que neste ponto você falou tudo : Quando o time funciona de maneira homogênea o conhecimento técnico ou de negócio é passado para todos, todos irão saber como agir quando algo der problema, todos vão assumir os problemas, todos vão cooperar. Em um time, nunca todos vão esta no mesmo nível, assim como no jogo de futebol, tem as posições em uma equipe também tem, neste caso sempre vai ter alguém que vai fazer mais.

  4. Gostei muito do seu post. Vou entrar na discussão:

    (Baseado em fatos reais. Caso vc já tenha passado por algo parecido abaixo, não será mera coincidência.)

    Trabalho numa empresa em que a TI acordou para a sua sugestão: Não criemos o “programador herói”.

    Para evitar este sujeito, estabeleceram processos e mais processos para o desenvolvimento de software. Desmenbraram o trabalho em várias áreas. Tiraram a autonomia do indíviduo e ele passa a depender de outras áreas para tudo: criar tabelas no SGBD, colocar o sistema no ambiente de homologação e produção, etc…

    As áreas comunicam-se sempre formalmente através de formulários e o processo foi até auditado e certificado nestes órgãos que o mercado adora (ISO, CMMI, etc.).

    O comportamento das pessoas foram mudando graças às ínumeras campanhas “foco no processo”, “preparem-se para a auditoria” e coisas do tipo. Cada um agora procura fazer a sua parte e todos somos obrigados a trabalhar em equipe. A consequência disso? Projetos demoram muito para ficarem prontos. Toneladas de documentação são geradas e, por conta da quantidade, ninguém é capaz de lê-las, muito menos mantê-las atualizadas. Os bons preferem ir direto no código-fonte. Os ruins não fazem nada e reclamam: “é necessário atualizar a documentação primeiro…”, “não bate com o código-fonte” e assim caminha a humanidade.

    Depois de 5 anos trabalhando aqui percebo que não temos mais HERÓIS. O problema disso é que ninguém mais SALVA os projetos.

    (Eu entendi que o seu ponto ao sugerir evitar este “espécime” é outro: voltado para a valorização do resto da equipe. O meu comentário apenas ilustra que fazer a caça aos “programadores heróis” nem sempre faz com que os outros brilhem.)

Leave a Reply

Your email address will not be published. Required fields are marked *