Vamos começar do começo. Eu vou dizer que até eu fico meio confuso com os diferentes cursos em faculdades. Existem faculdades que usam o mesmo nome de curso mas ensinam coisas diferentes, acho que principalmente em Sistemas de Informação. Existem faculdades que ensinam de formas diferentes. Fora os diferentes níveis de qualidade e reconhecimento. Então dependendo de onde você estudar, vai ter diferenças consideráveis. Infelizmente eu não posso ajudar muito aqui, não existe nenhuma forma objetiva de comparar curso a curso de todos os lugares.
Quando eu comecei a escolher cursos pra faculdade lá por 94 haviam principalmente 3 cursos diferentes. Engenharia da Computação, Ciências da Computação e Processamento de Dados. Até onde eu entendia, Engenharia da Computação é de fato uma engenharia, na realidade eu chutaria que é uma especialização de Engenharia Elétrica. Esse é o curso praqueles interessados no hardware em si, microprocessadores, placas lógicas e você teoricamente deve aprender a desenhar circuitos, desenhar placas, propriedade dos materiais e até processos de fabricação.
Normalmente os diversos cursos de engenharia todos começam igual, você tem dois anos da mesma grade e no meio você escolhe pra qual engenharia vai se especializar, tipo civil, naval, produção, elétrica, mecânica, etc. Pelo menos na USP era assim. Os primeiros anos é muita matemática, e ainda assim menos do que nos cursos de matemática mesmo, mas é cálculo, álgebra, física. Confunde um pouco porque você tem programação no currículo, mas eu imagino que é mais voltado à programação de mais baixo nível. Porta lógicas, circuitos integrados, semicondutores, talvez se fale em coisas como CMOS e MOSFET, VLSI, etc. Se você quer trabalhar na indústria de eletrônicos e automação por exemplo, seria esse o curso.
Ciência da Computação foi o que eu fiz, e eu diria que é uma especialização da Matemática Aplicada. A matemática pura, como você pode imaginar, não se preocupa tanto com a aplicação. Já computação é uma aplicação da matemática, por isso eu digo que seria uma especialização. Os dois primeiros anos de Ciências da Computação é muito parecido com os cursos de matemática mesmo e por isso muita gente não gosta porque se vê muito pouco de programação nesse período. Só a partir do 5o período você começa a ver mais coisas como montadores, compiladores, sistemas operacionais.
O objetivo de um curso de ciências não é ensinar o que o mercado do momento precisa. Você até tem matérias opcionais, que tentam introduzir alguma coisa mais prática, mas não é esse o foco. Computação, como eu disse, é uma aplicação da matemática, toda a base de conhecimento que torna um computador possível vem de décadas atrás, começando com a arquitetura de Von Neumann. Não importa se o computador de hoje é ordens de grandeza mais rápido que um dos anos 80, fundamentalmente eles ainda operam da mesma maneira. Mesma coisas como linguagens de programação. Tanto faz qual é a linguagem mais moderna de hoje, um Java de hoje fundamentalmente funciona da mesma forma que um Basic nos anos 70, só é mais complicado. Em vez de aprender só uma linguagem, você deveria aprender como todas elas funcionam no nível dos compiladores, por exemplo.
O que na minha época era Processamento de Dados ou mesmo Análise de Sistemas hoje em dia acho que é chamado de Sistemas de Informação. O grosso da computação aplicada na indústria continua sendo muito de “processamento de dados”. Por exemplo, numa multinacional de 10 mil funcionários, todos eles batendo cartão de ponto, imagine contabilizar as horas trabalhadas de todos, na mão. Ou imagine fazer o fechamento contábil de uma rede de varejo no papel. Ou no Brasil que você tem uma tonelada de regulamentações pra seguir, Reinf, SPED, ECF e por aí vai.
Eu não acompanhei a transição dos cursos de Processamento de Dados pra Sistemas de Informação mas o objetivo é parecido, que é a automatização de processos envolvendo informação na forma de sistemas, por isso Sistemas de Informação. Teoricamente você se forma tecnólogo ou bacharel e pode atuar como um analista de automatização de processos de informação. No mundo corporativo que é formado de diversas áreas como recursos humanos, vendas, financeiro, manufatura, etc todas precisam ser integradas, automatizadas, e um analista de sistemas de informação seria o profissional trabalhando nisso. E já que mencionei tecnólogo e bacharel vale esclarecer. Eu entendo que ambos são nível superior, e um bacharel é mais generalista do que um tecnólogo, e cursos de tecnólogo são mais curtos e mais focados.
E isso me leva pra outro curso que me parece que começou a aparecer mais nos anos 90 que é Engenharia de Software. Pelo menos pra mim esse sempre foi mais estranho. O maior problema de software, do ponto de vista das metodologias de programação, é que eu nunca consegui enxergar tanto como uma "engenharia" da mesma forma como engenharia civil ou mecânica por exemplo. Acho que de todas as engenharias, a de software é a única que não lida com hardware ...
Software em si não obedece leis da física. Quantidade de código não aumenta seu “peso”. Ele não tem cheiro, não tem textura, nada, é totalmente abstrato. Poderíamos escrever software pra uma máquina infinita teórica, com poder de processamento infinito, armazenamento infinito e velocidade de transferência de dados infinitos. Seria como na matemática pura. No mundo real, pra não dizer que não existe nenhuma lei, software é de fato limitado pelos ciclos do processador, pela capacidade de armazenamento e pela velocidade de transferência dos dados entre os diversos componentes.
Mas do ponto de vista do código em si, ele não tem limites. Eu posso literalmente escrever qualquer coisa. Tecnicamente, as linguagens também não tem limites, sendo todas Turing Complete eu posso escrever qualquer software em qualquer linguagem. Eu gosto da definição de engenheiro como sendo aquele que aplica os princípios da ciência e da matemática pra desenvolver soluções economicamente viáveis pra problemas técnicos. É o elo que liga as descobertas científicas às aplicações comerciais.
A parte da ciência que o engenheiro usa vem da ciência da computação cuja função é resolver problemas computacionais ou melhorar a performance das soluções existentes, é realmente mais voltado a uma forma de pensar mais de pesquisa, não necessariamente que a pessoa precise virar um pesquisador. Seja novos algoritmos. Seja novos componentes de computação como novas linguagens ou novos sistemas operacionais ou novos protocolos de rede. Veja os produtos que um Google lança como Protobufs, a virtual machine Dalvik, os algoritmos de pesquisa, bibliotecas de gerenciamento de memória melhores, tudo trabalho de pesquisa de ciências da computação. Daí você tem ferramentas como a linguagem Go, o framework Flutter, um Kubernetes, tudo trabalho de engenharia. E finalmente a aplicação dessas tecnologias pra criar produtos como o Google Analytics, o Gmail, o Google Maps, que poderia sair da mão de analistas de sistema e engenheiros trabalhando juntos.
Porém, os papéis não são tãaaao bem divididos assim. Existem cientistas com cabeça de produto, existem engenheiros com cabeça de pesquisa, existem analistas com cabeça de engenharia. Pode ter gente que saíram de diferentes cursos convergindo pros mesmos papéis. A beleza do mundo de tecnologia é que me parece mais fácil um cientista da computação ir pra engenharia de software do que um arquiteto de verdade virar engenheiro civil. Posso estar falando uma grande bobagem, mas é como a analogia se encaixa na minha cabeça.
De todos os cursos, o mais fácil de escolher talvez seja engenharia da computação, porque você já tem na cabeça que quer lidar com hardware, entrar na indústria de automação, produção, eletrônicos e coisas assim. Talvez a dúvida seja se você quer engenharia elétrica com especialização em computação ou engenharia da computação propriamente dita. Mas eu não estudei engenharia o suficiente pra saber qual o melhor.
Se seu foco for programação, você pode virar um programador mais cientista, ou mais engenheiro, ou mais analista. A grosso, bem grosso modo, é como eu dividiria se quisesse simplificar beeeem simplificado. Generalizando eu diria que a maioria dos autodidatas que já começou trabalhando por conta e aprendendo sob demanda, acaba sendo mais um programador analista, porque falta a fundação formal de ciências e engenharia. Elas podem ser aprendidas sozinho, mas a maioria dos autodidatas jovem sequer sabem da existência dessa fundação.
Como eu sou de ciências da computação, eu sempre vou ter um viés pra ciências. Mas não existe necessariamente uma correlação entre o curso que você escolher e seu sucesso no futuro. O sucesso depende mais do tipo de pessoa que você é, do que o curso em si. Todos os cursos são só bases pra começar. Eu sempre vou defender que você aprenda matérias que historicamente sobreviveram ao teste do tempo. Uma matéria como, digamos, Flash que tenha aparecido na grade de um curso no começo dos anos 2000, hoje é inútil por exemplo. Quanto mais específico em alto nível, mais rápido tende a ficar defasado, mas mais prático no dia 1. Quanto mais específico em baixo nível, mais tende a ter valor ao longo do tempo mas menos prático vai ser no dia 1, como cálculo ou estatística.
Como eu também sou defensor de jogar o jogo do longo prazo, eu defendo que um curso de programação cujas matérias tendem a te acompanhar por mais tempo no futuro seja ciências da computação e depois as engenharias, e um bacharelado antes de um tecnólogo. Mas isso é um compromisso de longo prazo, ou seja, você realmente não tem intenções de mudar de área. Mas eu sei que muita gente não tem essa certeza aos 17 anos. Por isso eu não sou contra cursos como sistemas de informação e tecnólogos. Você sempre pode estudar ciências depois. Vai ser bem mais difícil, especialmente se você estiver trabalhando, mas não é impossível dado que existem centenas de casos de pessoas acima dos 30 ou 40 anos fazendo exatamente isso.
Suas opções ficam mais limitadas, claro, é sempre um trade-off. Não existe uma decisão correta com resultado garantido, você vai ter que jogar. Suas chances sempre vão ser fifty-fifty, cara ou coroa. Alguém decidido a não mudar de caminho, como eu, que decidi por ciência como primeira opção e me segurei nela desde então, é só um cara teimoso. Por sorte eu dei certo. Nem todo mundo precisa ser teimoso, e eu conheço muita gente mais bem sucedida que eu que mudou de caminho várias vezes. Tudo depende de que tipo de pessoa você é.
Um médico tem como prioridade salvar o paciente que está na sua frente na melhor das suas habilidades e usando os recursos que existem hoje. Um pesquisador de laboratório tem como prioridade salvar o máximo de pacientes no futuro, aprimorando ou inventando tratamentos e ferramentas que vão equipar os hospitais e consultórios no futuro. Nenhum dos dois está errado e um precisa do outro pra continuar progredindo.
Um cientista da computação pode ter como prioridade a pesquisa de como aprimorar o gerenciador de memória de uma linguagem pra que ele use menos recursos e performe melhor no mesmo hardware. O correto é ele usar cálculo e estatística nesse processo. O engenheiro de software pode ter como prioridade os diferentes processos e técnicas de como usar as linguagens pra desenvolver aplicações com o melhor custo benefício. Ele pode usar princípios da engenharia de produção. Um analista de sistemas tem como prioridade usar essas linguagens e essas técnicas pra automatizar o problema real de uma empresa hoje, assim como um médico. Porém, diferente de um médico que tem um CRM e não tem autorização pra inventar um novo tratamento e testar em pacientes, um analista pode sim dar uma de engenheiro ou cientista e testar alguma coisa experimental, embora não seja essa sua prioridade.
Alguém com formação em ciências ou engenharia teria mais capacidade de desenvolver o software que equipa o sistema de estacionamento automático de um carro, mas provavelmente não um analista. Por outro lado, alguém com formação em ciência não tenha paciência pra analisar e resolver os problemas de dia a dia de uma empresa como um analista. E um analista talvez não tenha paciência pra ficar inventando soluções como um engenheiro.
Eu posso ficar o dia inteiro fazendo comparações e não vamos ter raspado a ponta do iceberg. É importante você, que é iniciante, entender que independente do que você escolheu e estudou, ao final da faculdade, você ainda não está nem perto de estar pronto. Programação, seja com perfil mais de cientista, ou mais de engenheiro, ou mais de analista, continua sendo uma profissão de prática. Agora são mais longos anos de prática na área.
E aqui começa outro problema pra mim. Júnior, pleno, sênior. O único mais ou menos fácil de definir é estagiário porque a CLT define isso. Existe um TCE ou termo de compromisso de estágio assinado entre a empresa contratante, o estudante que é o estagiário e a instituição de ensino. Se você não sabia disso, pesquise a respeito. De qualquer forma é uma atividade remunerada mas não de carteira assinada, com carga horária menor do que o normal, supervisionada, com tempo máximo de 2 anos.
Eu diria que a nova lei prejudicou a vida dos autodidatas porque não existe mais a oportunidade de estágio fora de vínculo com uma instituição de ensino. Independente se a instituição tem estágio obrigatório ou não, se possível faça, a partir dos 2 últimos anos do curso. A maioria faz no último ano. E eu sei que em cursos de federais de ciências da computação pode ser difícil porque o curso começa difícil e vai ficando mais difícil até o trabalho de conclusão de curso e muitos tem período integral. A intenção dos cursos de bacharelado em ciências da computação me parece ser mais formar pesquisadores e não tanto inserir no mercado de trabalho.
Se você for recém-formado ou mesmo recém-iniciado a trabalhar na área, tendo tido educação formal ou sendo autodidata, você é um júnior. Basicamente quer dizer que você tem pouca ou nenhuma experiência observada na área. De repente você é um gênio prodígio com QI 500 ou sei lá, mas ainda não há resultados observáveis. Não existe um tempo fixo pra você deixar de ser júnior. As primeiras experiências vão te ajudar a decidir melhor que área você prefere seguir. Se você é mais analista, mais engenheiro ou mais cientista e o que vai continuar estudando sozinho na sequência.
O analista e o engenheiro costumam ter mais opções, especialmente no começo. Um cientista puro que é bom em pesquisa mas não tem paciência pra resolver os problemas "mundanos" vai ter mais dificuldade e em 2019 tende a ir pra áreas como data science, machine learning ou algo assim em tech startups, ou a tentar entrar em empresas realmente grandes que tem condições de ter área de pesquisa e desenvolvimento, como os Google ou Microsoft da vida. A maioria das empresas médias e pequenas não tem o porte necessário pra suportar pesquisa ainda.
Eu por exemplo, apesar de ter estudado ciências tenho mais perfil de engenharia e principalmente de analista, eu tenho zero paciência pra escrever papers, fazer experimentos elaborados demais, e apesar do meu foco ser bom por longos períodos, eu logo mudo de foco de novo. Por alguma razão meu interesse acabou se voltando em resolver problemas mais "reais" e menos abstratos, parte disso porque eu fui consultor corporativo por muitos anos.
Mas eu estou me adiantando. No geral, os níveis de experiência em programação, pra mim, funciona assim: o mesmo problema dado pra um júnior, um pleno e um sênior, podem ser resolvidos com qualidade similar. O que vai variar é o tempo. O júnior não tem experiência, até achar a melhor combinação de programação e arquitetura que resolve o problema da forma mais eficiente, vai levar muitas tentativas e muitos erros. O pleno, por já ter tido mais experiência, vai ter uma gama menor de tentativas e erros, e um sênior provavelmente já viu problema semelhante e já vai ter meio caminho andado pra resolver o problema.
Intuitivamente qualquer não-programador poderia assumir que o código de um júnior vai ser pior do que de um pleno, que por sua vez vai ser pior que de um sênior. E também que o melhor código sempre vai ser do sênior. Eu não gosto muito dessa definição, ela só quer dizer que alguém deixou o júnior subir código em produção sem ninguém avaliar antes. E isso é verdade na maioria das empresas. Todo mundo só vê artigo de blog, papers, palestras de médias e grandes empresas, o 1% do mercado. Mas os 99% que não tem tempo nem recursos pra produzir esse material é justamente porque também não tem muito recurso pra supervisionar os funcionários mais inexperientes e por isso a qualidade geral do código tende a ser baixa.
Eu fico repetindo aqui sobre a dificuldade de definir porque é muito mais fácil encontrar definições que vem de empresas grandes, que podem se dar ao luxo de dar todo o suporte possível aos júniors. Mas essa não é a realidade. A realidade são pequenas empresas, com no máximo 5 ou 6 desenvolvedores, ou menos, entuxados de trabalho até o pescoço, vendendo o almoço pra comprar a janta. Esquece a pompa, esquece metodologia, esquece boas práticas. Especialmente quando os donos também são júniors ainda. Então é um navio sem capitão, à mercê da próxima onda.
A grande maioria das microempresas, infelizmente, não vai sobreviver. Dependendo de qual estatística você procurar, 4 em cada 5 devem fechar antes de completar 5 anos. Não é fácil ser empreendedor, especialmente no Brasil, onde você tem um sócio obrigatório, que não trabalha, só atrapalha, e leva 20% do seu faturamento independente se você teve lucro ou não, e ele deixa o prejuízo pros sócios de verdade, que trabalham. Nem vou entrar nesse mérito hoje.
Como se tudo isso já não fosse obstáculo suficiente, muitas grandes consultorias e fábricas de software tem mania de vender júnior como se fosse pleno, pleno como se fosse sênior e sênior como se fosse expert. É uma estratégia arriscada que funciona quando você é do tamanho de uma Accenture da vida. Por outro lado, num mercado como dos Estados Unidos, o que a gente aqui chama de sênior, pra eles ainda é mid-level, o que a gente chama aqui de pleno ainda é júnior e o nosso júnior seria um trainee talvez. A educação formal nos Estados Unidos, é no geral melhor mesmo.
Considerando um programador júnior com formação em faculdades dos Estados Unidos, nativo e cidadão americano, o salário varia na faixa de uns 40 mil dólares ao ano. Pense em algo na faixa de uns 12 mil reais por mes aqui. Considerando impostos, seria o salário de um pleno, talvez indo pra sênior aqui em São Paulo. Agora, na Accenture da Índia, um programador sênior ganharia na faixa de uns 600 mil rúpias, que é a moeda de lá. Uma rupee é 6 centavos no Brasil, então ele faz o equivalente a menos de 3 mil reais de salário, que seria faixa de júnior.
De novo, esses valores são só exemplos, porque salários varia de lugar pra lugar. Mas tem programadores na Índia que ganham tanto quanto um programador nos Estados Unidos, são raros mas tem. Mesma coisa no Brasil. Tudo depende do que você produz. Se você é o raro tipo de pessoa que tem capacidade e experiência pra produzir código de deep learning e redes neurais que ninguém mais consegue, eu nem sei porque você tá aqui vendo meu canal. Mas se você faz o mesmo tipo de código que todo mundo faz, obviamente seu salário sempre vai ser mais baixo. Sempre vai ter alguém na Índia que faz melhor e mais barato que você, se lembre disso.
Por outro lado, Índia é exatamente outro lugar que júnior é vendido como sênior. Deve ter um sênior lá a cada esquina, literalmente. Por isso a reputação é baixa e o valor é proporcionalmente baixo também. No caso geral, valor não é algo que você determina o que você acha que merece. Valor é determinado por o que essa entidade chamada "mercado" determina. Ache isso justo ou não. É sempre uma negociação. Se você não estiver disposto a negociar, no geral, vai ganhar o que vale, e costuma ser menos do que você pensa. Quanto mais cedo você aceitar isso, menos vai gastar de psicólogo.
Eu levantei esse ponto da remuneração porque na prática, o que todo mundo que discute sobre junior, pleno e sênior quer saber é quando vai ganhar mais, ou porque o cara do lado que parece que sabe menos que você ganha mais que você. E de novo eu vou repetir o que eu já disse em vídeos anteriores. Tirando os casos óbvios de abuso na empresa ou pura negligência mesmo, se você for júnior, a menos que você realmente esteja ganhando tão pouco que mal dá pra sobreviver, não é algo que você deveria se preocupar, ou pelo menos não é o que deveria estar no topo da sua lista de prioridades. A prioridade pra um júnior é estar perto de pessoas mais experientes e num lugar com desafios. Onde você tem alguém que critique o que você está fazendo, aponte o que você está fazendo errado.
Eu estou falando tanto de júnior porque infelizmente saltar de júnior pra pleno e de pleno pra sênior não é uma coisa objetiva. Não é que nem num videogame que de repente você tá com novecentos e noventa e nove pontos de XP e com mais um ponto tcharam deu level up. Não tem isso. Durante sua carreira você vai gradativamente subindo de nível de conhecimento, nível de responsabilidade, qualidade, reputação e vários outros pontos. No final do dia, quanto mais seus colegas e seus superiores vão te dando mais e mais confiança, e quanto mais você consegue corresponder entregando com mais e mais qualidade, mais você continua subindo. Quanto mais você cortar passos, tiver entregas irregulares, quebrar confiança, menos você avança. Ninguém dá muito a mínima quando você as coisas certas, mas basta uma coisa errada e todo mundo nota. E é assim mesmo que as coisas funcionam. Se fosse fácil, qualquer um fazia.
E confiança também funciona assim: quebre uma vez e conseguir de volta custa bem caro. Quando você é claramente júnior, tanto de idade quanto de tempo de experiência, erros são mais toleráveis porque as expectativas não são tão altas assim e erros são esperados. É uma fase onde a medição é se você pelo menos é esperto pra aprender com os erros e não errar na mesma coisa toda vez. É meio óbvio, mas vale dizer.
À medida que o tempo passa, você passa por mais desafios, e vai chegando na tal fase mid-level ou pleno, que apesar de não existir um tempo pré-definido, numa carreira normal, costuma ser depois dos 3 anos de casa e vai durar mais alguns anos. Aqui você corre o perigo de cair na armadilha do que chamamos de Dunning-Kruger effect. É um viés cognitivo onde as pessoas têm a incapacidade de auto avaliar as próprias inabilidades, em resumo, elas se acham melhores do que realmente são. E na minha experiência, eu já vi vários júniors de potencial caindo nisso e regredindo, o que é um desperdício.
Eu nunca parei pra pesquisar tanto desse efeito. Esse nome acho que foi cunhado só por volta de 2011 que foi quando todo mundo ficou blogando a respeito. Mas eu mesmo passei por algo assim na fase que eu era júnior também. Felizmente eu tomei vários tapas na cara e voltei pra realidade, mas quando a gente é novo, dinâmico, estuda sem parar e dá aquela impressão que você é melhor que todo mundo ao redor porque todo desafio que cai no seu colo parece que você consegue resolver, é extremamente satisfatório. E a tendência é você sentar em berço explêndido e estagnar, ou pior, regredir. Você precisa fazer um esforço consciente de imaginar que você sabe menos do que realmente sabe sem se tornar um vitimista de Síndrome do Impostor, quando na verdade você é só um impostor mesmo.
E esse é o truque. Na realidade você é as duas coisas: muito bom em poucas coisas, mas muito ruim em várias outras coisas. Só que isso é normal. Você dificilmente vai automaticamente bom em tudo só porque subiu de nível em uma coisa. Quando se é júnior é fácil porque você é júnior em tudo. Mas quando você está indo pra pleno ou mid-level, você é pleno em algumas coisas mas não em tudo. E quando novos desafios aparecem que você ainda não teve oportunidade de enfrentar, você fica confuso porque “como assim você que é pleno e experiente tá tendo dificuldade de júnior de novo?” É uma transição que pode ser meio desconfortável pra alguns. E muita gente começa a naturalmente tender pra lei econômica do menor esforço: entre tarefas que você já sabe fazer muito bem e tarefas desafiadoras que você não sabe fazer ainda, você começa a escolher só as que sabe fazer.
E é uma das razões de porque eu sempre odiei ser elogiado, especialmente por quem não é tecnicamente melhor que eu. É um incentivo muito forte pra te manter na zona de conforto. Por que você vai sair dessa zona e se arriscar a fazer alguma coisa onde você ainda é júnior, correndo o risco de falhar e as pessoas que te elogiavam depois te olharem com aquele olhar de "nossa, eu esperava mais de você", fazendo você se sentir um impostor? Aí quando você fala que não é tão bom assim, as pessoas ainda vem com o olhar de "nossa, olha o falso modesto".
Tem gente que naturalmente não liga muito pra isso, eu era o tipo que ligava e às vezes ainda caio na bobagem de ligar, então tive que aprender a desligar isso e ignorar sinais externos desnecessários. A única avaliação que interessa é sua auto-avaliação. Avaliação externa que tem importância é a crítica, porque ela pode indicar um defeito na sua auto-avaliação. Mas elogios não significam nada e ainda confundem sua auto-avaliação, e não dão dica nenhuma da direção certa ou errada.
Como eu disse no vídeo sobre não terceirize suas decisões, este é um caso clássico. Você está terceirizando a avaliação que você mesmo devia fazer pra outra pessoa que não sabe 100% dos detalhes de tudo que você faz. Só você sabe tudo que você faz todo dia, toda hora. Se você considera que faz "muita coisa" mas parece que ninguém dá bola, você devia avaliar se o que você faz tem de fato o valor que você acha que tem. Talvez você faça coisas demais que tem pouco valor. Aliás, você só pode produzir ou não produzir alguma coisa. O valor quem determina é quem paga, você pode pedir mais, mas de novo, é uma negociação. Digamos que você resolveu fazer mil origamis, é um puta esforço e dá um puta trabalho. Pra você deve valer muita coisa. Tente vender, vai valer só uma fração do que você acha, “se” tiver alguém que quer comprar.
Aí o cara preguiçoso que corta caminho pode parar pra pensar, por exemplo, "ah, vou parar de fazer testes, é o tipo de coisa que ninguém vê que existe, eu gasto mais tempo pra fazer, no final é tudo a mesma coisa". Lembram quando eu falei que 2 + 2 é 4 independente se alguém disser que é 5? Manter a qualidade do seu próprio trabalho é a mesma coisa: independe de sinais externos. Se alguém disser que não precisa fazer, você sabe que tem que fazer. Porque ao longo do tempo, se seu código é o que sempre causa bugs, sempre volta pra consertar; o que vai quebrando com o tempo é sua reputação. Por outro lado, se você faz o que ninguém pediu que é manter a qualidade, e sempre seu código funciona de primeira, nunca volta, e ninguém nunca elogia mas também nunca critica, ao longo do tempo sua reputação de confiável é que aumenta. Qual dos dois você acha que com o tempo tem mais chances de subir de carreira?
Esses são alguns tipos de micro-decisões que você vai exercitar ao longo do período entre júnior e pleno. O sênior pra ser sênior primeiro precisa ser de confiança, tanto do ponto de vista de integridade quanto de qualidade do que faz. Aqui a intuição falha a maioria das pessoas. Muita gente associa gente que fala bem com gente que entrega bem. Nunca ouça a opinião de pessoas sem skin in the game, eu já disse isso antes. Mais do que fazer um bom código, que é meio esperado, um sênior é sênior porque eu deveria poder confiar nas decisões que ele toma. O valor de um sênior começa na sua capacidade de tomar de decisões - que se não ficou claro, também implica que ele assume a responsabilidade da decisão. Decidir sem ter o ônus do fracasso não serve pra nada, não tem skin in the game.
De nada adianta um programador que sabe fazer um código bonito, eficiente, se ele é um péssimo tomador de decisões, ou pior, sequer consegue se decidir e fica em cima do muro, ou posterga, ou empurra com a barriga. Isso eu espero de um júnior. De um sênior se espera que ele tome a decisão certa na hora certa, e ninguém precisa pedir. A gente pede pro júnior. O sênior pede pro júnior. E essa é a outra coisa que um sênior esperto sabe fazer: delegar e orientar.
Eu sei que um cara é sênior quando ele aprende que eficiência em código tem um limite. Às vezes, em situações específicas, um júnior pode até fazer um código melhor e mais rápido que um sênior. Mas o sênior esperto é o cara que consegue pegar dois júniors do seu lado, e com as orientações certas, eleva o resultado desses júniors mais próximo do que se esperaria de um pleno. Ou seja, o sênior de verdade sabe escalar horizontalmente. E quanto ele sabe fazer isso é quando chegamos no famigerado conceito do desenvolvedor 10X.
Tem duas formas de se encontrar um desenvolvedor 10 X, em situações técnicas especiais, onde estamos falando de um sênior especialista, o cara que consegue criar um novo protocolo de rede, um novo garbage collector, um novo classloader, numa situação técnica incomum pra maioria das empresas, e sozinho, com pouco código até, faz de conta, consegue eliminar o uso de 90 máquinas das 100 que você precisava antes. Normalmente você precisa de escala e situações especiais pra ter essa oportunidade, por isso você não vê todo dia.
Mas mais comum é o caso do sênior que escala horizontalmente, e consegue fazer sei lá, 5 júniors performarem como 5 plenos. Eu disse no começo que pra mim um junior, um pleno ou um sênior são capazes de entregar a mesma qualidade de código, a diferença é o tempo que eles vão levar, proporcional à inexperiência. Se o sênior, com 2 tentativas consegue achar a melhor solução, o júnior precisaria testar 20 jeitos diferentes, porque ele nunca fez antes. Mas se o sênior ajuda ele a eliminar as 18 opções que ele já sabe que não funcionam, o júnior consegue focar só nas 2 que que tem mais chances de funcionar, e o resultado vai ser ordens de grandeza melhor.
Muita gente pergunta sobre a especialização. Eu não considero isso algo fácil de escolher, especialmente no começo. Ao longo do tempo, depois que você deixa de ser júnior e passa algum tempo como mid-level, acho que naturalmente você vai indo pra uma direção ou pra outra. Alguns simplesmente não tem capacidade de orientar os outros, mas se tiver a sorte de encontrar um ambiente que precise de especialistas, ele pode dar certo assim também. Mas como eu disse antes, a maioria dos lugares fora do 1% não tem tantos problemas nessa escala pra serem resolvidos, algo que exija alguém desenhar uma nova linguagem por exemplo. Sendo prático, na maioria dos lugares, o ganho maior vem da escalabilidade horizontal.
Não significa virar um gerente, não é delegar 100% do seu trabalho, é orientar, é fazer parte do código e delegar o restante, é ser alguém que consegue mostrar em código uma prova de conceito ou um modelo pra seguir. É o perfil de alguém que naturalmente viraria o que hoje se chama de tech lead ou líder técnico, que tem a visão do que precisa ser feito e com isso vai delegando e encaixando as peças, testando, pesquisando e orientando os demais.
Mas existem outras categorias e alguns anti-patterns aqui. Você precisa ter muito cuidado pra não se tornar um cavaleiro solitário, o cara que trabalha sozinho, que não aguenta ouvir críticas, que não muda de posição e toma decisões erradas e se recusa a aceitar que tomou decisões erradas. Esse tipo rapidamente vai entrar no time do Go Horse. E dependendo do tipo de empresa que entrar, especialmente nas pequenas onde não tem ninguém muito melhor, vai virar o herói e o vilão ao mesmo tempo, consertando os bugs que ele mesmo criou. E vou dizer que existem centenas nessa posição.
Outra categoria tão ruim quanto. Em empresas que crescem muito rápido, particularmente tech startups, é muito fácil um procrastinador se esconder. Como os processos mudam toda hora, a estratégia muda toda hora, é até difícil pra equipe notar que um dos membros está se escondendo ou mesmo sabotando. Alguns podem até notar, mas como as prioridades mudam toda hora, ninguém quer nem discutir. E como é muito comum a atitude clichê do "não vamos procurar culpados", é um excelente ambiente pros maus profissionais se esconderem e até se tornarem bem sucedidos, especialmente se for o tipo que fala bem. Ele passa rapidamente nos ranks de programação e consegue encontrar uma oportunidade de liderança onde não precisa codar, e como ele mesmo não tem parâmetro técnico pra medir as pessoas, ele vai medir pelos parâmetros errados do tipo, se ele se dá bem com a pessoa ou não. E assim a qualidade técnica de uma empresa que não muito tempo atrás era até boa apesar do caos, rapidamente se torna ruim.
Pra fechar a cagação de regra, por isso eu falo pra esquecer metodologias, processos, métricas e tudo mais no começo. Dado tudo que eu falei, se tem uma recomendação que eu faria primeiro a qualquer empresa, de qualquer tamanho, é que nenhum código deve ser imune à revisão, não importa de quem seja. Todo código deve ser revisado por alguém da equipe, de preferência mais de uma. Todo júnior precisa que alguém aponte o que ele fez de errado, o mais rápido possível. Todo sênior precisa se acostumar a orientar os outros e revisar o código é o primeiro passo. E pra escalar não tem nada melhor que pressão peer to peer, todo mundo olhando todo mundo. Se isso for rotina, fica muito fácil pra equipe inteira notar muito rápido quem está entregando código, em qual qualidade e com que frequência, e não deixar os problemas graves se acumularem a níveis ingerenciáveis.
E daí basta ser consenso que ninguém quer trabalhar do lado de alguém que está fugindo de entregar o que devia e está bloqueando e atrapalhando a equipe inteira, porque ninguém gosta de toda hora ter que ficar consertando o erro dos outros, nem de estar num ambiente com pessoas ruins. Portanto, antes de qualquer tipo de ritual, qualquer tipo de métrica, simplesmente institucionalize a revisão de código geral. A regra é simples: quem fez o código não pode mergear ela na master. Coisas como falta de testes, gambiarras e falta de cuidado em geral começam a aparecer bem mais rápido.
Ahh Eu sei que já ficou bem longo, mas eu preciso conectar com outro parâmetro que eu acho importante. Eu mencionei mercado, eu falei sobre os cursos de faculdade, os níveis de experiência mas não falei sobre o contexto, mas prometo que vai ser rápido. Entenda o seguinte: toda tecnologia tem um ciclo de adoção, e pra variar é outra curva em S. Toda adoção tende a começar devagar, se ela consegue pular o penhasco dos early adopters, ela vai entrar na early majority e começa a acelerar rápido. Aqui já ficou óbvio e você começa a correr pra não ficar pra trás. Uma hora ela atinge um pico de adoção e a partir daí o crescimento acelerado pára e vai indo bem mais devagar e em alguns casos começa a decair.
Neste exato momento tem tecnologias que já estão no fim da curva, e costumam ser as mais populares que você acha que ainda vai durar muito tempo. Mas quando já tem dezenas de cursos, eventos, posts, e todo mundo fala nela é porque ela já passou do early majority e virou mainstream. Pode já estar no fim do Late Majority. Quem sempre vai ganhar mais é quem souber “surfar” como eu vivo dizendo. É quem pega pelo menos no final do early adopter e salta pro early majority já tendo experiência. Enquanto todo mundo tá começando a aprender, você já aprendeu e já sabe usar então você é quem tem mais valor no mercado nesse momento. No pico da curva é quando cada nova pessoa entrando vai valendo menos e menos, e uma hora a curva inverte, e se você cometer o erro de entrar em negação e ficar defendendo tecnologia em curva invertida, vai ser que nem quem defendia Blackberry ou Windows Mobile em 2011. Quem saltou e pegou o early adopter de iPhone em 2009 e aprendeu Objective-C se deu muito bem porque o pico foi entre 2010 e 2014, desde então a curva desacelerou já.
No mundo ideal você sempre gostaria de ser o especialista de alguma coisa antes dela chegar no pico de adoção. No mundo real é difícil de adivinhar quais vão ser as tecnologias da próxima curva. Então eu pessoalmente sempre gostei de ser pelo menos um pleno na tecnologia que entrou em early majority e early adopter em algumas que estão no início da curva. E repetindo isso a cada nova curva. Daí se uma das que eu escolhi aprender, com sorte, entrou no early majority e eu já sei, posso surfar nela de novo. E a que eu era pleno, com sorte, ainda existe e agora eu sou sênior nela. E agora não posso descansar, preciso ver quais vão ser as próximas. São ciclos que duram cerca de 10 anos, então de 5 em 5 preciso ver alguma coisa. Eu aprendi Objective-C em 2010 por exemplo, e nessa época eu era pelo menos um pleno em Ruby, que estava no pico da sua curva.
O grande segredo óbvio é que você nunca vai ser totalmente pleno e nem totalmente senior. Você pode ser sênior de uma coisa, mas junior em outra. E isso vai variando ao longo do tempo. Aposte todas as fichas na coisa errada e você vai ser expert de uma tecnologia morta, que pode não significar muito em pouco tempo. Se isso tá parecendo mercado financeiro, você não tá muito errado.
Se você for conservador demais, vai deixar tudo na poupança e não mexer, achando que tá seguro, sem saber que você cresce menos que a inflação e ao longo do tempo na verdade você está deteriorando e cada vez valendo menos e menos e com cada vez menos chances de recuperaçao. Se você for hypeiro demais e colocar tudo numa ação arriscada ou IPO, já já você pode perder tudo ou muito mais que gostaria. Se quiser balancear você vai ter uma parte em renda fixa, outra parte em ações, e uma pequena parte em opções. Eu penso em carreira mais ou menos da mesma forma. Não é uma escolha fixa, por isso eu mesmo não me considero expert em nada, minha estratégia foi ir diversificando, meio que por acidente, meio chutando, mas aos poucos fui acertando.
Sobre ganhar mais ou menos, você vai ter que aprender a negociar. Pra negociar você tem que ter alguma coisa a oferecer. E repetindo pela última vez: o que você “acha” que você vale não é o preço final, é o preço inicial da negociação. Tudo na vida é negociável, só que se você não tem disposição pra tomar uma decisão, alguém vai decidir por você. Entenderam porque eu disse que não terceirizar decisões é a coisa mais importante? E também como em finanças, existem decisões que vão dar certo e existem decisões que vão dar errado e você vai ter algum prejuízo. Use de aprendizado e não erre na mesma coisa de novo.
Tem muito mais coisas que eu posso falar sobre esses temas mas acho que por hoje já é bastante coisa. Se vocês tem experiências diferentes e outras perspectivas, não deixem de mandar nos comentários abaixo. Se curtiram o vídeo mandem um joinha, não deixem de assinar o canal e clicar no sininho pra não perder os próximos episódios. A gente se vê, até mais.