O que os cursos de computação não ensinam?

Por que uma profissão que parece ser nossa vocação natural e que já nos fez virar noites por puro preciosismo uma dia começa a dar sinais de que consumiu nosso combustível além da reserva?

Depois de uns dez anos de profissão, às vezes antes disso, muita gente com quem eu trabalho (ou trabalhei) diz alguma coisa parecida com “não foi bem pra isso que eu estudei tanto!”.

Para tentar descobrir alguns dos motivos que levam a esse desencanto, precisamos voltar lá atrás, quando sentimos orgulho de codificar (com sucesso) nosso primeiro IF. Se recuperarmos aquele sentimento de satisfação e avançarmos no tempo, vamos perceber que todas as revistas e livros que lemos, os cursos técnicos, as graduações e pós-graduações que cursamos, os mentores que escutamos… todos nos prepararam magnificamente para os desafios técnicos que teríamos. Mas poucos abordaram algumas pedreiras que enfrentamos no dia a dia da profissão.

E o que foi que eles não nos disseram?

“Você nem sempre fará o que quer”

Ou quase nunca.

Sabe aquele parse de linguagem que fica martelando na sua cabeça durante meses? Aquela aplicação mobile que os usuários poderiam usar para coletar dados no tablet? Aquele refactoring que facilitaria enormemente as manutenções futuras? Pois é. “Agora não dá”. E não dá porque você está num projeto que se comprometeu a alterar a base de cálculo de impostos. E só.

Muitas vezes olhamos o escopo de um projeto e percebemos que daria para fazer algo muito maior; usando tecnologia de ponta; agregando valor… Mas o cliente não quer pagar, o prazo não comporta, a instalação não tem a infraestrutura necessária. Fica pra próxima!

Quando você estudou J2EE, Swift ou Go tudo era possível. Mas agora você está trabalhando numa seguradora que roda VB6 com SQL Server, meu irmão! E nesse momento eles esperam que você localize programas e stored procedures, especifique as alterações, altere, teste, homologue com o usuário, implante e dê suporte pós-implantação. E tudo isso para sexta-feira.

Claro, você pode trocar de emprego e ir para aquela start up promissora que ainda não gerou muita renda, mas onde eles deixam beber cerveja durante o expediente e jogar ping-pong depois do almoço. Se você já está trabalhando numa dessas empresas e está feliz com o que faz e com o que ganha, parabéns. Mas se não for esse o seu caso, continue lendo esse artigo.

“O ótimo é inimigo do bom”

Se você teve a sorte de não ouvir essa frase de seu cliente ou de seu gerente, prepare-se: você ouvirá.

Esse dogma já foi usado para justificar verdadeiras atrocidades em sistemas. Ele tem uma pele de cordeiro que dá a entender que temos que ser flexíveis e resilientes, que não podemos ser tecnicamente puristas num mundo acelerado e competitivo, que não devemos aumentar os riscos do projeto sem uma justificativa clara e indiscutível. E isso realmente faz todo sentido.

Mas nas sublinhas também está o “precisamos reduzir escopo pra diminuir o preço”;  “precisamos fazer em metade do tempo”; “temos que pensar numa solução paliativa”.

Veja bem: não estou aqui satanizando o lado business da Tecnologia da Informação. Eu mesmo já usei esses e outros paradigmas várias vezes, com diferentes equipes, em diversos projetos. Mas nenhum professor te falou sobre isso quando estava te ensinando UML.

“A tecnologia avança mais rápido do que as empresas têm capacidade (ou vontade) de absorver”

Está aí o COBOL para confirmar. E sabe por quê? Porque para acabar com milhões de linha de código COBOL e reescrever tudo em PHP e Java as empresas teriam que:

• Comprar novo hardware que garantisse a mesma confiabilidade
• Comprar novo software básico que também garantisse a mesma confiabilidade
• Treinar a equipe atual e/ou contratar novos profissionais
• Adquirir pacotes e/ou re-desenvolver todos os sistemas legados
• Migrar dados definitivos e temporários para a nova plataforma, prevendo um plano de roll-out que garantisse a transição gradual sem afetar a operação da empresa
• Congelar as manutenções evolutivas por um longo período, ou duplicar os esforços para garantir que mudanças inadiáveis fossem implementadas no sistema antigo e no sistema novo, ao mesmo tempo.
• Definir novas políticas e processos para operação do sistema: backup, manutenção de bases de dados, segurança, auditoria, recuperação de desastres etc.
• Treinar todos os usuários da corporação para operação dos novos sistemas.

Caro.

É bacana e importante ler sobre o que está surgindo sobre Blue Mix e computação cognitiva. Mas esteja preparado para ter que dominar a tela preta com letra verde do TSO e absorver (rapidamente) as diferenças entre a programação estruturada e a orientação a objetos. Seu aumento de salário pode depender disso.

“Algumas vezes, você adotará as piores práticas do mercado”

Lá pelas fases finais de um projeto você descobrirá que o usuário “esqueceu” de pedir aquela funcionalidade essencial, sem a qual o projeto não vai servir para nada. Você fará uma análise de impacto, apresentará um novo cronograma e uma nova estimativa de esforço. Mas não vai dar: “nesse caso, precisamos minimizar os impactos, porque o negócio do cliente depende disso etc. etc. etc.”.

Nessa hora, meu camarada, você vai adotar as “piores práticas do mercado”; tudo aquilo que você sempre combateu: especificar as alterações “de boca” para  os colegas, alterar parte dos programas e deixar os outros para depois da implantação, criar aquele campo que desnormaliza a base de dados, alterar o código sem revisar as especificações (e as linhas de comentário) e por aí vai.

É duro. Mas o que nos transforma num profissional respeitado e procurado não é só nosso conhecimento técnico, mas nossa capacidade de resolver problemas. E nem sempre conseguiremos resolvê-los pelo caminho mais limpo.

“A carreira Y passa por uma porta estreita”

Essa talvez seja a verdade mais ignorada em toda a literatura da TI.

Você ama programar. Você sonha com modelos de dados e camadas de software. Você está (relativamente) feliz com o status e com a responsabilidade que a empresa confia a você. Finalmente você é um técnico respeitado!

Mas um dia, você perceberá que seu colega de faculdade assumiu uma função gerencial e está ganhando mais, mandando mais, participando de reuniões com gente importante… Negar é pior! Não adiante dizer que isso é inveja. Não é inveja; é cobiça. E a cobiça é constitutiva da formação humana.

E você é humano! Você também gostaria de um salário maior, da salinha, do carro da empresa, da secretária, do contato direto com o CEO, das viagens internacionais… Mas percebeu que nenhum técnico que você conhece “chegou lá”.

É nessa hora que vão te oferecer um cargo gerencial. No começo você vai aceitar, pois a mudança de papel é pequena; você ainda poderá usar seu conhecimento técnico nos primeiros desafios que surgirão; você será respeitado por sua equipe porque, afinal, você é um técnico!

Mas não se iluda. Com o tempo, vão te oferecer novas promoções e, pouco a pouco, você vai se afastar daquilo que realmente gosta de fazer. Quando se der conta, estará 10 anos sem ver uma linha de código; 10 anos sem logar num ambiente de desenvolvimento; seu skill mais valorizado será sua fluência em Excel, PowerPoint e Project.

E aí você vai perguntar: “para que eu estudei tanto?”.

Conclusão

Existem muitas outras situações parecidas que enfrentamos na vida como ela é. Isso não torna a computação menos fascinante. Pelo contrário, provavelmente para aqueles que realmente gostam de (verdadeiros) desafios esse cenário faça toda a diferença. A capacidade de pensar rápido no meio do caos diferencia os bons dos medianos.

Talvez o que falte nos cursos, nas revistas e nos livros seja uma abordagem que não coloque técnicos e gerentes – tecnologia e negócios – como “nós” e “eles”. Quando algumas das questões que sugeri aqui forem debatidas em sala de aula, quem sabe não apareça uma metodologia que não precise ser retalhada para se adequar aos projetos de verdade?

E você? Lembra de alguma outra situação que o deixa frustrado na profissão?