Hoje eu vou fazer uma crítica sobre a carência de bons profissionais de TI no mercado. Eu vou fazer uma reflexão pessoal de por que é que eu acredito que essa carência existe como um todo e por que eu nunca tive esse problema de falta de bons programadores nas minhas empresas. Essa é uma opinião sincera minha e que, obviamente, não é direcionada a ninguém em específico.
Antes de começar a entrar de fato no tema, eu quero dar um contexto para a minha explicação. A primeira coisa que a gente tem que entender é a evolução do mercado de tecnologia. Eu passei os últimos 20 anos nesse mercado e acompanhei efetivamente essas mudanças, então eu quero destacar alguns pontos que eu considero relevantes desse processo. Quando eu comecei, lá nos anos 2000, a gente ainda estava no início da popularização da internet no Brasil, meu primeiro computador tinha uma conexão discada de 56Kbps, era muito lenta e tinha muito pouco conteúdo relacionado a programação. Na época, as linguagens mais utilizadas eram Delphi e C++, o processo de aprendizado de programação era demorado, complicado, precisava entender inglês porque os materiais não eram traduzidos, não tinha YouTube, você ficava limitado normalmente a livros, artigos e alguns poucos sites relevantes. Outro fator é que os hardwares da época eram muito inferiores em processamento, em nível gráfico e tudo mais, logo, qualquer compilação ou interpretação levava muito tempo para ser processada. Acabava que, pelo menos no meu caso, eu preferia digitar bastantes linhas de código e entender “na mão” aquele processo para, na hora de eu debugar um programa, esse processo ser o mais rápido possível. Na prática, a galera “das antigas”, que tem mais tempo de casa, acabou estudando e se aprofundando mais na linguagem e no contexto, por questões de limitações da época, tanto de documentação quanto de tecnologia. Hoje o meu celular é mais rápido que o meu primeiro computador, então se eu for debugar um programa no celular é muito mais rápido que naquele computador, um Pentium 166. Nesse contexto dos anos 2000, foram criados vários softwares justamente para tentar antecipar e simplificar algumas coisas, como é o caso do Delphi.
A molecada que está começando a aprender a programar hoje acha que o Angular e o React são puta inovações da tecnologia, mas componentização é uma coisa de 20 anos atrás. O Delphi 7 já tinha o princípio de componentes. Outro detalhe, naquela época já tinha uma IDE Gráfica para “arrastar e soltar” as coisas, só que todos os bons programas eram feitos para Desktop, para Windows, para Mac, não eram feitos para browser. Quando teve o boom da internet é que começou a portabilização de softwares para navegadores. A primeira grande ideia que a Microsoft teve foi criar um componente chamado ActiveX, cuja premissa principal era pegar um programa que rodava no Windows e acessar esse software pelo browser, pelo Internet Explorer. Então era possível, por exemplo, acessar o Word instalado na sua máquina através de um servidor IIS [Microsoft Internet Information Server] ativando o ActiveX e você conseguia acessar os arquivos que estavam na sua máquina. O ActiveX, a priori, parecia ser uma excelente ideia, mas acabou virando um negócio maluco porque os softwares instalados no Windows podem ser idôneos, como um Photoshop, um Word, ou ele pode ser um vírus, um worm, um Man-in-the-Middle, ele pode ser uma série de falhas de segurança. Você podia acessar um site que tinha ActiveX e baixar um trojan sem querer, que ia pegar o controle da sua máquina, então a Microsoft acabou tendo que desativar o ActiveX. Então a gente começou um processo para portabilizar de fato os softwares para sistemas web.
Hoje, a gente programa para web da mesma forma que nos anos 2000, escrevendo o código, na mão, esse conceito de componentização do Angular, do React, do Vue, é relativamente recente para internet, porque o JavaScript precisou passar por uma evolução gradual para que fosse possível criar essas ferramentas. Seria impossível criar o Angular ou o Vue com o JavaScript dos anos 2000, porque ele não tinha classes, não tinha async/await, não tinha uma série de coisas. Depois, em 2013 e 2015, a gente teve as assembléia do ECMAScript, que mexeram na estrutura do JavaScript, para torná-lo uma linguagem mais robusta, capaz de comportar componentes. Eu sempre falo do ECMAScript 2015 porque, para mim, foi onde o jogo mudou, há “apenas” 7 anos a gente teve essa reunião, com as maiores empresas do mundo, onde foram definidos os rumos da internet. Com a popularização da internet, era inevitável a portabilização desses softwares locais, desenvolvidos em Delphi, em C++, para o ambiente web do navegador, e o JavaScript como linguagem foi a escolha mais lógica, e toda a estrutura precisou ser mexida para conseguir suportar toda essa evolução, essa necessidade mercadológica.
Quando a gente volta a escrever código na mão para desenvolver para web, a gente tem uma série de problemas. Primeiro: não é mais um sistema que vai rodar numa máquina específica, agora precisa de um cliente e um servidor, e a gente segrega entre back-end e front-end o que, antes, era uma coisa só. Normalmente quando se desenvolvia um sistema qualquer em Delphi, o próprio programador fazia o layout, às vezes ficava uma porcaria de feio, mas funcionava muito bem. Agora, na internet, a gente tem uma figura chamada front-end, que a princípio era um designer que aprendeu HTML e CSS e foi evoluindo e se transformando num “monstrinho”. Do CSS3 em diante surgiram ferramentas, frameworks, e tudo mais, veio Bootstrap, Tailwind, etc., e virou uma gárgula o negócio. Hoje é dez vezes pior do que no passado, porque uma parte da lógica, que antes era processada no servidor, passou para os frameworks e os devs front-end, que teoricamente eram designers que sabiam HTML e CSS, tiveram a necessidade de aprender a programar para poder mexer num framework desses. Criou-se um cenário esquisito, onde pessoas que se classificam como front-end, mas não sabem escrever um “if” dentro do código e ficam extremamente dependentes do back-ends para poder tornar o layout usável. Isso eu falo por experiência própria, eu tive front-end que não sabia escrever um “if” e o tempo todo precisava ficar trocando figurinha com os back-end.
O back-end também foi segregado para só ficar cuidando de API. Eu, quando comecei a mexer com internet, tinha que saber fazer de tudo. No máximo um designer me mandava um layout em .PSD ou .PNG e eu que precisava transformar aquilo num site utilizável, fazer o HTML e o CSS. Essa divisão de agora, no meu ponto de vista, é equivocada. Normalmente o designer quer cuidar só do layout, ele não quer programar, se ele tem que escrever React, Vue, ele fica meio perdido nessa história. Aí criaram esse termo bizarro chamado full-stack, que é o cara que é back-end e front-end ao mesmo tempo. Na minha época, isso se chamava programador, web designer. Full-stack é o novo termo para web designer. Eu vejo sempre vagas descritas como “precisamos de profissionais de front-end, que saibam React”. O cara que é bom dev quando vê uma vaga dessas, bate até uma depressão de pensar em ficar o tempo todo mexendo com CSS, honestamente falando.
Eu sou mais que um full-stack, eu faço tudo, desde configuração do servidor, back-end, front-end, app, site, banco de dados. Acho que o termo é full-cycle, que é o cara que faz tudo dentro do ecossistema da empresa. Tudo que precisar, eu faço, porque eu aprendi a ser assim, a mexer em tudo, a fuçar e, se eu não sei, eu aprendo. Quando eu vejo uma vaga de front-end React, ou qualquer coisa do tipo, eu penso que, se eu estivesse numa posição de precisar de uma vaga dessas, eu me sentiria muito desconcertado de ter que ficar o tempo todo só mexendo com front-end. Eu ia querer fazer de tudo, mas aí existe essa divisão dentro da empresa que front-end não pode mexer no back-end, e vice-versa. Que porra é essa, mano! Eu sou programador e eu deveria poder mexer em qualquer coisa que fosse, essa é a minha opinião. Se o back-end também quiser dar pitaco dentro do front-end, qual é o problema disso? Tanto que na minha antiga empresa, o Vigia de Preço, todos os programadores tinham liberdade de mexer em qualquer parte do código. Deu bug no app, quem vai resolver? Quem estiver disponível. O gerenciamento era feito no GitHub, então se alguém fazia algum tipo de modificação, o cara responsável pelo app só precisava gerenciar os merges dos commits. Eu era responsável pelo GitHub da API, então eu que aprovava os requests para API. A gente tinha pessoas qualificadas, com a capacidade de poder aprovar o merge em qualquer repositório. Se o cara reparou um bug que não é da área principal dele, excelente!
No meu entendimento, não é que faltam profissionais, as empresas é não estão sabendo lidar com esses profissionais, e eu vou explicar o porquê. De novo, no meu entendimento fazer essa segregação de back-end e front-end já é uma puta furada, você tem que querer contratar um programador e ponto. Outro ponto: esse programador vai fazer uma função específica ou ele vai ser generalista? Eu vejo os programadores iniciaram já desenvolvendo apps ou sites muito segmentados em relação a frameworks. “Eu sou programador Vue e a vaga é para React.” Entenda uma coisa, para migrar do React pro Vue, ou vice-versa, é simples. Se você é um bom programador, você consegue fazer aplicações em Vue, em Flutter, em Angular, a plataforma não é o problema. Uma coisa ou outra você vai ter que se adaptar, reaprender algumas coisas por questões semânticas, mas a lógica funciona do mesmo jeito. Se alguém deixa de se candidatar a uma vaga por causa de framework, não é só uma limitação que a empresa está colocando, mas também que os profissionais procurando vaga segregam, por uma questão pessoal. “Eu não quero trabalhar com React porque eu só gosto do Angular.” Seu gosto pessoal você usa nos seus projetos pessoais, se a empresa optou por usar Vue, você vai aprender a escrever em Vue. Você pode até tentar questionar, tentar mudar, mas a empresa não tem que se adaptar ao seu gosto pessoal, você que tem que se adaptar às necessidades e requerimentos da empresa.
Quando eu vou contratar alguém, normalmente eu faço uma analise generalista, a não ser que precise necessariamente saber uma linguagem especifica. Exemplo, se eu estou procurando um desenvolvedor de Unity, eu preciso que o cara escreva o código em C#. Agora, se eu estou precisando de alguém para trabalhar com React, eu posso criar uma vaga para JavaScript ou TypeScript, eu não necessariamente preciso expor que é somente React. Qual é a diferença de eu contratar um cara que manja de TypeScript, mas não tem tanto conhecimento de React? Ele vai ter que dar uma estudada básica na documentação e pronto, o cara consegue trabalhar com React ou qualquer outro framework. Sinceramente, mesmo com experiência, se eu fico um mês sem mexer no Vue, no Angular, ou no React, e eu já trabalhei nos três frameworks, eu não vou lembrar como tudo é feito. Esses frameworks são modificados o tempo todo, alterados e melhorados, então é uma idiotice achar que o cara é especialista sênior em React ou em Vue. A nossa memória nem consegue comportar quantidade de coisas que essas linguagens tem, a gente precisa recorrer o tempo todo às documentações, então é totalmente desnecessário isso ser um requerimento de vaga, no meu ponto de vista. Se o cara é um bom programador, ele vai dar um jeito de se virar, resolver o problema e entregar o que precisa ser entregue. Entendemos esse ponto?
Vamos passar para outro problema: Os programadores não querem saber as regrar do jogo da sua empresa, isso é uma premissa básica. Praticamente 99% dos programadores querem receber a demanda de uma determinada tarefa, executá-la, entregá-la e foda-se. Se a sua empresa tem um modelo complexo de gerenciamento e tal e coisa e não sei o que mais, o programador não quer saber. Ele quer que você, como gestor, crie todo um briefing, faça o fluxograma para ele, a documentação e passe para ele simplesmente pegar aquele conceito e transformar em código. Entender o business da empresa não é uma tarefa que 99% dos profissionais vão estar dispostos a fazer. Eu tinha uma empresa de comparação de preço, a maior parte dos programadores que passaram pela minha empresa não queria saber o que era um comparador ou como ele funcionava internamente, eles queriam simplesmente a demanda: mexer no layout, mexer numa função que estava dando problema, etc. Eles resolviam o problema e foda-se, eles não queriam saber como funcionava a parte comercial do processo, por exemplo. E a maior parte dos programadores realmente não quer saber. Se você consegue profissionais que se interessem, que estudam o seu business, excelente, você achou um cara raro. Hoje, a diferenciação que eu faço de um excelente profissional e de um profissional na média, é o cara que se dedica a entender o negócio da empresa. Quanto você entende como é que funcionam as bases estruturais daquele modelo de negócio, você evita ruídos de entendimento, quando alguém te pede para fazer alguma coisa, você não precisa de um interlocutor para explicar como aquilo tem que funcionar, nem precisa de uma equipe de QA para poder testar se aquela implementação foi feita de forma adequada. Então, quando um profissional entende do negócio, o desenvolvimento daquele sistema é muito mais fluído do que normalmente seria se ele não entendesse nada do sistema.
Partindo dessa premissa, desse contexto gigantesco que eu dei para poder falar sobre o tema, por que é que o mercado tem uma deficiência de bons profissionais para ocupar as vagar em aberto? Onde estão os devs bons de verdade, que desenvolvem sistemas ultra complexos e sabem uma porrada de linguagens, e tudo mais? Empresas brasileiras, entendam o seguinte, vocês nunca vão conseguir competir por esses profissionais. Sabe por quê? Porque esses caras vão estar numa empresa grande, uma Microsoft, um Google, um Facebook da vida, tirando 10 mil dólares por mês de salário inicial. Você, como uma empresa brasileira, acha honestamente que vai conseguir competir com essa faixa salarial? A gente está falando de um salário de quase 60 mil Reais. Você não vai conseguir competir. Se o cara bom, isso falando de um profissional top de linha, e ele não está trabalhando para uma empresa de fora, ganhando em dólar ou em Euro, ele está empreendendo, fazendo suas próprias empresas, criando seus próprios softwares e, de novo, ganhando muito mais dinheiro do que você pode oferecer de salário para ele.
Vou dar um exemplo: Quando a minha empresa foi comprada, eu fui passar por um processo de RH durante a incorporação. A menina do RH me perguntou quanto eu achava que era um salário adequado para eu trabalhar na empresa. Quando eu falei que nenhum salário era adequado para mim dentro da empresa, ela questionou o porquê, e eu precisei explicar que eu tirava 200 mil Reais por mês, quase 10x mais do que o diretor da empresa. Consegue entender isso? Nenhum salário que me oferecessem ai ser maior do que o que eu ganhava. Não tinha como me oferecerem um salário maior do que eu ganhava. Eu tenho diversas fontes de renda e só fui trabalhar lá porque a empresa foi comprada, senão eu nunca trabalharia ali. Só trabalhando numa empresa nos EUA para ganhar o que normalmente eu ganharia, em torno de 15 a 20 mil dólares, que é um salário que nenhuma empresa brasileira vai me pagar nunca. Eu só consigo fazer esse mesmo valor aqui no Brasil empreendendo, criando minhas próprias soluções, as minhas próprias empresas. Então olha que situação de merda que o RH passa.
Obviamente a gente está falando de profissionais top de linha. O que sobra aqui no Brasil é uma galera que não está tão preparada tecnicamente, comercialmente, que não tem um bom relacionamento interpessoal, não tem case, não passou por diversas experiências, não tem tantos anos de mercado. Inclusive o tempo de programador não quer dizer necessariamente que você seja um cara sênior ou mais que isso. Para mim, essas classificações de junior, pleno e sênior são as camadas inicias da cadeia, tem muita coisa acima disso. Você tem que ser um bom gestor de produto, gestor de equipe, até você chegar a um título de CTO tem uma escada muito grande, mas é meio negligenciado isso. Aqui no Brasil, pelo menos as estruturas mais comum que eu vi é, você chega até certo ponto e passa a tech lead, que já parte para um lado mais gerencial, depois vai para gestor, até virar diretor. Existem muitas outras camadas nesse meio, mas cada empresa tem a sua própria forma de classificar o que é cada coisa. Empresas como o Google, por exemplo, separam muito mais por habilidades, exemplo, o cara é muito bom em desenvolvimento de um produto especifico, ou de uma área especifica, ou de um processo específico, então eles separam o programador por especialidade e não propriamente por senioridade, que é uma questão muito subjetiva de se analisar. Eu me considero muito superior ao que se classifica no mercado como sênior, não existe uma classificação propriamente dita para o cargo que eu ocupo. Não é um cargo de CTO porque eu faço muito mais do que um CTO normalmente faria, então é muito difícil fazer uma analise de cargos complexos, de pessoas que estão num nível muito acima. Quando você dá sorte de conseguir pegar um bom profissional, com um salário relativamente baixo, é porque a auto-estima do cara é baixa, ele não tem bom relacionamento interpessoal, ele não se arrisca, ele tem medo. E aí você vai ter outro tipo de problema, porque ele é bom tecnicamente, mas não vai conseguir evoluir como pessoa, como líder, dentro da corporação por outros fatores. Já tive esses casos, também, de profissionais excelentes tecnicamente, mas que em relação ao relacionamento interpessoal dentro da equipe eram um lixo. Ele ficava isolado lá na caverna dele e era isso.
Já que a gente está falando nesse tema, como é que eu consigo trazer excelentes profissionais para trabalhar comigo? Eu poderia até chamar algumas pessoas próximas, que já trabalharam comigo ou que trabalham comigo, para poder dar os 3% deles, a opinião deles com relação ao que fez eles se sentirem atraídos a trabalhar comigo. Claro que cada caso é um caso, mas eu vejo que algumas coisas que são padrão. Primeiro: os projetos que eu faço são sempre muito ambiciosos, grandes, complexos e isso atrai gente boa. Uma coisa é abrir uma empresa de jogos para fazer um joguinho de celular casual, outra coisa é abrir uma empresa de jogos para fazer um MMORPG, entendeu? São níveis de complexidade muito diferentes, então os projetos casuais não atraem tanto quanto os complexos. Gente boa quer coisa complexa, quer desafio. Não é só o dinheiro que vai trazer o cara, você tem que trazer o cara pelo desafio, pela excelência, por estar participando de um projeto muito foda.
Segunda coisa que eu acho extremamente importante é esse profissional perceber que existem outros profissionais tão bons quanto ele, ou melhores, dentro da equipe. Nesse caso, o fato de eu ser um excelente programador faz com que outros programadores se sintam instigados de alguma forma. A gente consegue trocar experiência, não só experiência de programação, mas também experiências profissionais. O fato de eu ser bem sucedido, de ter tido várias empresas, essa experiência de vida que é trocada dentro de uma empresa é muito boa. Além de alimentar seu network, você tem um parâmetro de comparação e isso é excelente. Quando você é o melhor programador da empresa, você fica sendo a referência e tem que ficar meio que atendendo todo mundo ali, resolvendo dúvidas, é um cenário meio enjoado. Agora, se todo mundo é mais ou menos do mesmo nível, isso fica mais pulverizado, então a troca é mais de boa. Fora o cenário de admiração que acaba ocorrendo mutuamente entre bons profissionais. Eu já tive casos que eu tive que demitir o dev, mas eu tenho um imenso respeito pela qualidade com que a pessoa produz os códigos. Para mim, código é uma arte, é como pintar um quadro. Quando o cara é muito bom, por mais que você não goste da linguagem que o cara usa, por mais que você não goste da forma como ele se porta, você entende e vê aquilo como uma espécie de expressão por meio dos códigos. Então existe um respeito mutuo, e eu já tive vários casos assim, que eu respeito o cara profissionalmente porque eu sei que ele é um excelente codificador, é um excelente gestor de produto, é um excelente resolvedor de problemas no geral. Se a sua empresa não tem nenhum profissional que sirva de referência, não tem nenhum produto inovador que seja um chamariz de pessoas boas, e você não está pagando um salário que seja competitivo com as empresas de fora, você só vai ter profissionais medíocres na sua empresa. Essa é a dura realidade. Você só vai atrair gente medíocre, vai ter dificuldade para desenvolver coisas, vai estar o tempo todo trocando de profissionais, então gerar resultados consistentes vai demandar tempo. O que eu faço sozinho em um mês, às vezes uma equipe de dez pessoas vai demorar 6 meses para fazer. Já tive casos assim, de chegar em uma empresa e dar um resultado tão absurdo que a empresa inteira ficou incomodada com a minha presença.
Um questionamento que eu faço para você, que é gestor de empresa de tecnologia: como é que você resolve isso? Porque, honestamente, eu não resolvo.
Eu já falei outras vezes sobre o mercado de TI, especialmente aqui no Brasil. Vou deixar algumas indicações de post sobre o assunto:
O conteúdo deste post foi retirado do vídeo “Carência de profissionais de TI”:
