Skip to content

Instantly share code, notes, and snippets.

@rranelli
Last active September 1, 2020 04:56
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save rranelli/deae3b8cbb70084c2ee6f914c80c2a1c to your computer and use it in GitHub Desktop.
Save rranelli/deae3b8cbb70084c2ee6f914c80c2a1c to your computer and use it in GitHub Desktop.

DISCLAIMER: Esse texto é todo minha opinião. Onde cabe referência vai ter referência. Onde não tem referência eu basicamente estou tirando do meu cu mesmo. Leia por sua conta e risco.

Senioridade

Pois bem. A treta da vez na comunidade dev agora é sobre o que é ou deixa de ser “um senior”, o que é razoável pra “um senior” fazer ou deixar de fazer.

Geralmente esse tipo de assunto passa no meu radar e cai direto no /dev/null mas dessa vez teve um twitte que capturou muito minha atenção:

https://twitter.com/gabrielammafra/status/1300469425703968768?s=19

Em especial essa parte:

> A gente deveria estar se perguntando como fazer devs não experientes (que é o > que tem) serem bons.

Como eu sou um sujeito que chamam de Senior fazem uns bons anos e que já entrevistei muita gente muito boa (e muito picareta tbm) e vivi pra ver as consequências talvez eu consiga ajudar.

Vou tentar abordar o tema de uma forma um pouco diferente. Vamos partir do ponto de vista do usuário e construir o papel da senioridade a partir de um modelo utópico de “time de engenharia real porém topissimo”. A ideia é tentar entender melhor que coisas constituem a tal “senioridade” e por que talvez seja uma boa ideia ter uma pessoa com o crachá dizendo “Sênior”.

A utopia

Um time de engenharia de software eficaz é capaz de, dentre outras zilhares de coisas, fazer as seguintes 5 muito bem (ou seja, bem o suficiente que ninguém no negócio reclama que a “engenharia atrapalhar/é lenta/não é confiável”):

  1. Descobrir quais problemas valem a pena serem resolvidos.
  2. Propor alternativas (plano/projeto) para a solução desse problema e balancear prós e contras.
  3. Executar & acompanhar se as soluções de ontem continuam funcionando hoje. Caso contrário, incorporar no trabalho o que tiver de ser necessário para que continue funcionando indefinidamente.
  4. Explicar por que tal coisa aconteceu.
  5. Observar, medir e melhorar o próprio processo de construção.

Repare que até agora não falei de individuos – Idealmente o time seria composto por um unico individuo mágico onisciente e imortal. No mundo real, precisamos atingir isso tudo com gente. E ai que tudo fica muito mais difícil.

Para atingir essas 5 qualidades o time precisa, em conjunto:

  1. Aprender (0, 2, 4)
  2. Executar (1, 2)
  3. Comunicar (*)

O grupo precisa exibir essas qualidades/caracteristicas. Até agora nada falamos sobre cargos, organização, liderança. E isso é de propósito – Todas essas coisas são acidentes da solução que empregamos para entregar valor.

Realidade

Uma abordagem muito comum que vemos no mercado, e que de fato faz algum sentido como vamos abordar, é separar as pessoas individualmente em níveis: junior (quem ainda está a aprender), pleno (quem já se vira sozinho), senior (???).

A premissa é que se a gente espalhar essas habilidades – aprender, executar, comunicar – entre esses 3 níveis vamos ter um bom balanço e atingir a configuração utópica.

E é ai que as coisas começam a ficar gelatinosas. Na pratica o que vejo muito frequentemente é que o “Senior” acaba virando a figura que “preenche os vazios” entre a realidade do time e o estado desejado – Cabe ao Senior “fazer rolar”. Seja lá o que isso significa.

E como é muito comum as organizações de engenharia não saberem direito o que querem, quando querem, como querem ou porque querem esse papel de “Senior” fica muito propenso à virar um papel “gelatinoso” que se expande para ocupar o vácuo que ali se manifesta, seja ele técnico, processual ou simplesmente de bom-senso.

A forma da figura do senior acaba sendo uma “consequência” ou a manifestação de um trauma muito específico à organização, seu histórico e seu tempo. Por fim, ficamos todos com a amarga constatação que “ninguém sabe direito o que é ser senior”.

Arrisco dizer que a própria pergunta não faz nenhum sentido. Ora, se o nosso entendimento de senioridade é tão dependente assim de mil fatores, vale a pena discutir em termos disso? E uma vez definido o significado dessa “senioridade”, o que isso significa para os outros níveis? E quando colocam um arquiteto no meio?

Em suma, acredito que a resposta pra esse tipo de questão não está em tentar delimitar caixinhas e escrever o que “cada sujeito tem de fazer” mas sim em voltar para os principios da sessão sobre utopia: O que queremos do time e como cada um pode ajudar?

