[Akitando] #29 - O que eu devo estudar? Vou conseguir emprego?

2018 November 27, 17:00 h

Disclaimer: esta série de posts são transcripts diretos dos scripts usados em cada video do canal Akitando. O texto tem erros de português mas é porque estou apenas publicando exatamente como foi usado pra gravar o video, perdoem os errinhos.

Descrição no YouTube

Uma das maiores dúvidas de jovens programadores é sobre que linguagem aprender primeiro. Qual vai ter mais chances de ter emprego e ter mais oportunidades?

Parece que se aprender linguagens novas como Go ou Elixir vão ter menos oportunidades, mas porém parecem ser o futuro. Como conciliar aprender linguagens novas que tem menos mercado ao mesmo tempo que trabalhar com linguagens mais tradicionais como Java?

Vou dar meus 2 centavos de perspectiva nesse assunto.

Links:

AkitaOnRails:

Script

Olá pessoal, Fabio Akita

Quando comecei este canal eu fiquei com uma dúvida. Se eu deveria me focar nas tecnologias mais novas. Fazer vídeos sobre Javascript ou Elixir ou Kubernetes ou algo assim.

O motivo de porque eu não tenho interesse nisso é porque uma rápida procurada no Google vai te dar muito mais informação, em muito mais detalhes, e muito melhor estruturado do que eu poderia tentar fazer neste canal.

Vamos lá, Se você quiser aprender Elixir, o que você deve fazer? Simples, comece no site elixir-lang.org. Ele tem um excelente tutorial para iniciantes, pra começar a aquecer na linguagem.

Dali você pode ir direto pro site The Pragmatic Programmer. Eles tem diversos excelentes livros sobre Elixir como o Programming Elixir. Outra boa editora é a Manning que tem o clássico The Little Elixir & OTP Guidebook. E tem várias outras que você pode procurar. Na real, o próprio google te dá boas primeiras opções. Tente procurar "Best Elixir Books" e eis os primeiros resultados:

Você pode começar aprendendo Elixir, Ecto e Phoenix direto e, como eu expliquei em outro vídeo, quando você aprende os primeiros 20% do conhecimento, você já está produtivo o suficiente pra começar a fazer aplicações. Não se engane, você ainda é um iniciante, mas já dá pra começar. Idealmente você vai aprofundar mais, ler mais sobre a história, ir atrás da origem do Erlang e como é o real funcionamento da Beam VM.

Se quiser ir mais devagar, pode assistir screencasts como os do Daily Drip. Eu aprendi muito com os vídeos do Josh Adams. E, claro, assinar mailing lists como o Elixir Weekly pra se manter atualizado.

Daí você quer colocar a aplicação num servidor. Você vai encontrar diversos tutoriais pra Digital Ocean, pra AWS, pro Heroku e assim por diante. E finalmente, se olhar posts do meu blog de 2015, vai ver todas as minhas explicações detalhadas sobre Elixir. Eu aprendi tudo que eu precisava.

E isso sem contar os inúmeros fóruns de reddit a hackernews com mais centenas de dicas de opiniões a respeito.

Ou seja, é relativamente simples aprender o básico de Elixir pra se tornar produtivo.

Se você ainda tem dúvidas o problema não é falta de material, é preguiça de usar o Google direito e de sentar a bunda na cadeira e começar a estudar sozinho.

A pergunta que a maioria das pessoas tem na cabeça é o imediatismo: mas tem emprego pra isso? Será que vou perder meu tempo e não achar nenhum emprego? E se você começar com essa pergunta toda vez, você está perdendo seu tempo. Porque essa pergunta vale pra Elixir, vale pra Ruby, vale Python, pra qualquer coisa.

Talvez não tenha. Talvez você acabe usando Elixir pra fazer a mesma coisa que faria mais rápido e melhor usando Javascript ou PHP. Talvez você tenha mais opções de emprego se simplesmente aprender C# ou Java.

Agora tudo depende de você. Existem motivos muito objetivos de porque em 2006 eu comecei a evangelizar Ruby mas porque hoje eu não evangelizo Elixir, ou Go, ou Rust. Talvez eu fale sobre isso em outro episódio. Mas vou levantar um ponto: quando eu decidi que ia aprender Ruby E trabalhar com Ruby, havia zero mercado de trabalho no Brasil. Não é um exagero, existia zero empresas usando, existia zero vagas de trabalho, existia zero material em português. Nenhum livro, pequenos fóruns de entusiastas, quase nenhum blog ou site falando a respeito. Esse foi até um dos motivos pra eu ter escolhido Ruby com tanta convicção, embora não tenha sido o motivo principal ;-)

Naquela época eu tinha um emprego muito bom de consultor Java no mundo Enterprise. Eu já ganhava bem pra época, já tinha investido uns 5 anos subindo na carreira de consultor. Mesmo assim eu literalmente joguei tudo fora. Quando eu me coloquei no objetivo do Ruby, eu pedi demissão e comecei do zero.

E calma! Eu não recomendo que ninguém me copie, as circunstâncias foram muito específicas. Eu avaliei com muito cuidado e fiz uma aposta de alto risco. Eu levaria os próximos 10 anos me recuperando, era um plano de longo prazo.

Mas meu ponto é o seguinte: eu decidi aprender Ruby em 2006. Meu primeiro emprego remoto com Ruby foi em 2007. E eu abri minha empresa de Ruby em 2011. Em 2018 minha empresa tem 7 anos, 80 funcionários sendo 75 desenvolvedores não só fazendo Ruby como Javascript, um pouco de Python e até Java eventualmente. Em nenhum momento minha preocupação principal foi ter ou não ter emprego.

Aprender Ruby ou Aprender Elixir não é o objetivo, é só um meio. Se você acha difícil aprender Ruby, Elixir, Go, Javascript ou qualquer coisa assim, esse é o primeiro ponto que você vai ter que melhorar.

A recomendação que eu daria pra um total iniciante, talvez seja não aprender primeiro nenhuma das linguagens novas. Invista seu tempo em Java ou .NET ou mesmo PHP. Nem todo mundo teve a chance de crescer numa capital como São Paulo, Porto Alegre, Recife. Nós temos opções em lugares assim. Mas se tem uma coisa que eu aprendi percorrendo o país inteiro é que nós somos a exceção.

O normal, principalmente em cidades do interior, em estados do Norte como Roraima, Amapá, é não ter nenhuma opção. Alguns poucos conseguem se mudar pras capitais, mas muitos não tem essa opção. Tem filhos. Tem família pra cuidar.

E pior ainda: em alguns lugares do país não existe internet banda larga que permita um trabalho remoto de qualidade. Obrigado pelo seu desserviço à nação Anatel.

É um dos motivos de porque minha empresa abre fora de capitais. Eu deteste falar da minha própria empresa porque sempre vai soar como propaganda, mas considere que eu tenho 11 escritórios e talvez uns 3 ou 4 funcionários em home office até estabelecermos um novo escritório. Em capitais eu tenho São Paulo, Natal, Teresina e Goiânia. Os outros são: Santa Maria e Novo Hamburgo no Rio Grande do Sul, arredores de Criciúma em Santa Catarina, Guarapuava no Paraná, Batatais, Sorocaba e Campinas no estado de São Paulo, arredores de Belo Horizonte, e Anápolis em Goiás.

A constatação mais óbvia: existem pessoas de qualidade em qualquer lugar do país. Um programador de São Paulo não é automaticamente superior a um programador de Teresina. A gente faz o que pode. Mas voltando ao ponto. Eu não faço isso porque sou um divino ser altruísta ou algo assim. Não, eu faço isso porque é lógico: é uma troca voluntária com mútuo benefício.

Voltando ao meu ponto: aprenda Java, aprenda C#, aprenda Javascript ou PHP. Você mora no interior, cidade de 200 mil habitantes, tem uma talvez duas empresas com alguma vaga na área de informática. Talvez seja uma agênciazinha, customizando Wordpress e Magento. Ou alguma instituição pública precisando dar manutenção num sistema velho em .NET. Não importa.

Isso não é pomposo. Não parece divertido. Mas você só pensa assim porque fica assistindo caras como eu falando das maravilhas que empresas de São Francisco usam.

Aqui não é São Francisco ainda. Não faça isso com você. Eu disse num video anterior que nos primeiros 5 anos de carreira acho que nem tinha e eu não participava de eventos, de fóruns, de comunidades, e isso me blindou e evitou que eu perdesse tempo questionando tudo que eu fazia. Questionar só funciona quando você tem alguma experiência. Dos 20 aos 25 eu ainda não tinha. Teria sido um desastre se eu ficasse toda hora correndo atrás do hype. Eu tive a sorte de poder correr atrás só do meu esforço.

Se você se sente mal em entrar numa empresa da sua cidade pra dar manutenção num sistema legado em PHP, você está começando sua carreira em enorme desvantagem, porque você está desperdiçando seu tempo se lamentando. Porque vocês acham que eu não estou fazendo vídeos sobre Elixir mas sobre o ASP que que eu fazia em 2001? Quando eu comecei a aprender Ruby já era 2006, eu já tinha mais de 10 anos de carreira.

Se você vai ficar empacado só no Java velho no sistema legado pra sempre é uma opção sua. Eu não tinha dinheiro na faculdade. Eu não tive dinheiro guardado a maior parte da minha carreira. O que eu fiz? Fiquei culpando a sociedade por não dar chances o suficiente? Não, eu aproveitei cada emprego em que eu entrei, eu fazia o trabalho, mas com o pouco que eu tinha eu comprava livros. Fazia upgrade no meu micro xing ling. Eu tava fazendo ASP em startup onde eu chegava a varar muitas noites e fazia muita hora extra, mas eu chegava em casa e baixava a JDK e Eclipse e treinava. No episódio sobre o Diário de Henry Jones eu disse que escrevi meu livro de Rails em 2006 enquanto eu estava trabalhando como consultor em Java. Eu escrevi em 2 meses nas horas vagas não porque eu era bom, mas porque eu não tinha outra alternativa.

Prática deliberada? O primeiro segredo é não ter ídolos. O segundo segredo é encarar sua vida inteira como um processo deliberado. Por consequência, o terceiro segredo é jogar o jogo do longo prazo. Hoje eu tenho quase 30 anos de carreira. Eu tive a sorte de começar cedo, aprendi a programar aos 12 anos, eu saí da faculdade mais cedo pra entrar no mercado mais cedo, consciente de todas as desvantagens que eu também ia ter fazendo isso, e eu venho sistematicamente compensando os pontos que eu era ruim.

Eu também queria abrir minha própria empresa antes dos 30 anos. Mas eu esperei. Até os 34 anos. Quando você pratica deliberadamente com seriedade, você sabe no que você é bom e no que você é ruim. Aos 30 eu sabia que ainda não era bom.

As histórias que eu estou contando e as que ainda vou contar, não é só pra você: que nasceu em classe média alta numa capital abastada do país com acesso às melhores universidades e opções. Eu conheci pessoas que vieram de situações muito piores do que as minhas e já me superaram. Cada um tem seus problemas, mas alguns tem o mérito de conseguir superar as expectativas.

Voltando ao Elixir, ou ao Go, ou ao Rust. Não foque em ter um emprego. Esse não é o propósito. Aprenda porque é legal aprender, porque você está praticando algo diferente que contribui pro seu banco de conhecimento e experiência, o único bem que ninguém jamais vai conseguir roubar de você. Dinheiro, posses, tudo isso você pode perder, mas conhecimento e experiência você vai ter pra sempre. E pode ser que você nunca use num projeto. Isso não importa.

Ao mesmo tempo, e esse é o primeiro desafio, evolua seu Java, seu C#. .NET em particular, está bacana hoje em dia, depois que a Xamarin foi adquirida pela Microsoft e eles estão migrando do .NET Framework pra .NET Core, que inclusive roda nativamente não só em Linux como smartphones iOS e Android, o pacote está interessante hoje em dia. No mundo Java você sempre tem a encheção da Oracle, mas alternativas como o próprio OpenJDK ou a nova JDK da Azul Systems, baseado em LLVM, e o dialeto Kotlin da Jetbrains, também aumentaram o padrão do jogo.

O mundo PHP não é o mais atraente mas pelo menos com frameworks como Laravel, você tem opções razoáveis.

E mesmo se você se ver obrigado a usar versões mais antigas por causa do legado da sua empresa, não se aflija.

Deixa eu te contar um dos grandes segredos da nossa área: qualquer imbecil consegue começar um projeto novo do zero. Mas só caras realmente bons conseguem melhorar sistemas legados.

A característica mais importante de qualquer profissional não é saber usar bem suas ferramentas, isso é o básico. É a capacidade de absorver o ambiente, entender as limitações desse ambiente, e tomar as melhores decisões o mais rápido possível e executar. Quem consegue fazer isso sempre vai estar na frente do rato de laboratório que sabe escrever Erlang de cabeça mas não consegue avaliar a situação real e toma decisões caras e de pouco resultado prático.

