Eu recebi a seguinte mensagem:

“Como alguém continua a construir uma carreira em desenvolvimento de software quando
existem pessoas jovens e famintas (p.e. pessoas que podem e irão trabalhar 16
horas por dia e podem aprender coisas em um ritmo ridicularmente rápido)
adentrando o campo?

Estou na madura idade de 33 anos, e já estou sentindo o desafio de acompanhar as pessoas
de 23, 24 e 25 anos… :/

Além disso – e eu sei que isso é em parte uma função do crescimentoexplosivo do campoao longo dos anos – eu não vejo muitos
desenvolvedores de software dos 40 para cima, então eu não tenho precedentes
para observar, em termos de construção de carreira, um caminho diferente do que
o direcionado para gestão.”

Como eu já decidi dedicar esta década à programação, e parte dela à contratação, este tópico é
interessante para mim (tenho 50 anos). Eu não sei se tenho coisas muito úteis a
dizer. No entanto…

• Em um time, algumas pessoas
  servem como catalisadoras para as habilidades de outras pessoas. Por exemplo,
  desde os meus 20 anos, eu tenho estado preso no friction-free work (inglês). Então, era mais provável
  que eu, em vez de outros, fizesse um trabalho de construção melhor,
  escrevesse e compartilhasse funções emacs
  para automatizar tarefas semi-frequentes, ou trabalhasse em testes. Essas
  tarefas não são gloriosas – “Eu não sou um construtor-reparador rock
  star!” –, mas elas ajudam o time. Como o excêntrico do time, eu poderia
  destacar que eu ia além, libertando as outras pessoas para se concentrarem
  nas façanhas mais prodigiosas da codificação.

  Uma maneira típica como um velho programador pode
  catalisar a situação é prestar atenção nas relações humanas. Se você puder evitar
  a tendência condenável
  que pessoas mais velhas têm para pontificar pessoas ou de contar histórias
  apenas marginalmente relevantes sobre
  como elas fizeram isso há 20 anos, você pode ser
  uma pessoa que leva a equipe a uma melhor configuração. O papel
  ideal é aquele do player coach
  (“técnico-jogador”) (mas ele deve ser reconhecido pelo time, em vez de ser
  apontado como tal).

• Outro motivo para o
  patriarca trabalhar em um time bem fechado é que as vantagens dos
  programadores jovens não são uniformes. Por exemplo, o que mais me faz
  sentir como um velho com tremedeira é a quantidade de coisas que esses
  meninos de hoje conhecem: ferramenta em cima de ferramenta, em cima de
  ferramenta, em cima de ferramenta, gem em cima de gem, em cima de
  gem, em cima de gem, os 83 lançamentos do Rails etc. Mas se você tem uma
  dessas pessoas no seu time, a vantagem se entende a todos, e a perda de
  uma mente centenária não é uma desvantagem muito grande.

  Quando o que interessa é a capacidade do time,
  equilíbrio é mais importante do que a excelência uniforme individual. Portanto,
  quando uma pessoa mais velha e conservadora faz parte do time, foque em ser
  complementar em vez invés de único.

• Uma maneira tradicional de
  programadores mais velhos cooperarem é ser um dos poucos experts em uma
  tecnologia que já passou (Cobol é um exemplo, Smalltalk também). Essa
  tecnologia não tem que ser, necessariamente, chata. Às vezes, como já
  aconteceu com Smalltalk, Lips, e talvez com linguagens funcionais mais
  puras, o que passou se torna interessante de novo.

  Um caminho semelhante é se tornar um expert em uma
  tecnologia bastante especializada e difícil, como por exemplo máquinas
  virtuais ou segurança-alguma-coisa, que é difícil de aprender rapidamente e
  requer aprendizado constante. 

• Agora que aprendemos que o
  legado do código não tem que ser horrível, talvez o vovô devesse procurar
  se unir a uma base de código extensa e de vida longa. Você pode encontrar
  grande satisfação em assistir seu jardim florescer ano após ano.

• Também é útil não agir como um velho. Por exemplo,
  eu tenho que brigar contra minha vontade de ser presunçoso por não saber
  CSS. Claro que, no meu caso, eu não sei, porque… bem.. CSS. Mas é facilmente interpretado
  como se eu estivesse dizendo “Oh, outra novidade da moda, *bocejo*, me dê
  um RPG qualquer dia desses”. Da
  mesma maneira, eu devo ter cuidado ao dizer coisas como Clojure aos
  programadores, como, “Bem, nos meus dias de Lisp nos fazíamos assim…”.
  Como um exemplo final: vendo este site, sinto que não aprendi nada sobre
  tecnologias web desde 1994.

  As pessoas são sensíveis a pessoas velhas agindo de
  maneira velha. O x da questão é que é fácil subverter expectativas. Acho que é
  uma boa estratégia ser capaz de falar com modéstia profunda sobre duas ou três
  tecnologias que são de certa forma novas ou da moda. Portanto, por exemplo,
  estou feliz que posso falar sobre Clojure, Cappuccino e Sinatra. Você quer apresentar a aparência de ser capaz – e
  realmente ser capaz – de sintetizar o
  passado e o presente.

• Finalmente: se a programação
  realmente é um daqueles campos em  você faz seu melhor trabalho enquanto
  novo, pessoas mais velhas devem ter um salário menor. Velhos programadores
  podem competir (com credibilidade) ao pedir por menos dinheiro.

  Porém, essa “credibilidade” é um problema, uma vez
  que programação é um campo de machos prepotentes. Dessa maneira, um salário
  menor é facilmente interpretado como uma grande bandeira vermelha, em vez de
  um reconhecimento realístico de que, digamos, memória de curto prazo e
  concentração são importantes para programação, e que ambos pioram com a idade.

Outros pensamentos que podem ajudar meus colegas
velhinhos?

?

Texto original disponível em http://www.exampler.com/blog/2010/05/10/old-programmers/