E é olhando para essas qualidades (FIXME link), dia após dia, buscando de expertise, prototipagem, dados operacionais e tudo mais que descobrimos se as nossas práticas estão nos ajudando ou atrapalhando para atingir a visão.

Tá, mas como encaixar isso no meu trampo?

Agora que estabelecemos um “framework” para falar dos cargos, vou explicar a minha interpretação de como podemos nos aproximar do time ideal usando os papeis de “junior”, “pleno” e “senior”. Para definir qual função é executada por qual papel vamos aplicar o mesmo princípio a cima: Onde cada papel pode melhor ajudar?

O profissional “Júnior” é entendido como alguém no começo de carreira, sem tanta familiaridade e vivência com a industria. É esperado que esse profissional precise de uma dose maior de apoio e ajuda para executar as tarefas do dia-a-dia do time.

É durante esses momentos de apoio que o Junior gera um valor que talvez só ele consiga: fazer as perguntas óbvias. E quando falo perguntas óbvias eu não falo com tom de desdém – muito pelo contrário. A medida que estamos “enraizados” no contexto específico da nossa organização, é muito fácil perder de vista o que é acidental do que é essencial (como já falamos antes, a própria noção de “sujeito Senior” é um acidente). É essa pessoa que ainda não está cicatrizada o suficiente que consegue nos fazer perceber coisas que são mais complexas do que deviam, coisas que “não fazem sentido se você pensar bem” e por ai vai.

O profissional “Pleno” é entendido como alguém que já se vira sozinho e que não precisa mais de tanto apoio. É esperado que em questões mais “cascudas” o sujeito precise de apoio de um membro mais experiente. No mais, é esse papel que “executa” a grande parte do trabalho e fornece “o grosso” do apoio que os Juniores precisam.

“It goes without saying” que o profissional Pleno também precisa ser um excelente Junior. Para que você seja eficaz em executar, você precisa ser muito bom em aprender e experimentar dentro do microcosmo da sua tarefa em foco – Não da pra ser bom pleno sem ser um bom Junior.

Já o profissional “Senior”, o tema desse post todo, é quem “erra por ultimo”. O que diferencia o Senior dos demais níveis nesse modelo é simplesmente o fato de ele ter “feito isso várias vezes” – ou seja: A diferença do senior é ser mais “velho” – ou seja: A diferença do sênior é ser sênior. (eu disse que ficaria meta).

E aqui já faço um disclaimer antes que venha o esperto “ahhh mas tempo de experiência não é tudo”. Sim, é claro que não é. A velocidade com que as pessoas adquirem as qualidades supramencionadas é muito dependente do contexto específico (as all things software) e de quão madura está a equipe. Voltaremos nisso em breve.

Piadas a parte, é exatamente essa “velhice” que da substância e peso à palavra de um sujeito Senior. É por ter “visto coisas” que precisamos escutar os Senior. E claro, it goes without saying, como o Senior participou de muitos ciclos, ele é o profissional mais apto a *olhar para a cadeia de valor como um todo*/visão holistica. E para ser eficaz em direcionar a cadeia de valor o Senior precisa ser um excelente Junior, para entender cada vez melhor as complexidades e nuances do produto e suas interações, e também precisa ser um excelente Pleno. You get the idea.

E essa capacidade de executar/direcionar/ensinar/aprender as qualidades da entrega de valor eu vou chamar de senioridade.

Quem tem senioridade consegue todos os dias entender um pouco mais sobre o produto, sobre a tecnologia; todos os dias consegue se perceber errado; todos os dias consegue observar oportunidades de melhora. E todos os dias faz isso de forma que fique mais fácil para os colegas fazerem o mesmo.

Conclusão

Depois disso tudo, finalmente conseguimos responder:

“Milhouse, de onde saem os Senior?”

Os seniores saem de times eficazes. Os seniores saem de times que sabem o que estão fazendo e por que estão fazendo. Os seniores saem de times que descobrem que na verdade a gente não sabia muito bem e que entendem por que não sabiam. Os seniores saem de times que não tem vergonha de errar, que se orgulham de acertar e que são precisos. Os seniores saem de times que causaram incêndios, derrubaram produção e causaram vários prejuízos. Os seniores saem de times que não repetem os incêndios. Seniores saem de times que se importam.

Muitas vezes esses Seniores nem se consideram seniores. Nada adianta ter Senior no titulo mas o produto do seu trabalho só deixar mais difícil que os outros façam o mesmo que você.

O que importa não é o que um “senior” é capaz ou não de fazer – O que importa de verdade é o que conseguimos atingir juntos. Seniores ou não.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment