O meu trabalho é muito bom eu tenho que confessar… ~ Pedra Letícia

Eu realmente acho que a profissão de desenvolvedor, na média, é privilegiada. Particularmente, já tive empregos em que tinha bem menos flexibilidade e que usava bem mais força física. Trabalhar em supermercado é bem tenso.

Na área de desenvolvimento, sobretudo em empresas grandes, você tem boas chances de encontrar um ambiente de trabalho em que vai ter uma pressão condizente, não vai ter chefe fungando no seu percoço, te monitorando como se fosse o grande irmão da história de George Orwell.

Ter trabalhado com outras coisas antes molda minha perspectiva sobre a área de desenvolvimento. Geralmente tendo a pensar que as pessoas são muito reclamonas pois têm um bom ambiente, só não conseguem ver isso - mas isso é assunto pra outro post.

Há, além dos reclamões, os aproveitadores. Estes, se valem de um ambiente flexível, e de confiança, e exploram vulnerabilidades que esse sistema oferece.

Ao longo da jornada eu tenho observado esses hackers da vida real fazendo tais exploits. Claro, isso só é possível em organizações complexas. Em startups mais enxutas é bem difícil encontrar o desenvolvedor senil.

A metodologia do desenvolvedor senil

Esse artigo é um guia de como ser o desenvolvedor senil - aquele que faz-se passar por um desenvolvedor senior.

NOTA: Para seguir o guia com eficiência é preciso ser desapegado de querer fazer um bom trabalho. Além disso, tem que ter pelo menos um outro dev que seja o total oposto, com o tal do brio para fazer as coisas, e mais, de forma decente.

O guia, até então, possui cinco pasos simples. Eles são:

Programação por coincidencia

Programação é para profissionais e entusiastas. Um dos conceitos do Programador Pragmático é a programacao por coincidencia. Resumindo bem diz respeito a fazer as coisas funcionarem sem necessariamente entender o que está acontecendo. Você vai tentando coisas, até que funciona.

Isso é fácil de fazer, basta copiar partes de código existentes que você precisa. Esse vai ser o default da maioria das pessoas que chega numa base de código pela primeira vez. O segredo aqui é continuar fazendo isso. Nunca improvisar. Mesmo que você conheça a base de código, haja como se nunca tivesse visto.

Não tenha a preocupação de isso ser pego por algum revisor mais atento. Temos um método para lidar com isso e será visto na próxima seção.

Code Review e Pair Programming

Pair programming e code review são ambas práticas extremamente difundidas na área de engenharia de software. Code reviews são boas para evitar algum desastre ou má prática. O código, antes de chegar na branch principal, passa pela review de outros membros do time.

Em nossa metodologia, code reviews vão ser úteis para corrigir o código feito. Afinal, você fez usando programação por coincidência, então não entende o porquê das coisas.

Acontece que durante a revisão você vai receber sugestões, as vezes até o código feito para por no lugar. E você levar isso até onde der com o revisor te direcionando em como fazer testes se o projeto tiver.

O que acontece quando a paciência do revisor acaba? Pair programming.

Pair programming é essa técnica em que dois devs se juntam pra resolver uma problema. Um de piloto e outro de observador. Você é aquele que vai escrever código, o piloto, mas com o observador (antes revisor) te dizendo exatamente o que fazer. Assim, você entrega a task e colhe os louros.

Uma outra forma de usar pair programming é carregar a task até o limite, até aquele limite em que se passar o time em si vai ser prejudicado. A partir daí, clame por pair programming e siga o mesmo modo, sempre de piloto.

Procure a complexidade

Seus gerentes não vão saber tudo do trabalho que você tem que fazer para concluir uma task. Se ele for uma pessoa bacana então, ele não vai te pressionar, pode manter a tranquilidade.

Então, ao receber uma task, faça algo mais complexo do que a task pede. Idealmente, procure algo que seja mais complexo para não-devs entenderem. Assim, durante reuniões diárias você vai poder explicar de modo que dê um senso de que sua tarefa original é difícil.

Isso vai te dar mais tempo para fazer sua task original e na entrega a glória vai ser maior.

Tenha o máximo de tickets ‘em progresso’

Se você está trabalhando, vai ter algo em progresso. O segredo aqui é ter o máximo possível. Que nem um cego tateando até encontrar uma parede você vai mantendo tasks até encontrar o número limite. Se ficar visível que está forçando, reduza; mantenha a média.

Ao término da sprint você não vai ser necessariamente cobrado por todos esse tickets, afinal, você tinha muita coisa pra lidar e a troca de contexto te complicou - não importa se você deliberadamente fez isso.

Use suas próprias palavras

Alguém disse algo que a maioria do time achou inteligente ou útil? Não perca tempo, certifique-se de falar a mesma coisa, porém com suas palavras.

Aqui é a única parte da metodologia em que o improviso é bem-vindo. Mude a ordem, adicione sinônimos e outras figuras de linguagem, enfim, faça sua mágica.

O meu trabalho é muito bom eu tenho que confessar

Esse trabalho é muito bom, e em empresas grandes você consegue facilmente ficar sem fazer nada, ganhar um bom salário e até um bom cargo que vai ter dar insumos para, eventualmente, pleitear uma vaga em outro lugar que vai te valorizar mais - com um cargo melhor, um salário melhor, etc.

Sempre vai ter uma pessoa ou um grupo de pessoas no seu time que devido a um certo ímpeto vai querer ver as coisas funcionando e quando tudo estiver quase indo por água abaixo, esse grupo de pessoas vai vir em socorro do time/projeto.

É esse grupo de pessoas que vai estar presente em reuniões e que vai até ditar algumas coisas do projeto, mas o Desenvolvedor Senil não se importa com isso.

O objetivo a ser concluído é: não trabalhar e colher os louros no final da sprint.

Que nem na música da banda Pedra Letícia:

O meu trabalho é muito bom eu tenho que confessar
Segunda-feira eu não vou, to de ressaca
Na Terça-feira é o rodízio da minha placa
Na Quarta-Feira pego atestado
Na Quinta-Feira eu já emendo um feriado
Na Sexta-Feira, tenho dentista
Sábado eu não vou porque eu sou adventista

Essa é a essência do desenvolvedor Senil.

Conclusão

Isso é, naturalmente, um guia de o que não fazer para ser um profissional decente. Se por ventura você, leitor, identificou com algum dos pontos do guia de como ser um Desenvolvedor de Software Senil, mas não tem interesse em ser um, deveria rever essa prática. Como um guia anti-senil deixo de recomendação os seguintes livros:

  • O Programador Pragmático;
  • O Mítico Homem-Mes.

Boa leitura.