Muitos de vocês estão no mercado há muitos anos. E muitos de vocês presenciaram grande parte das transições das ferramentas de desenvolvimento e, também, das filosofias de desenvolvimento em todos esses anos. Eu estou no mercado desde 2005 ou 2006, mas já programava em VBA desde 2004. Já trabalhei com o Visual Studio 2003, 2005, 2008, 2010, 2012, 2013 e 2015. Quem sabe agora trabalhe com o VS 17 e com o Visual Studio Code também. Como os programadores .NET relativamente experientes, gostaria dar alguns conselhos de carreira e um pouco de histórico para quem está chegando na área ou ainda tem pouca experiência.
>>Leitura Recomendada:
Planejando a carreira em programação
Resumo do que aconteceu em .NET até 2011 ou 2012
Em 2005, quando comecei, as coisas eram muito diferentes de hoje! Eu, por acaso, tinha uma assinatura MSDN Ultimate da HP e consegui baixar o VS2005 assim que tinha saído, no fim daquele ano.
Eu não tinha consciência ainda, mas eles tinham acabado de lançar o .NET 2.0. Naquele momento tínhamos generics, e um ASP.NET 2.0 com várias melhorias, um Gridview com mais poderes, componentes legais para trabalhar com datasets tipados e outras coisas infernais que para nós era muito bonito de ver à primeira vista.
As revistas de programação bradavam aos quatro ventos como era lindo e fácil fazer software corporativo de qualidade. E todos começaram a bolar, com o tempo, frameworks para gerar telas, frameworks para validação e tudo mais. Uma zona que durou bastante tempo até — uns 5 anos.
Acabei indo para uma empresinha trabalhar num ERP que usava o VS 2003 e usava VB.NET.
Um senhor arquiteto resolveu enfiar um Web Service na solução, criando uma camada intermediária completamente desnecessária.
O projeto webforms chamava o web service (de 8000 linhas), que chamava a “camada de negócios”, que chamava a “camada de acesso a dados”. Uma estupidez que contestei, mas ninguém quis mexer. Ok.
Com o tempo trabalhei em projetos mais legais com o famigerado Windows CE, trabalhei com projetos sem ser web e, com a chegada do .NET 3.5, lambda expressions e LINQ para a linguagem, o nível de qualidade do código que produzíamos começou a subir.
No VS 2008, que trouxe o .NET 3.5, as coisas em .NET começaram a ficar vibrantes. Parecia que a Microsoft estava investindo nas ferramentas de desenvolvimento como nunca.
Aquela sensação de novidade e mudança começava a aflorar e assim como eu, muita gente falava apaixonadamente do .NET. As revistas de programação idem!
O Windows Vista prometia ser um bom SO. O Windows Workflow Foundation parecia ser a revolução dos workflows. O Windows Presentation Foundation certamente mudaria para sempre como fazer uma UI e o XAML era (e ainda é!) algo magnífico.
E o que falar do Windows Communication Foundation com seu poder de melhorar comunicações entre componentes? Todos os problemas de comunicação corporativa estariam resolvidos para sempre!!!
>>Leitura Recomendada:
A importância da comunicação em Projetos de TI
Pessoalmente me senti muito animado e feliz com .NET. Eu estudei e tirei certificações e me sentia conhecedor de grande parte do .NET. Eu até comparava a evolução do Java e, naquela época, .NET havia dado um salto muito grande.
Eu também me sentia feliz com a minha escolha de tecnologia porque me sentia capaz de entregar qualquer tipo de projeto corporativo que me pedissem. Mesmo com pouco tempo de profissão, eu tinha conseguido alcançar um grande conhecimento não só de C#, como de SQL Server.
Enquanto eu estava super feliz com tudo isso, um movimento quieto e fulminante começava a acontecer.
Um movimento denominado “Alt.net” começou a fomentar o desenvolvimento de ferramentas open source alternativas ao que a Microsoft carinhosamente nos oferecia.
E, claro, nós caçoávamos disso tudo. Quem é que vai querer um software de código aberto ruim feito por nerds amadores?
Usar o que a Microsoft oferecia era a escolha mais acertada a se fazer. E, com esse mindset, eu e o mercado fomos vítimas de decisões erradas da Microsoft, do nosso comodismo e muito mais.
No período de 2005 a 2010 tudo mudou. Uma das mudanças fundamentais que complicou muito a nossa vida foi a questão da incorporação do Ajax.
Isso acabou virando um inferno, porque todos os clientes queriam que a página “atualizasse sem piscar”. A abordagem com Webforms, padrão na época, era nebulosa e o uso de frameworks que suportavam bem o Ajax era um grande diferencial.
Além disso, para piorar mais a nossa vida e acabar com a zona de conforto, os smartphones apareceram e acabaram mudando drasticamente como pensávamos o software.
Outra coisa que também piorou foi a multiplicação dos browsers e a guerra de compatibilidade que tivemos e talvez ainda tenhamos que suportar, mesmo atualmente.
O mercado mundial acabou entrando em choque quando certos aplicativos começaram a dominar o mundo usando como porta de entrada as aplicações mobile. Projetos impensáveis como o Twitter, Facebook e similares acabaram explodindo nesse curto espaço de 5 a 7 anos.
De repente, os programadores .NET começaram a ficar para trás. O mercado mudou drasticamente com a mobilidade e o aumento da flexibilidade dos modelos de negócio.
E, além disso, começou uma nova corrida pelo ouro: a busca pelo enriquecimento rápido ao criar apps para celular.
Startups começaram a surgir da noite pro dia, tentando chegar primeiro em mercados totalmente novos.
E no fim, pouquíssima gente se arriscou a considerar .NET para trabalhar nesses projetos. Começamos a ficar para trás, sem sequer saber o que era JavaScript.
O simples ato de montar algo como REST era muito complexo no WCF. O fato de rodar .NET apenas no Windows Server era um impeditivo muito grande para negócios que precisavam escalar cada vez mais.
Isso sem falar na lentidão e péssima arquitetura do ASP.NET WebForms, que praticamente inviabilizava qualquer investimento em aplicações web mobile.
.NET deixou de ser uma opção para startups e, só agora, poderemos ter uma possível reviravolta nesse cenário, com os atuais investimentos na plataforma .NET para se tornar algo que rode em qualquer servidor de forma rápida e com um arsenal de linguagens poderoso.
>> Leitura Recomendada:
Leia nosso artigo sobre programar em equipe
O .NET de 2010 para cá
Quem trabalha com .NET e ficou no seu mundinho de aplicações corporativas, sem observar o que acontecia fora do feudo da Microsoft, não percebeu que o desenvolvimento de aplicações novas e modernas acabou ficando ainda mais complexo.
O crescente uso de JSON para trafegar dados pela rede acabou estimulando ainda mais o uso de JavaScript para criar projetos web.
O ritmo do crescimento de JavaScript acabou levando à criação de frameworks em Javascript e, também, ao surgimento de servidores web que usam JavaScript para responder a requests.
Ou seja, a indústria se moveu para sair do padrão e para buscar cada vez mais possibilidade de diminuir a complexidade de subir novas aplicações. Mais uma vez o programador .NET clássico ficou para trás.
Para compensar o atraso da plataforma .NET em relação ao mundo real, a Microsoft absorveu pessoas e ideias da comunidade open source para revolucionar suas ferramentas de desenvolvimento: foi criado o ASP.NET MVC.
Essa mudança foi um verdadeiro choque na comunidade. Ninguém estava preparado para largar o WebForms. Todo mundo já tinha algum truque para lidar com ajax. Todo mundo já tinha milhares de sistemas prontos usando WebForms.
Muitas empresas estavam estruturadas para trabalhar dessa forma. A aderência acabou demorando demais. Pouca gente quis sair da zona de conforto e se arriscar a trabalhar com MVC e Javascript.
Houve uma certa batalha do “bem contra o mal” para convencer a maioria dos devs a considerar MVC. E os mais resistentes acabaram sendo forçados a migrar e estudar MVC porque os requisitos das aplicações começaram a ficar mais complexos. Nessa década, uma aplicação simples acabou ficando muito mais complexa do que em 2007, por exemplo.
No meio dessa explosão tecnológica da década de 2010, surgiu algo que veio para mudar em definitivo como pensamos em software.
A computação em nuvem surgiu como uma resposta à demanda crescente de startups que precisavam subir suas aplicações em servidores que não fossem absurdamente caros.
Outros requerimentos como: facilidade de aumentar ou reduzir o poder de processamento de acordo com a demanda, crescimento proporcional dos custos, oferecimento de serviços auxiliares como bancos de dados, armazenamento de arquivos e muito mais, levaram a importância da nuvem a um patamar inimaginável em 2010 e óbvio na atualidade.
Vale notar que a criação da nuvem da Amazon e da Microsoft começou em 2006 ou 2007, mas até a década de 2010 era uma opção hipster de infra.
Outro movimento que ajudou a deixar o ecossistema .NET ainda mais obsoleto no mercado de startups (e de inovação como um todo) foi a crescente adoção de bancos de dados não-relacionais.
A onda de bancos nosql revolucionou para sempre a forma como os novos aplicativos começaram a ser pensados.
Ao adotar um banco de dados ideal para cada tipo de workload, os usuários conseguiram velocidades de desenvolvimento maiores e maior facilidade em resolver certos tipos de problemas como: armazenar e consultar documentos em formato JSON, buscar em grandes tabelas e representar grafos de dados. O cara que só consegue trabalhar com o projetinho web, webservice e banco SQL Server definitivamente está muito obsoleto em 2019.
>> Leitura Recomendada:
XML vs JSON: Entenda como fazer a melhor escolha
Quais caminhos tomar de agora em diante?
Infelizmente, antes tínhamos condições de entregar sozinhos sistemas razoáveis com uma equipe relativamente pequena.
Tínhamos praticamente um time de design e um time de back-end e era o suficiente para conseguir entregar grande parte dos projetos. Tanto no front-end quanto no back-end, as decisões já estavam tomadas e não era preciso pensar muito.
A complexidade dos projetos aumentou de tal forma que hoje é virtualmente impossível entregar tudo o que entregávamos testado em vários dispositivos, com layout responsivo, com boa performance, com um back-end elástico, escalável e com alta disponibilidade — nos prazos que estávamos acostumados e com os recursos humanos que usualmente tínhamos à disposição.
Tampouco podemos considerar que o back-end é uma coisa genérica e adaptável a cada necessidade — isto é, não seja um arquiteto de “pastinha”.
Não seja o cara que se considera arquiteto só porque sabe organizar uma solution do Visual Studio e sabe em qual projeto se coloca o repositório.
Não seja o cara que sai criando IoC e interfaces sem pensar. Não seja o cara que acha que dá pra colocar “DDD” num projeto. Não seja esse cara. Os métodos construtivos que reinaram na década passada estão cada vez mais obsoletos e vêm mudando a cada ano.
Quero deixar aqui quatorze conselhos e dicas de estudos para vocês pensarem e fico totalmente aberto a críticas e sugestões. Vamos lá:
Um
Em front-end, as Single-Page Apps vão continuar crescendo. Projetos em ASP.NET MVC serão preteridos e provavelmente não serão mais uma opção.
Estude Angular, React ou Vue.js. Mas principalmente, estude os princípios por trás destas tecnologias.
Se quiser seguir em front-end, invista também em estudos sobre como criar UI mais atraentes e funcionais, UX mais agradáveis e sempre, sempre aprenda com o que é feito lá fora.
Há muitas fontes de estudo no Medium que versam sobre ideias de UI e bons exemplos de UX. É claro que você não será capaz de fazer tudo sozinho, mas ter este conhecimento e bom gosto ajuda muito a manter o emprego e a entregar um projeto melhor.
>>Leitura Recomendada:
Boas práticas de programação em PHP
Dois
Não caia nessa de virar programador full-stack. Pouca gente tem capacidade de fazer um back-end e um front-end de qualidade máxima.
Levando em conta todos os processos de engenharia do front-end (é, tem que minificar JS, testes, builds, processar SASS / LESS, bla bla bla) e back-end (testes, builds, conteineres, concorrência, elasticidade, bla bla bla).
Além disso, cada “lado” do software está cada vez mais especializado — um cara que só mexe com front-end não consegue mais absorver as novidades do próprio ramo! Imagina ter que conhecer tudo o que acontece de novo no back-end! Não dá tempo!
Você até pode ser esse cara, mas não considere que existam caras assim disponíveis no mercado — não anuncie vagas deste tipo. Não tente economizar contratando um cara que faça dois papéis.
>>Leitura Recomendada:
Os profissionais de TI mais valiosos no mercado.
Três
Não se esqueça que desenvolvimento mobile ainda é uma área com boa quantidade de vagas de qualidade.
Conhecer Xamarin abre muitas portas, embora a quantidade enorme de gente que está indo para essa área tenda a forçar os salários para baixo em pouco tempo.
Não sei se vale a pena investir em programação mobile nativa, mas se você investir nisso, na ordem Android — iOS , provavelmente também terá empregos bons por um bom tempo.
Há quem diga que o modelo atual de aplicativos está fadado ao fracasso e que simplesmente as pessoas esquecerão dos apps já em 2020. Então analise com cautela essa opção.
>>Leitura Recomendada:
Leia nosso artigo com dicas para se tornar em programadores .NET especialista
Quatro
Projetos Web API crescerão ainda mais e acabarão se tornando simplesmente fornecedoras de JSON para as telas ou outros sistemas. Ou seja, novos projetos com WCF deverão diminuir bastante.
Cinco
Sempre houve e sempre haverá espaço para aplicações desktop. Embora tenha havido um grande e infundado desespero para colocar “tudo na web”, o desktop ainda é um bom lugar para prover experiências de usuário cativantes.
>>Leitura Recomendada:
Que tal ler o artigo que fizemos sobre as melhores linguagens de programações pro dev iniciante aprender?
Seis
.NET Core se tornará (na verdade já é!) uma realidade e será uma grande opção para começar startups.
E mais: a plataforma .NET provavelmente absorverá muitas pessoas de outras stacks que buscam trabalhar com programação funcional.
O uso de F# no .NET Core já é uma realidade, e assim será cada vez mais. O C#, mais moderno, terá um apelo maior ainda. Startups certamente passarão a considerar o .NET Core como uma grande primeira opção.
Espera-se que, com isso, o ecossistema .NET amadureça e tenha ainda mais ferramentas bacanas para se criar aplicações sérias na nuvem e principalmente, amadureça a ponto de ser fácil e rápido começar novas aplicações em .NET.
Outras stacks já possuem várias formas práticas de iniciar e configurar projetos novos. Espera-se também que novas IDEs usem o espaço que hoje é praticamente exclusivo do Visual Studio.
Com um ecossistema mais vibrante e com menores custos de entrada, .NET finalmente chegará ao mainstream de tecnologias usadas pra novos projetos.
Sete
Pense bem: vocês hospedará uma aplicação web no IIS e Windows Server nos próximos 2 ou 3 anos, caso tenha a opção de hospedar com menores custos no Linux?
Provavelmente, quem estiver criando algo novo hoje acabará utilizando o .NET Core para a grande parte das tarefas.
Portanto, além de conhecer o Windows, é importante estudar melhor o Linux. Além disso, espera-se que a performance das apps em Linux ainda seja melhor que a performance em Windows.
Oito
Não deixe de conhecer TDD. Não deixe de praticar TDD. Não deixe de sentir alegria com metodologias “test-first”. Esse é o princípio fundamental de todo software que entrega valor para o cliente e vai para produção.
>>Leitura Recomendada:
Validação de dados usando Fluent Validation
Nove
As empresas estão acordando para o alto custo de licenças de banco de dados. O SQL Server ainda é muito caro.
Considere ao menos conhecer PostgreSQL, que é um banco de dados excelente que inclusive pode substituir o MongoDB e SQL Server em muitos (todos?) casos de uso.
Não deixe de conhecer e, pelo menos brincar, com uma opção de banco orientado a documentos (pode ser o MongoDB mesmo) e outra orientada a grafos (dê uma boa olhada em Neo4j!). Depois, conheça as ofertas da Amazon e do Azure.
Dez
Hoje, conhecer uma “nuvem” como AWS ou Azure é praticamente tão obrigatório quanto ter 3o. colegial completo.
Recomendo fortemente que vocês estudem e treinem com pelo menos uma destas opções.
Certificações nessa área são muito bem vistas e aumentarão cada vez a empregabilidade, tanto como programadores .NET quanto como arquiteto de software / sistemas.
Considere arquiteturas que tenham “densidade” cada vez maior, ou seja, que contenham praticamente só o serviço de hosting da aplicação ou, mesmo, de partes da aplicação.
Antes se colocava a VM inteira na nuvem. Hoje em dia dificilmente essa é a melhor opção.
Hoje se fala mais em serviços que apenas hospedam a sua API ou app Web, em funções dentro de topologias “serverless” e por aí vai. De forma análoga, há maiores facilidades em criar clusters na nuvem hoje em dia.
Onze
Outra vertente que cresce cada mais é DevOps. Essa excelente opção de carreira basicamente trata de como automatizar os processos e workflows ligados à gestão de código-fonte, testes, builds, releases, publicações, containers e muito mais.
Ter conhecimento em DevOps requer um conhecimento razoável de desenvolvimento de software e pode ser um passo interessante para quem já é experiente e quer crescer sem necessariamente virar coordenador ou gerente.
DevOps é uma área que também tem desafios, como migrar clientes de um legado para uma nova situação ou produto , por exemplo.
Podemos pensar que um trabalho de consultoria de DevOps envolva a migração de bases do TFS para Git + estabelecimento de um workflow automatizado para se chegar, um dia, a publicação contínua de código.
A função de DevOps é ainda mais importante quando se trata de interagir com serviços da nuvem, já que certas automações adicionais são necessárias para ajudar a otimizar custos e recursos disponíveis.
Arquitetos e líderes de equipe também se beneficiarão ao conhecer técnicas de DevOps e ferramentas de gestão como VSTS ou Jira.
Doze
O back-end hoje em dia mudou radicalmente. Não temos mais como falar em começar projetos grandes sem ao menos considerar que o mesmo monolito poderia ser quebrado em partes menores.
Um arquitetura que utiliza microserviços bem divididos tende a ser bem sucedida no longo prazo, desde que certas dificuldades como: comunicação assíncrona e tratativa de situações, falta de conectividade ou resposta de outros serviços consigam ser resolvidas.
Isso leva a que você…
Conheça e absorva conceitos importantes de programação funcional.
Uma arquitetura orientada a microserviços tende a favorecer construções funcionais, ou seja, com o máximo de dados imutáveis, com o mínimo de estado e, eventualmente, usando modelos de dados que favoreçam eventos imutáveis, onde o estado atual do sistema seja o resultado do acúmulo de eventos imutáveis anteriores.
Isso leva que você…
Considere uma arquitetura que trabalhe usando mensageria e filas.
Uma arquitetura que utilize uma fila ou um banco que guarde eventos do sistema é bem mais complexa e impõe que os usuários aceitem que a consistência dos dados não é imediata.
Há sempre um tempo x para colocar o evento numa fila, e mais um tempo y para que alguém pegue o evento da fila e coloque os dados no banco de dados para que a aplicação possa ler o resultado do comando.
Mas o uso desse tipo de arquitetura acabou alavancando o crescimento de muitas startups e, combinando-se arquitetura de microserviços + filas +bancos de dados específicos e otimizados para cada dada situação, os programadores .NET e analistas tiveram muito mais capacidade de resolver problemas em produção e de dar fluidez ao trabalho de múltiplas equipes.
Conceitos-chave como: imutabilidade, fluxo de dados unidirecional (cada componente só se preocupa com enviar dados para o próximo componente, sem deixar o componente prévio aguardando uma resposta), código funcional (com pouco ou nenhum estado mutável) são fundamentais também para criar sistemas escaláveis que possam rodar na nuvem em qualquer número de máquinas e em clusters.
Em resumo, considere fazer CQRS com o banco EventStore do Greg Young e/ou com Apache Kafka e crie aplicações que se aproveitem de algo como Actor Model (dá uma olhada no Akka.net) para propiciar este modelo escalável e concorrente na nuvem.
Treze
Indo no sentido de arquiteturas imutáveis, tanto em código quanto em infra, considere também utilizar containers para colocar o seu produto no ar.
Os sistemas de integração contínua podem gerar automaticamente uma imagem Docker da versão da aplicação com todas referências e configurações necessárias.
Isso acaba tornando mais previsível a forma que a aplicação é publicada, facilitando a busca por erros.
Na prática, no mundo ideal, os programadores .NET tem uma imagem para testar, uma hipótese que pode ser exercitada simplesmente replicando os comandos que estão na fila ou no Event Store de produção.
Magnífico. Com este grau de agilidade, o custo de manter algo em produção é significativamente menor.
Quatorze
Por fim, você pode também se especializar em novas áreas de conhecimento como Machine Learning, Análise de Dados (fazer a ingestão de logs é fácil — difícil é tirar conclusões de 10 TB de dados), Processamento de Dados em tempo real (quem é que não gostaria de impedir uma fraude durante sua execução?), Bots (robôs que automatizam tarefas de forma quase-humana) e muito mais. Há um universo de possibilidades que não se encerram no mundo web ou mobile.
Vá além
Como um outro conselho, além de estudar programação funcional (que te tornará um programador muito melhor), recomendo conhecer o que há de bom em outras stacks.
Há um site muito bom para você fazer buscas para descobrir quem usa uma dada tecnologia e quanto uma tecnologia é usada.
Se você só trabalhou com .NET, conheça um pouco do mundo Java, do mundo Ruby e, principalmente, estude quais stacks mais aparecem em sites de empregos dos principais mercados.
Essas stacks chegarão em breve (com atraso de 5 a 10 anos) ao Brasil e vale a pena se antecipar. Analise o que o InfoQ coloca, analise principalmente o que é falado no InfoQ de Londres ou Nova York e sempre tente acompanhar sites que buscam contar histórias bem sucedidas de ideias inovadoras.
E se você não quiser estudar essas coisas todas?
Pra ser bem sincero, não tem problema. Uma das funções mais promissoras do mundo de desenvolvimento de software em geral é manter sistemas legados!
Você pode encostar em alguma empresa, arrumar um emprego CLT e viver fazendo pequenas melhorias e modificações em softwares existentes. E assim, tocando a vida por anos a fio, poderá se aposentar em paz.
Não é errado, não é pecado e essa opção de vida é tão válida quanto as opções feitas por “aventureiros” que mudam de emprego o tempo todo.
E claro, hoje sempre tem aquela vaga para o programador Delphi, VB6 que paga bem. Um dia também terá aquela vaga bacana para o programador Web Forms que entende tudo do AjaxControlToolkit.
Eu conheci muitos caras assim no mercado. O problema dessa estratégia é que muitas vezes a empresa acaba tomando decisões que acabam tirando o sossego de Programadores .NET acomodados.
Às vezes você tá curtindo seu quinto ano de boa, quando de repente, a empresa vai à falência. Ou então, a empresa é comprada por outra empresa e, no merge, você acaba rodando.
Esse mundo de fusões e aquisições é um inferno. E, nessa crise, as chances de cortes na área de TI são muito maiores do que em qualquer outra época da história recente do país.
Assim como conheci muita gente que optou por fazer “carreira” numa empresa, vi muita gente que se deu mal com essa estratégia e simplesmente ficou mais do que 12 meses procurando um emprego.
E já recebi muitos currículos, com currículos que resumiam uma vida de 5 anos em apenas 1 ou 2 parágrafos. Quando isso acontece é sempre triste e o cara se arrepende de ter se limitado tanto no antigo emprego.
Se assim mesmo você optar pela estratégia do “sossego tecnológico”, precisará obrigatoriamente ter conhecimento muito forte e relevante na área de negócios.
Por exemplo, seria valoroso você ter experiência com folha de pagamento, fiscal, contábil, PDV e etc. Essas áreas, para quem conhece o business, são garantias de emprego mesmo em tempo de crise.
São áreas importantes, “cross”, necessárias em várias empresas e precisa de algum estudo contínuo para se adaptar às mudanças / exigências legais que sempre surgem e que ajudam a manter o emprego…
Por último, caso você não queria ser um bom técnico e também não queira mexer em software legado para sempre (é preciso ter muito estômago para conseguir suportar um código complexo desses), você pode investir na carreira de gestão.
Coordenar projetos grandes, lidar com times, gerenciar expectativas dos stakeholders, utilizar princípios ágeis e “lean” para criar software com equipes focadas — tudo isso faz sentido para quem busca ser um gestor capaz de entregar software moderno daqui para frente.
Não é fácil encontrar gestores com a cabeça aberta para novas metodologias de tecnologias, com tenacidade suficiente para fomentar essas mudanças para a empresa com calma.
Talvez faça muito sentido buscar certificações em gestão de projetos, MBAs e etc.
Com o passar do tempo, nossa experiência acaba sendo o ativo mais importante que temos e essa experiência pode ser fundamental para entregar projetos cada vez mais complexos.
Focar em ser um bom gestor é uma estratégia de carreira que, pessoalmente, considero arriscada, já que há muita oferta de gestores no mercado e você pode ser trocado como quem troca de carro — basta um projeto crítico começar a dar errado ou o cliente não gostar de você.
Mas mesmo assim é uma opção que quando bem-sucedida, pode dar muito certo financeiramente. De forma análoga, ser um bom analista de negócio é uma opção que também pode dar certo e gerar uma boa renda e continuidade de demanda por tempo indeterminado.
Pensamentos finais
Com o tempo, muita gente acaba perdendo a energia para ser um programador atualizadíssimo e produtivo com as novas tecnologias, ainda mais agora que o leque de tecnologias aumentou brutalmente e já não dá mais para ficar atualizado com tudo o que surge diariamente.
Cedo ou tarde, todos nós vamos acabar sucumbindo e ficando para trás em algum momento. Você, que assim como eu, foi enganado e convencido a entrar na área de TI, já se ligou em 2016/2017 que essa área é uma grande furada.
Eu estudo quase todos os dias desde antes de começar na área. Eu estudei muito mais que um médico ou engenheiro com mais de 10 anos de carreira.
Nós, da área de TI, acabamos virando reféns do que geralmente mais gostávamos quando moleques: lidar com coisas novas e exercitar nossa criatividade.
Não há como ter paz e parar no tempo, pois sempre haverá algo a mais para ter que estudar e se atualizar — e não fazê-lo é se expor a riscos.
O que eu gosto de pensar é que aprender uma coisa nova e esse fluxo constante de inovação na nossa área é a cor do nosso mundo.
Ninguém mais no mercado tem a sorte de ter acesso a tantas novidades quanto nós, da área de TI. Pode até ser estressante. Pode ser muito estressante mesmo! Mas o que nos colocou nessa área, no fim das contas, é o que nos mata e o que nos faz viver: a mudança.
Espero que tenham gostado. Abraços, Mário.
Artigo original retirado do medium e repostado com autorização do autor
Crie um perfil na GeekHunter e receba propostas alinhadas ao seu perfil. São mais de 1000 vagas abertas, inclusive Vagas .NET.
