Vira e mexe essa discussão volta a tona no Twitter, sobre o que é ser sênior , junior etc...
Primeiro de tudo ser sênior não significa nem habilidade nem capacidade, muito menos domínio de alguma linguagem ou tecnologia. Ser sênior significa ter experiência em matéria de tempo mesmo. Km rodados.
Então não significa necessariamente que o dev Sr. é um guru da tecnologia, muito pelo contrário: algumas das maiores cagadas que tenho limpado são de devs com 10+ anos de XP. Não falo de acidentes como um update sem where, mas coisas como por exemplo dois métodos exatamente iguais mas com parâmetros invertidos. Catch mudinho. Grafo de um giga sendo enviado pro browser em JSON. Webservices abertos sem senha nem segurança nenhuma.
Sei lá, é tanta cagada que a gente limpa todo dia. 80% é dev Sr que faz.
O negócio de Junior/Pleno/Sênior varia de acordo com a empresa.
As vezes o cara que é considerado sênior em uma empresa é considerado Junior em outra. Ou é considerado sênior em uma tecnologia e Junior em outra.
As vezes um cara novinho de carreira manja muito de uma única tecnologia, esmerilha, e quer sair da empresa porque encontrou outra vaga com o salário maior, mas seu superior dá um aumento pra ele ficar, a famosa contraproposta. O cara tem pouco tempo de carreira mas a empresa acaba passando ele pra pleno ou sênior para justificar / equiparar o salário.
(Sim! na nossa área só existe crescimento horizontal, o crescimento vertical ou a lenda da carreira em Y eu nunca vi). Uma série de (in)felizes coincidências pode levar o cara a se tornar Sr. em MENOS de dois anos. As vezes o cara tem potencial, mas tem que lapidar.
As vezes o dev pleno é purista demais, e aprende a ser tolerante quando vira sênior. Quando ele conhece aquela gambiarra que funciona, quando o sistema é descartável e é mais importante funcionar capenga agora do que funcionar cheiroso só semana que vem.
As vezes ele olha no histórico do git pra ver quem foi o FDP que fez aquela cagada que ele está arrumando e encontra Vitor Luiz Rubio no commit, porra, se olhar da perspectiva do coleguinha sempre é uma experiência transcendentalmente humildificante. Você chega a conclusão de que "nossa, eu realmente não sou lá grandes merda".
As vezes você mora em uma cidade em que os salários médios são mais altos, e o custo de vida muito mais alto. O pleno na capital de São Paulo com certeza ganha mais que o sênior no interior. Senioridade não significa diretamente salário, e salário não quer dizer capacidade.
Ser senior envolve ter aquele "pulo do gato" pra identificar um problema de negócio ou de requisito antes mesmo que o pleno comece a codificar. Significa entender o que aquele GP babaca realmente quer, ou o que aquele usuário que não sabe direito o nome das coisas quer dizer (Godzilla Giroflex?!).
Mas você tem que tomar cuidado para não ser o legado instantâneo da sua empresa.
Legado instantâneo é aquele cara que faz o máximo esforço possível para fazer o mínimo esforço possível. É o cara que faz uma gambiarra sabendo que vai explodir na mão de alguém lá na frente. É o cara que sabendo fazer o certo e tendo a mão os recursos pra fazer o certo, faz o errado.
Opta por não aplicar as boas práticas por preguiça. Código bagunçado, métodos enormes, nomes de campos nas classes e nas tabelas que não tem nada a ver com a informação armazenada neles. Jeitinhos, go horse só pra terminar mais rápido e ficar de bobeira. Três loops for aninhados e dentro do mais interno faz uma query no banco de dados? Se esse for o jeito mais fácil de fazer, é assim que vai ser feito.
Esse cara, o legado instantâneo, joga a culpa dos bugs que explodem nas costas dos dev júnior, mesmo que esse jr mostre no histórico do git que na verdade foi o legado instantâneo.
O legado instantâneo é um babaca. Ele diminui e menospreza todo mundo pra se promover. Alguma coisa deu errado? Não foi ele. Alguma coisa deu certo? Foi Ele!!!
O legado instantâneo puxa a moral de todo time pra baixo, pra equalizar com a dele. As coisas só tendem a degringolar com o legado instantâneo. O legado instantâneo não é um estilo de código mal escrito, mas uma atitude pessoal simplesmente má.
Assuma seus erros, compartilhe suas conquistas. Faça certo da primeira vez pra só dar manutenções leves depois. Não superestime, não subestime, não otimize precocemente (mas otimize quando necessário), resolva as issues, faça testes, resolva os alertas do seu lint. Faça classes e métodos pequenos, adote KISS, adote SOLID, adote SCRUM, XP, TDD, DDD, BDD e qualquer outra modinha que inventarem ..... se e somente se todo o time entender e for ficar mais suave pra todo o time com a nova modinha.
Comunique-se com seu time, diga o que está fazendo e o que está desfazendo. Não assuma que algo está errado só porque não foi você que fez, ou só porque foi o dev jr que fez.
Não seja um legado instantâneo.
Não. Seja. Um. Legado. Instantâneo.
Comentários
Postar um comentário