Eu não escolheria isso de propósito, mas considere que qual o melhor lugar pra aprender essas coisas? Num lugar ruim, com gerentes ruins, com clientes e usuários cabeça duras. Aí você tem 2 escolhas: se conformar e só seguir a inércia e ficar no mesmo lugar, ou aprender a escolher e lutar uma pequena batalha de cada vez, não com o objetivo de salvar a empresa ou o produto ou os usuários, mas pra exercitar sua capacidade de lidar com esses problemas. Era o que eu fazia, por isso eu gostava tanto de consultoria apesar do stress. Eu fui forjado em projetos impossíveis.

Mas, pra sobreviver, você precisa começar sabendo usar as ferramentas mais básicas direito. Exercite seu Go, seu Rust, seu Haskell, nas horas vagas. Continue se exercitando sem parar e sem objetivos de curto prazo. Mas domine a ferramenta do seu trabalho. Você só ganha voz pra tomar decisões de verdade no dia que sua competência técnica é reconhecida porque ela é óbvia. Se você precisa explicar, ela ainda não é óbvia.

Deixe eu contar uma pequena história. Em Dezembro de 2002 a Janeiro de 2003 um dos comerciais da minha consultoria disse que me vendeu pra um trabalho pontual numa grande empresa. Ele tinha ouvido falar que eu sabia ASP - e nessa época eu já estava só em Java - mas o cliente tinha um sisteminha super porco que outra consultoria fez em ASP. Era algum tipo de sistema de RH, pra banco de horas extras ou coisa assim, era tosquinho mesmo. Eu acho que comecei dando suporte por e-mail e depois fiquei alguns dias alocado direto no cliente.

Eu cheguei lá e abri o código. Sério, correram lágrimas de sangue quando eu vi. Fazia tempo que eu não via um código que tinha sido tão maltratado. Era praticamente o guantanamo do código. Por exemplo, eles tinham feito componentes COM+ que abriam conexão com banco de dados mas não fechavam, tinha vazamentos pra tudo que é lado, era tudo um linguição da pior espécie, com um monte de SQL misturado no meio do HTML. Acho que ele precisava integrar com o SAP mas nem isso funcionava. Felizmente eu era especialista nisso. Enfim, era um desastre. Mas eu me empolguei porque o cliente falou que antes de mim uma outra consultoria tinha vindo tentar consertar e desistiu. E nada aumenta mais minha motivação do que uma tarefa impossível. Não tem nada que tem mais valor do que um problema que ninguém quer nem consegue resolver. Você tem que aprender a gostar de ter as mãos sujas, enlameadas, se arrastar no pântano, e sair vivo no final.

E tinha outra coisa que me chamou a atenção. Quando estavam me mostrando o usuário do sistema disse que quase tudo funcionava, menos uma funcionalidade que não lembro se era um gerador de relatório ou alguma besteira assim. Essa informação era super importante. Eu disse: repete, é só esse botão aqui, se ele cuspir o que você precisa que é nesse formato x y aqui, pra você tá tudo ok? E ele falou: sim. BINGO

Veja o que é a situação de um consultor: um consultor é um agente externo, nós caímos de para quedas no projeto e na empresa dos outros, pra resolver coisas que ninguém interno sabe resolver, porque senão já teriam resolvido. Nós temos menos conhecimento de tudo, e menos tempo pra resolver o que ninguém conseguiu resolver. É sensacional porque você sempre começa em desvantagem e você é obrigado a fazer mais com menos.

Aquele código era um zumbi ambulante, precisava jogar tudo fora e começar de novo. Reescrever o código todo, eu ia passar os próximos 3 meses lá, fácil. Mas só aquele botão ... eu ajeitei outros bugs críticos ao redor que impediam o sistema de ficar de pé e aí me foquei especificamente naquele maldito botão - nem lembro se era um botão, mas era algo simples nesse nível.

Sei lá, em 1 semana eu consertei. Chamei o usuário e falei pra ele fazer o processo todo. E foi até o fim. HA, um trabalho de 1 mes resolvido antes, e depois que meu concorrente tinha jogado a toalha. Se você nunca passou por isso, passe, não tem nada mais satisfatório do que resolver um problema que outra pessoa disse que não dá pra resolver.

Isso foi em Janeiro de 2003, daí em maio, esse cliente chamou minha consultoria de novo. Os caras gostaram tanto do meu trabalho que decidiram dar a chance da gente participar na RFP ou Request for Proposal deles, que é uma competição entre diversas consultorias. Normalmente só participaria consultoria maior, mas resolveram dar essa chance depois do resultado que eu tinha mostrado. Foram semanas de reunião, eu analisei centenas de páginas de casos de uso, diagramas, que outra consultoria tinha gasto meses escrevendo, escrevi gantt charts, fiz contas, e cheguei numa proposta de trabalho.

Pra vocês verem como isso demora, foi um processo que acho que levou de maio até pelo menos outubro ou novembro. No final eles falaram que ficou caro, me chamaram de última hora pra dizer "cara, a gente quer colocar vocês, mas o concorrente ta propondo bem mais barato e ainda ia trazer um consultor gringo". Eu tinha 26 ou 27 anos, o projeto dependia só de eu dizer sim ou não. Eu disse não, eu já estava no limite e apostar mais baixo que isso era garantia de fracasso. Então depois de meses de análise, perdemos a RFP.

Em janeiro de 2004 eles ligam de novo pra gente. Em resumo, o tal consultor gringo acabou não podendo vir e como isso estava no contrato que venceu, o cliente disse: beleza, vou aceitar o gringo não vir, mas então eu exijo que vocês contratem o japonês da outra consultoria. Ha, satisfação receber esse e-mail da concorrente.

O nome desse cliente era Suzano Bahia Sul Papel e Celulose, o projeto era a implementação SAP do módulo de recursos humanos pra gerenciar os mais de 4000 funcionários que eles tinham na época. Meu sub-projeto era criar todos os aplicativos Web J2EE que iam expor todos os serviços como banco de horas, benefícios e tudo mais que seriam acessíveis diretamente pelo funcionários a partir de totens colocados nas fábricas. Incluindo reescrever aquele sisteminha tosco ASP que eu originalmente consertei.

O projeto era de tempo e custo fechado, mas a minha quarteirização negociamos pra ser de hora aberta ;-) e adivinhem o que aconteceu? Eu montei minha própria equipe e passei os próximos 2 anos mais ou menos trabalhando lá. No final levou o tempo e o custo que eu tinha dito que ia levar na RFP. A outra consultoria que era bem maior estava comprando o projeto pra ter um case. No final todo mundo saiu ganhando.

E é assim que as coisas funcionam: eu não planejei nada disso. Se eu tivesse feito bico, esperneado, reclamado, recusado a fazer o servicinho porcaria em ASP porque eu já era um Javeiro hipster ou qualquer besteira assim, nada disso teria acontecido.

É impossível juntar os pontos no presente. Só no futuro que tudo se conecta. Hoje você pensa, se eu ficar fazendo PHP e ganhando só o salário que eu ganho pelos próximos 10 anos, mesmo com aumentos, eu nunca vou pra frente. Mas isso só vai acontecer se você não fizer nada. É impossível dizer o que você vai fazer daqui 10 anos então não faça essa conta, é inútil, é perda de tempo. Em vez de ficar perdendo tempo com essa indagações inúteis, se prepare. Porque quando a oportunidade chegar, é tarde demais, você precisa estar preparado pra pegar a oportunidade quando ela chega.

Todo mundo reclama que ninguém dá oportunidade. É o contrário, existem muitas oportunidades, mas ou você não está preparado ou você está escolhendo as oportunidades que parecem mais confortáveis pra você. Ah vá, isso é mimimi, especialmente na primeira década da sua carreira, tudo é uma boa oportunidade. E eu já disse isso antes: se não está doendo, você não está treinando o suficiente. Ai, eu não vou evoluir na minha carreira de Java se ficar fazendo esse quebra galho em ASP ... quem diria que isso é o que daria o meu maior projeto em Java até então poucos meses depois?

E vocês? Já foram surpreeendidos no futuro tendo feito coisas no passado que pareciam que não faziam sentido mas em retrospectiva tudo se conectou? Compartilhe com a gente nos comentários abaixo. Se curtiram mandem um joinha, e uma coisa que ia ajudar muito é se vocês ajudassem compartilhando os vídeos do canal pros seus amigos! Não deixem de assinar o canal e clicar no sininho. A gente se vê, até mais!

tags: elixir java .net legado akitando

Comments

comentários deste blog disponibilizados por Disqus