Como se destacar no mercado da programação?

Se você imaginou que dominar profundamente uma tecnologia é o caminho para se destacar no mercado, você está parcialmente correto. O caminho sem dúvida passa por aí, mas existem algumas outras características que podem ser até mais importantes.

O que querem as empresas?

Antes de tudo, vamos deixar claro que estamos falando de “se destacar no mercado”, ou para ficar mais claro, “se destacar nas empresas que contratam programadores”.

É óbvio que você pode criar um aplicativo revolucionário e independente e se tornar um programador famoso e/ou milionário. Nossa indústria tem muitos exemplos assim: Linus Torvalds, Dennis Ritchie, James Gosling, Mark Zuckerberg… e alguns mais antigos, como Grace Hopper, Alan Turing, Bill Gates, John Backus ou Tim Berners-Lee… todos eles escreveram seus nomes na história da tecnologia da informação. E nessa pequena lista certamente cometi muitas injustiças ao esquecer de muitos que tiveram a mesma importância.

Mas enquanto isso não acontece com você, vamos imaginar que seu objetivo inicial seja se tornar um profissional reconhecido e valorizado pelas empresas com as quais venha a trabalhar.

Vamos também, pelo menos por enquanto, esquecer aqueles bordões conhecidos em artigos de aconselhamento profissional. Sim, as empresas querem “alguém que vista a camisa”, que “seja proativo”, que “trabalhe em equipe”; sim, inglês é essencial… Ok, ok, ok… Mas não é disso que estamos falando.

Pense bem: a grande maioria das empresas não quer uma equipe de programadores formada por gênios antissociais em C++ para desenvolver o novo sistema operacional que vai dominar o mercado. Muito menos um time de gente passiva, aguardando que alguém lhes explique passo a passo o que fazer, como fazer e o que estudar. Em outras palavras, as organizações procuram pessoas que estejam no “meio do sino”, entre esses dois extremos, com algumas características em comum.

Solução de problemas

Acredite: poucas coisas são tão desanimadoras para um gerente ou coordenador quanto um analista/programador que faz o seu trabalho direitinho, que entrega as coisas no prazo, é sempre solícito, mas que é incapaz de resolver um problema sozinho sem, a todo momento, precisar da ajuda de um colega mais (ou às vezes até menos) experiente.

Quem vive o dia a dia de TI sabe que nosso trabalho é uma fila eterna de problemas e imprevistos. Podemos montar um cronograma com 3000 linhas, mapear riscos, planejar contingências, desenhar todos os diagramas previstos na História da UML, adotar as melhores práticas de programação de determinada linguagem, pedir para o próprio Steve Wozniak fazer nosso peer review… Mesmo assim, às vésperas da implantação do projeto, descobriremos que a normalização de uma tabela de dados estava errada; ou que a assinatura daquele serviço atende a 98% do sistema, mas os 2% faltantes são essenciais; ou que o usuário tem certeza que falou que precisava de determinada funcionalidade, e que sem ela o projeto não vai servir pra nada…

Nessas horas tão comuns, o que a empresa espera é que a gente contorne a situação; que não deixe essa “contingência” (a palavra certa é outra, mas as empresas adoram um eufemismo) atrapalhar nem o andamento do projeto nem o relacionamento com o cliente. O gerente, o coordenador ou o líder técnico olham pra gente com uma mistura de pavor e esperança, disfarçando o pânico, e esperam aquela sacada sagaz que vai botar o projeto de novo nos trilhos, pelo menos por hoje.

Aí está a primeira chave para quem quer se destacar no mercado: a capacidade de resolver problemas e apresentar sugestões razoáveis. Esse perfil não está necessariamente associado a um profundo conhecimento técnico. Pelo contrário. É justamente a capacidade de manter a calma, enxergar o cenário completo e traçar uma estratégia que dá ao líder da equipe a sensação de que “pode contar com esse cara”.

A hora da verdade

Muitas vezes, as soluções dependem de uma ação completamente diferente daquelas que planejamos para vender e iniciar o projeto. Eu costumo dizer que nessas horas precisamos adotar “as piores práticas” para não deixar o projeto naufragar. É quando vamos incluir aquela informação hard-coded para diminuir a quantidade de programas impactados, ou embutir aquele update que vai aumentar o acoplamento da função, ou usar o polimorfismo para o mal… e assim por diante.

Não precisa parar de ler por aqui! Não estou defendendo a destruição dos conceitos de certo e errado na programação e na análise de sistemas. Estou apenas constatando que, apesar de todos os esforços realizados até hoje para fazer progredir a ciência da computação, ainda vivemos de uma profissão que muitas vezes se parece mais com artesanato do que com engenharia.

É verdade: provavelmente não houve tempo suficiente para levantar e especificar corretamente; possivelmente o usuário não sabe o que quer; eventualmente você até tenha avisado a todos que aquilo ia acontecer… Mas depois que você aproveitar seus cinco minutos de ironia e vingança, inevitavelmente terá que pensar fora da caixa e sugerir uma saída digna.

E profissionais assim são menos comuns do que parece.

Saber aprender

Houve um tempo, não muito distante, em que aprender como codificar determinada instrução, como interpretar uma mensagem de erro ou como usar um certo utilitário dependiam ou da consulta a um colega que tivesse aquela experiência, ou da leitura de um ou mais livros sobre o assunto, ou da pesquisa aos manuais que normalmente estavam trancados em algum lugar.

Hoje, felizmente, a internet capilarizou o conhecimento. É possível aprender quase tudo digitando a frase certa no Google. Existem vídeos no Youtube explicando como fazer um monte de coisas. Naturalmente, algumas fontes são boas, outras ruins; algumas são confiáveis, outras suspeitas. E essa capacidade de localizar rapidamente a informação certa no lugar certo é um diferencial no mercado.

As instituições de ensino já há algum tempo discutem seus projetos pedagógicos em função da evolução da tecnologia. A ideia de que o conhecimento deve ser transferido para o aluno com ar comprimido, “sob pressão”, não é mais unânime, ainda que não se tenha chegado a muitas conclusões sobre o modelo ideal.

O que se sabe, no entanto, é que “ensinar a aprender” é mais eficaz do que apresentar conteúdo e exigir que ele seja lembrado numa prova ou fixado num exercício abstrato.

Mudanças tecnológicas e conceituais cada vez mais rápidas afligem as organizações com a mesma velocidade que nos atingem, com a diferença de que empresas são mais lentas do que nós para absorver essas mudanças.

O programador que se antecipa na aprendizagem de novos conceitos certamente tem uma vantagem competitiva. Mas não podemos nos iludir: sugerir uma solução baseada em computação cognitiva num projeto que pretende alterar o layout da fatura vai fazer você parecer um lunático, não um autodidata pró-ativo.

É preciso que aquilo que aprendemos por conta própria seja útil e aplicável para a empresa e para o projeto em que estamos trabalhando. Guarde seus conhecimentos sobre Blue Mix para o momento certo. Se agora o que você tem que fazer é criar um web service em COBOL, então que seja: saiba onde procurar tutoriais sobre esse assunto, vídeo-aulas que falem sobre isso, artigos que mostrem como fazer, exemplos práticos… Mostre que você entende as necessidades reais da empresa e que ela pode contar com você para agregar valor aos serviços que ela presta.

O Especialista

Dominar a tecnologia “certa” é um grande desafio para qualquer programador. A diversidade de plataformas utilizadas pelas grandes empresas nos obriga a conhecer diferentes sistemas operacionais, linguagens de programação, bancos de dados, gerenciadores de transação, frameworks… Existem anúncios de empregos pedindo um stack que só poderia ser atendido por um departamento de TI, e não por um ser humano.

De seis em seis meses revistas especializadas publicam artigos sobre “a linguagem que vai bombar no ano que vem”, ou “a tecnologia que todo profissional de TI precisa dominar”. A notícia que mais vende é aquela que provoca medo em quem lê.

Mas convenhamos, mesmo para o profissional de TI é impossível dominar tudo o que todo mundo diz que precisa ser dominado. Quando achamos que já estamos bem em Ruby, alguém nos avisa que precisamos aprender Swift e começar tudo de novo.

É óbvio que quanto mais linguagens, bancos e frameworks dominarmos maior será nossa empregabilidade. Mas não podemos esquecer que as novas tecnologias não chegam massivamente às empresas com a mesma velocidade com que são lançadas. Enquanto procuramos na Amazon um livro recém-lançado sobre Goland, Hack ou Rust, nossas empresas estão pensando se migram aquele sisteminha de VB6 para .Net.

Não adianta, portanto, devorar ano após ano novas tecnologias e linguagens de programação e não se tornar sênior em nenhuma delas. E se sênior, no Brasil, é um conceito que se aplica a profissionais que têm “x” anos de experiência, em outros países é aquele cara que, independentemente da idade, domina uma determinada plataforma e se torna referência junto aos colegas e à organização.

Vale muito mais a pena dedicar parte do seu tempo para dominar profundamente a tecnologia adotada pela empresa onde você está trabalhando do que se dedicar exclusivamente às tendências do ano seguinte.

Mas especialização não se refere só a tecnologia. É muito comum que empresas sofram por não ter um técnico que conheça o negócio atendido por determinado sistema. Às vezes temos 15 pessoas na equipe que conhecem Java muito bem, mas ninguém que possa conversar com o usuário, analisar o impacto da solicitação, desenhar e implementar uma solução e planejar os testes no sistema de cobrança. Conhece-se bastante as ferramentas utilizadas, mas domina-se pouco as funcionalidades e as regras de negócio envolvidas na operação.

Que perfil sua empresa tem mais dificuldade para repor? Quando ela precisa contratar, qual plataforma recebe menos currículos? Que aplicações sofrem mais com a falta de especialistas? Esse é o nicho que essa empresa precisa. Você não pretende passar mais muito tempo trabalhando para ela? Ok, então tente descobrir qual é o nicho na empresa para onde você pretende ir.

Conclusão

Resolver problemas, aprender sozinho e tornar-se referência em determinado assunto: esses são os grandes diferenciais no mercado. Existem outros, sem dúvida, mas para aqueles que não querem ser “mais do mesmo”, é essencial correr atrás desses três objetivos.

É importante também saber falar sobre isso. Mais do que um currículo cheio de cursos e certificações, o entrevistador muitas vezes quer ouvir a sua história, de sucessos e derrotas. Chamará mais atenção aquele profissional que conta como ajudou a resolver um grande problema no projeto anterior ou que demonstre conhecimento profundo sobre determinada tecnologia ou determinado ramo de negócio.

É preciso mostrar para seu chefe (ou para o recrutador) que ali, na frente dele, está um profissional com quem ele pode contar quando as coisas ficarem feias. Porque gente que se diz pró-ativo, colaborativo, perfeccionista e que promete vestir a camisa… ah, desses o processo seletivo está sempre cheio.