rvf, software e mitos

Os cinco pecados do programador revolucionário

Posted on: 11 de dezembro de 2010

Eu já fui um. Entrar em uma empresa e querer mudar tudo é o maior desafio que uma pessoa quer, a mudança por si só é estimuladora. Acho que muitos já foram assim, mas, este post é para quem ainda está sendo ou pretende pretendia ser. Saiba como não ser o programador revolucionário, mas sim, o cara da nova geração da sua empresa.

É muito bom mudar, transformar, e isso deve ser feito com cuidado, mas nunca, jamais, da noite pro dia. É o erro que o pessoal (principalmente da geração Y) comete com freqüência. Resolvi aqui listar alguns destes erros que eu já fiz, presenciei e superei. Mas não vou deixar ninguém na mão, deixo na verdade a minha opinião sobre estes pecados e a forma que eu agiria em cada situação. Espero que sirva de aprendizado para o seu sucesso profissional.

#1 – Não faça críticas ao legado. É legado e todo legado tem problemas. Sua empresa não é exceção ao todo, todos têm legados e todos sofrem com este. Não julgue um legado pela linguagem que este fora implementado. Por pior que seja, se for, ainda é um ativo da empresa, afinal, é o que mantém o negócio no ar. Idéias revolucionárias para substituí-lo continuam a ser idéias, ainda não existem e não estão em produção. Não faça o novo criticando o presente/passado. Principalmente se alguém que faz parte do presente/passado esteja na sua equipe. E se você for de alguma consultoria, mais atenção ainda, pois ninguém quer ouvir que o seu sistema legado é uma droga. Eles querem soluções. Não cometa este erro para não ouvir um “faça melhor”. Na verdade, faça melhor e quando for virar à chave, o agradeça e as pessoas que nele trabalharam. Todos ficaram felizes.

#2 – Não tente implantar uma metodologia ágil da noite para o dia. As pessoas que trabalham na sua empresa podem estar acostumadas e confortáveis com a atual metodologia de trabalho, por mais burocrática e engessada que esta venha a ser, implantar uma metodologia nova em um ambiente de TI é necessário muito esforço, alinhamento com sua equipe, gerencia e seus clientes, para piorar, este alinhamento é incremental: primeiro planta-se uma sementinha sobre uma oportunidade e depois vá regando até brotar e crescer, mas atente-se  ao risco de morrer na primeira tempestade. Por exemplo, um dos programadores conhece o negócio, mas não sabe usar determinada API, enquanto outro sabe da API, mas não conhece o negócio… Coloque os dois lado a lado, mostre para eles que, se os dois pensarem juntos, se alternarem no comando do teclado e do código, algo bom pode fluir. Diga ao final que isso se chama programação em par, uma técnica da metodologia ágil Extreme Programming, certamente eles vão querer saber mais sobre este tal de XP. Veja oportunidades nas dificuldades, é a melhor forma de se conseguir algo, resolvendo um problema real. Fazer sua equipe comer agile com farinha falhará.

#3 – Tenha opiniões formadas, do contrário, não opine! Você pode ser questionado e não saber se defender, conseqüentemente sua moral irá despencar. Se quer tratar um assunto com alguém, saiba do que está falando. Quer falar de Test-Driven Development com alguém? Domine isso antes. Tenha tido experiência com isso antes. Tenha escrito testes antes (duplo sentido). Ser xiita, defender algo que conhece apenas teoricamente ou porque leu em algum artigo por aí é um erro fatal. Fuja disso.

#4 – Não seja resistente com o fornecedor picareta. Eu e você (e até eles) sabemos que, o que eles mais querem é vender (menos o seu gerente, que costuma acreditar em conto de fadas)! Quanto ao negócio propriamente dito, eles tratarão disso vendendo consultoria depois. Mas o primeiro passo continua a ser vender o software “faz tudo” de um milhão de dólares. Isso não significa que você vai falar para seu gerente não comprar. É uma variante do pecado #3, afinal, você vai saber argumentar o motivo de não comprar? Ou vai dizer apenas que a empresa é picareta, pois um amigo do seu irmão lhe disse? – Monte uma apresentação, faça gráficos (gerentes adoram gráficos), mostre as alternativas, soluções open-source e a economia que ele terá escolhendo X ao invés de Y. É assim que se toca, camarada. Fuja da resistência, apresente alternativas e os benefícios relacionados.

#5 – Não force ninguém a usar o que você usava na sua empresa anterior. A empresa atual usa cruisecontrol? Aprenda cruisecontrol antes de falar do Hudson. Sua empresa usa JDeveloper? Aprenda JDeveloper antes de falar do Eclipse. Sua empresa usa bugzilla? Use o bugzilla antes de falar do Jira. E por ai vai… Critique apenas o que você conhece e sabe que existe algo melhor, para então sugerir. Você corre o sério risco de ser ignorado e/ou ser visto como uma pessoa resistente, por mais certo (ou não) que esteja.

Se você achou os cinco pecados coerentes entre si, você captou a mensagem! E você, poderia contribuir com esta lista?

Robson

http://twitter.com/irobson

7 Respostas to "Os cinco pecados do programador revolucionário"

Em fim saiba o que está falando.
Ótimo artigo. Já bati muito a cabeça com essas coisas. Agora seguirei todos os pontos.


[]ão
Raphael Almeida
http://raphaeldealmeida.wordpress.com
http://www.twitter.com/raph_almeida
http://rubyonrio.org

Muito legal seu post, em especial o #1.
Trabalho numa empresa que possui um legado que iniciou lá nos anos 90… Fui responsável pela modernização do mesmo e o que aprendi é que realmente não se pode julgar linguagem, metodologia etc.. em que foi desenvolvido.
Não é possível saber sob que pressão a equipe estava naquele momento com relação a prazos e resultados (geralmente isso não fica registrado em lugar algum) e também deve-se sempre partir do princípio que existe uma razão para que tenha sido feito daquela maneira, então considere que era “a melhor solução para aquele momento”.
Como diria o amigo Aparecido Carmo Martins, “A solução do passado é o problema do presente!”

Aproveitando, posso incluir um link para o seu post no meu blog e reproduzir o texto, com os devidos créditos?
Obrigado!

Muito interessante o texto. Fruto da experiência. Por falar em experiência e conhecimento técnico, meu amigo Jamir Déa Jr é o exemplo típico. Porém, me resta observar que a frase acima não é minha, ela representa uma das Leis do Pensamento Sistêmico: A lei que diz que não existem soluções definitivas, que o problema de hoje é conseqüência de uma solução adotada no passado. Em outras palavras, a solução de hoje poderá ser nosso problema de amanhã. Obrigado.

Pra variar, mais um ótimo texto, Mr Robson! De acordo com tudo o que você falou.

Abraço!

Muito bom, muita experiência. Gostei cara parabens!

Muito bom este post.
Acho que tudo isso pode ser resumido em uma única palavra: humildade (isso não significa não defender seu ponto de vista).

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s


  • Adolfo: Muito bom este post. Acho que tudo isso pode ser resumido em uma única palavra: humildade (isso não significa não defender seu ponto de vista).
  • Adolfo: Olá Robson, Alguns modelos até consegui identificar em alguns projetos que já trabalhei... Com algumas coisas eu concordo e outras não... Q
  • milah: Eu tenho um Amazon L71. Até 2 meses atrás não tive problemas com ele. Já troquei a placa de lan dele, por uma que capta melhor wi-fi. Só que ago
%d blogueiros gostam disto: