Início > Blog, Carreira, Desenvolvimento > De Júnior a Sênior

De Júnior a Sênior

Vivemos uma época transformadora no desenvolvimento de software . A partir da segunda década do século XXI só vai sobreviver quem fizer software barato (leia-se: sem “gordura”),  recheado de valor, feito com responsabilidade e entregue no prazo. É a hora de separar o trigo do joio.

Os sufixos júnior e sênior me aborrecem enormemente desde sempre. Especialmente quando utilizados fora de contexto ou como sinônimos de “tempo de serviço”. Mas o que realmente faz de você um júnior ou um sênior?

A resposta a esta pergunta pode não ser o que você esperava ouvir. Mas se quiser trabalhar com software nos próximos decênios é bom que a aceite.

A diferença entre júnior e sênior não está na idade, nem no tempo de serviço. Está na maturidade técnica e na maturidade profissional.

Para um júnior, trabalhar muito é sinônimo de “bom”. Trabalhar até altas horas e acumular um monte de horas extra é um sinal de dignidade. Para um sênior só de isso ser sugerido, é um insulto. O sênior sabe que se algo der errado não é com horas a mais ou fins de semana longe da família que o problema se resolve. Bem pelo contrário. Se agrava. Então a posição do sênior é não ter problemas. Para isso ele usa todos os seus skills técnicos para que problemas não aconteçam ou sejam facilmente mitigados. Um bom design, uma bateria de testes automatizados e muito refactoring são ferramentas básicas do sênior para não deixar “a vaca ir p’ro brejo”.

Para um júnior, boas práticas são subjetivas e discutíveis e gambiarra é um martelinho de ouro que resolve todos os problemas com uma pancada só. Para o sênior, as boas práticas são como leis da natureza, objetivas e irrevogáveis, e a gambiarra um pecado demoniaco intolerável que tem ser exorcizado a qualquer custo de todo aquele de quem se apodera. O sênior sabe que seguir bons princípios e boas práticas fazem as coisas fluirem mais facilmente e responder mais eficazmente a imprevistos enquanto o júnior ignora que as suas gambiarras são aquilo que está fazendo seus fins de semana serem perdidos na empresa ao invés de poder estar em casa ou em passeio com os amigos ou a namorada.

O júnior acha que o objetivo de construir um software é fazer o programa funcionar. O sênior sabe que o objetivo de criar um software é fazer uma aplicação de fácil manutenção. Pois é na manutenção que está o custo e não na criação.

O júnior acha que com 3 anos de serviço pode ser um pleno. Um pleno tapado será se pensa que o tempo traz experiencia. O trabalho é que traz experiencia. O sênior sabe que desenvolver software é uma arte e uma arte não se aprende com o tempo e sim com a prática.

O júnior tende a usar pouco a cabeça, tentando seguir ao máximo “receitas de bolo”, sem se ater ao contexto. O sênior racionaliza o problema e encontra a solução mais flexível até à solução. Normalmente esta solução só é possível com o uso de alguma técnica avançada de desenvolvimento de software como o uso de  objetos  em vez de rotinas. Como para o júnior boas práticas são piadas que se contam aos amigos este tipo de técnica passa longe.

O júnior fica feliz quando o dinheiro entra na conta todo o mês, o sênior dorme tranquilo quando sabe que o código que a sua equipe fez tem qualidade e pode ser mostrado a qualquer um.  Bom, nisso o junior é muito semelhante. Ele também não tem nenhuma vergonha do código que escreve. Acontece apenas que ele não a tem porque não enxerga as tremendas burrices que o seu código exclama.

Maturidade profissional não se ganha com o tempo. É preciso que a pessoa tenha orgulho no que faz e prime pela qualidade do que faz. Só isso a fará se aprefeiçoar.

Se você acha que ainda é júnior, não se desespere, aprimore-se. Acredite que as boas práticas são realmente boas e apreenda-as. Use-as. Tenha orgulho do que faz e vergonha dos seus erros. Procure qualidade e não quantidade. Procure terminar antes do prazo e com mais funcionalidades e não se faça de preguiçoso para poder arrecadar algumas horas extra. Seja profissional. Desconfie de qualquer um que o tentar levar pelo mau caminho.

Se você conhece alguém nas condições descritas aqui como júnior que ocupa um cargo sênior não tenha medo nem vergonha em o desafiar. Tanto tecnica como profissionalmente. Teste-o. Ele pode estar enganando você. E se você é diretor de gerentes de TI, a probabilidade de estar sendo enganado por um júnior se passando por gerente é quadriplicada. Cuidado, abra os olhos.

Se você é um sênior, tal como descrito aqui, meus parabéns. Agora é hora de elevar a qualidade exigindo mais dos que estão à sua volta. Ou dobra ou parte. Não há meio termo. O seculo XXI não terá pena de quem for conivente com a mediocridade.

About these ads
  1. 2009/06/20 às 23:40 | #1

    Ótimo texto. Parabéns

  2. 2009/06/22 às 10:01 | #2

    Fala Sergio, post muito bom. Acho que compartilho muito das características necessárias para ser Senior. Entretanto acho que ainda não possuo experiência necessária, por isso me considero sendo um pleno.

  3. João Lucas dos Santos
    2009/06/22 às 11:45 | #3

    Parabéns pelo texto.

  4. 2009/06/22 às 12:13 | #4

    Existe uma responsabilidade e um conciência individual para se considerar apto ou não a determinada função, infelizmente no Brasil a parceira Faculdade & Empresa é uma verdadeira faixada.
    Profissionalismo requer também auto-confiança e ter astúcia de encarar o desconhecido, requer uma certa auto-ditática e ser diferenciado.
    Temos ai uma demanda de pessoas que possuem determinadas qualidades e expertise de lidar com situações criticas e embarasoça ou mesmo blefam dizendo aquilo que a gerencia quer ouvir , um monte de inverdade e promessas de sucesso em um projeto fálido.
    Não se denomine junior, pleno ou senior se denomine profissional e lhe garanto que você vai mais longe.Quanto alguém lhe monta uma herquia é que ter lhe sujeitar a responsabilidades até inexistente, e então faça o seguinte.
    Se lhe perguntar se você é junior, pleno ou senior rebata da seguinte forma, diga que você é profissional, isso já lhe garante a vaga.

  5. franciscosantana
    2009/06/22 às 12:16 | #5

    Sérgio, um excelente post.

    O passar do tempo é irrefutável e independe de nós, mas a forma como aproveitamos esse tempo faz a diferença. Esse movimento de absorção e de exposição de informação através de boas práticas e exercício sério da profissão é que distingue o nível de cada profissional.

    Percebo que valorizar o tempo é o principio básico de se ser sênior. Seja o tempo do cliente, da equipe, da empresa ou o seu pessoal fora do trabalho.

    Mais uma vez, parabéns.

  6. Edson
    2009/06/22 às 13:16 | #6

    excelente!!!

  7. Otávio
    2009/06/22 às 14:31 | #7

    Ótimo post, parabéns.

  8. Rodrigo
    2009/06/22 às 15:53 | #8

    Muito bom o texto, e “gambiarra” vc tem razão, encontra de monte, rsrsrs

    abçs

  9. Rafael Castanho
    2009/06/23 às 13:02 | #9

    Meus parabéns pelo seu post!!

  10. Lúcio Assis
    2009/06/23 às 20:53 | #10

    “Para o sênior, as boas práticas são como leis da natureza, objetivas e irrevogáveis, e a gambiarra um pecado demoniaco intolerável”

    Achei isso muito exagerado. É preciso saber viver com gambiarras e ter jogo de cintura pra dizer quando você vai ou não aplicar uma. Se uma gambiarra representa uma vantagem competitiva considerável pro seu negócio contra não fazer a gambiarra, ir atrás da solução ‘irrevogavelmente perfeita’ pode fazer você perder uma boa oportunidade. Da maneira que o ponto foi colocado, parece que ninguém deveria correr riscos com gambiarras, mas se a possibilidade de ganho é boa, não acha que vale a pena administrar o risco ao invés de correr dele?

    • sergiotaborda
      2009/06/24 às 7:50 | #11

      Não, não acho.
      Se existe uma oportunidade de negocio que, de alguma forma, necessita de uma alteração não antes prevista a solução não é fazer gambiarra. Nunca gambiarra é solução de coisa alguma. A solução é fazer um refactoring, aplicar algums padrões ou até mesmo remodelar uma parte do sistema, para que ele faça o que deve sem ferir as boas práticas e a modelagem OO.

      Nunca ha desculpa suficiente para usar uma gambiarra. Nunca! Pensar o contrário é danoso. Repare : vamos aceitar que por motivos de competitividade você faz a gambiarra. Como ela é contra-senso do resto do sistema e não se encaixa no modelo do resto do sistema era representa sempre uma exceção à regra com a qual vc precisa de preocupar sempre que alterar o sistema. Hoje uma gambiarra para competir, amanhã outra, depois outra.. e você vai se enganado com o fato de estar “competindo” e o seu sistema estar “funcionando”. O problema é que mais tarde ou mais cedo ( normalmente mais cedo) o conjunto de gambiarras, todas elas exceções e todas elas não corretamente integradas no modelo do sistema viram um bloco de exceções com que você tem que se preocupar. Sendo que normalmente elas não são documentadas e não se integram com mais nada se tornam um tumor. Chega a um ponto onde para continuar competindo vc precisa colar mais alguma funcionalidade e gambiarra ou não, vc não consegue porque o seu sistema virou uma massa heterogénia de codigo amorfico completamente imcompreensivel. Agora, neste estágio, o tumor é demasiado grande. Nem com outra gambiarra você consegue resolver o problema. O resultado é que essa competição que nos primeiros tempos você usou para permitir a gambiarra não é mais possivel. O seu sistema é um monstro que não vai a lado nenhum. A sua competitividade cai que nem uma pedra e você está na roça. Ai, normalmente, a solução e é o clássico : “vamos fazer outro sistema melhor”. Mas ele nunca será melhor se você continuar aceitando a gambiarra. Vai tudo acabar como começou. Sem competitividade e sem sistema.

      Criar um software não é prover um programa que funciona e com isso ganhar dinheiro. É criar uma aplicação que pode ser facilmente alterada. Assim, mesmo que não funcione rapidamente você consegue por a funcionar e se for necessária alguma coisa extra, rapidamente você adiciona. Quando você encara a possibilidade de fazer uma gambiarra isso é um sinal que o seu modelo, tecnologia ou implementação não são flexíveis o suficiente e ai a solução não é dobrar o sistema para fazer o que você quer, a solução sempre é modificar o sistema para que a alteração faça parte do sistema de um forma fluida.

      A gambiarra nunca é desculpável. Nunca! Sobre nenhuma condição.
      Pensar o contrário é se enganar. Não se engane.

      • 2009/08/06 às 16:13 | #12

        Isso tudo se encaixa perfeitamente num ambiente empresarial onde cada etapa de desenvolvimento é respeitada. Em empresas onde o lema é “o negócio da empresa não é esse, então pode meter um POG que tá bom” aí… Não adianta perder tempo com o certo, porque o certo será descartado logo mais a frente.

      • sergiotaborda
        2009/08/07 às 11:03 | #13

        Infelizmente é verdade que em empresas onde o negocio não é fazer software (não são software houses) então o development kit aparece como uma ferramenta tal como o word e o excell. E da mesma forma que as pessoas não dominam essas ferramentas também não dominam o kit de desenvolvimento. Aqui existem duas opções : ou a pessoa chamada de programador ( utilizador do dk) é um programador de verdade ou não é. Se é, não tardará muito a que ele se aborreça de fazer tudo POG e migrará para outros pousos. Se não é, paciência. O problema é que o mercado está infestado de utilizadores de dk que não são programadores. Parcialmente por culpa deles mesmos, parcialmente pelas circunstancias e totalmente pela falta de preocupação dos programadores verdadeiros que deixa o seu oficio ser vilipendiado dessa forma.

        Quando se contrata um contador para trabalhar internamente sempre ha aquele jeitinho e isso se propaga para contadores que atuam terceirizados já que o “mercado” “exige” isso. Mas ninguém contrata um médico e espera que ele faça gambiarra. É esse nivel de ética que os profissionais não têm e os utilizadores de dk têm menos ainda.

        É um problema que só pode ser enfrentado com educação. E por isso é tão difícil resolvê-lo.
        Ninguém demonstra a essas empresas utilizadoras de dk que isso é mais caro que contratar uma empresa de software terceirizada que faça as coisas bem! … pois, o problema é esse mesmo, essas empresas também não fazem as coisas bem…

  11. 2009/06/24 às 14:52 | #14

    Concordo com você Sergio,

    Uma excelente explicação sobre a tal “gambiarra”, na sua visão profissional, isso mostra que existem pessoas comprometida com a evolução e não com o ar de superficialidade que lidam com sistemas. No que entende a mesma atitude se procede até com a propria vida particular como é tratada dessas pessoas, na base de gambiarra, ou melhor dizendo no cambalacho.

    Abrassss….

  12. Lúcio Assis
    2009/06/24 às 21:33 | #15

    Sim, faz sentido o que você disse: é preciso correr do amontoamento de gambiarra, mas penso que a boa comunicação dento da equipe, ou seja, documentação da gambiarra + plano pra acabar com ela, faz com que ela seja tolerável. Se você não previa um certo cenário, você consegue enxergar a solução limpa da coisa mas nem sempre tem o tempo que precisa pra implementar. Você poderia dizer que ‘se você não tem tempo, é porque a solução não é flexível o suficiente’. Mas não sei ver o futuro. A flexibilidade que eu coloquei pode não ser suficiente pra uma coisa nova que apareceu e eu não tinha pensado.

    Acho que o problema é que é raro encontrar por aí a organização e a disciplina necessárias pra realmente ir lá e consertar o que se documentou como quebrado, daí gambi ser tão mal vista. Onde eu trabalho elas se chamam “tactical solutions”, são documentadas, revisadas e consertadas em tempo. Mas concordo que esse não é o caso na maioria dos lugares.

  13. 2009/06/25 às 11:23 | #16

    Ótimo texto, muito bem completado também pelo comentário do Marcio Duran.

    O problema pode ser agravado por alguns gerentes que prezam pelo tempo gasto no projeto do que pela qualidade da solução. De fato premiam quem fica até tarde mesmo que escrevendo gambiarra, ao invés de alguem que deixa de “gerar resultados” para escrever testes, por exemplo.

  14. Alex Rios
    2009/06/26 às 10:42 | #17

    Parabén pelo texto!
    Concordo absolutamente.

  15. 2009/06/28 às 18:32 | #18

    realmente, excelente post, muito show mesmo.

    parabens!

  16. serjaumfantin
    2009/08/03 às 9:20 | #19

    Fala chará!
    Concordo com você! Tempo acumulado não transforma ninguém em pleno. Se você não tiver orgulho do código que escreve e não buscar sempre as boas práticas, será um eterno júnior.

    Abraços…

  17. dchohfi
    2010/01/14 às 15:53 | #20

    Olá Sergio, incrivel o seu blog e mais incrivel ainda este post! Fantástico, concordo em tudo o que disse e acredito que isso ocorra o tempo todo em diversas empresas, junior que se acha senior e senior que ainda não foi descoberto e continua ocupando um cargo sem muitas responsabilidades. Realmente desenvolvimento não é linguagem, é arte! Parabéns novamente, um grande abraço!

  18. 2010/03/18 às 23:56 | #21

    eh sergio, excelente texto mesmo. parabens! alem de motivador mostra a realidade. :D.
    abracos,

  19. SMafra
    2010/03/30 às 18:45 | #22

    Há vários pontos de vista para a discussão “junior” vs “senior”.

    Uma delas pode ser enquadra-se na oferta de empregos.

    Geralmente, o termo “junior” significa q a empresa está disposta a pagar um baixo salário.

    Não obstante, é muito comum vc encontrar em ofertas “junior” a exigência de conhecimento “senior”.

    É uma piada.

  20. Juan
    2010/04/09 às 10:24 | #23

    Me lembrei do David Allen: “Programmers work long hours trying to design stuff that keeps them from having to work long hours”

  21. 2011/07/05 às 14:43 | #24

    Muito legal!

  1. 2009/07/01 às 18:48 | #1
  2. 2009/07/04 às 9:57 | #2
  3. 2012/03/15 às 11:25 | #3
Tem de ter a sessão iniciada para publicar um comentário.
Seguir

Get every new post delivered to your Inbox.

%d bloggers like this: