Outro dia, compartilhamos dois posts que geraram ótimas reações. Um voltado para o público técnico (Somos “Amadores Remunerados”?), outro voltado para o público de gestão (“Transformação digital fica bem mais difícil quando remuneramos o amadorismo“)

Este post contem algumas notas, explicações e ampliações inspiradas nas reações que identificamos.

Nossa disciplina tem um ABC

Estamos realmente preparados para fazer o trabalho que estamos nos propondo a fazer?

Nossa tese era (e continua sendo), que profissionais da área de computação precisam conhecer e valorizar conceitos fundamentais (de computação) para fazer um bom trabalho.

Assim como um escritor precisa saber escrever (embora tenhamos bons corretores ortográficos),  um economista precisa saber somar, subtrair, multiplicar e dividir (embora, no dia a dia utilizem calculadoras e programas de computador para fazer os “cálculos difíceis”), precisamos saber algoritmos, estruturas de dados e entender o mínimo de como o computador funciona.

Muita gente argumentou que estávamos afirmando que todos precisavam saber temas avançados. É exatamente o contrário! [tweet]Não há nada de avançado em entender abstrações, estruturas de dados e os algoritmos clássicos.[/tweet] Houve quem perguntou se estes temas não são apenas para “cientistas” – acreditamos que não!

Qualquer big name vai cobrar exatamente esses fundamentos em suas entrevistas. Todas as big names estão erradas?

DICA: Que tal investir uma parcela, mesmo reduzida do seu tempo para estudar o ABC de nossa área? Garantimos que seu investimento de tempo e dinheiro vai valer a pena.

Sobre Frameworks e bibliotecas

A cada dia se espera mais e mais de TI.

Estamos inseridos em domínios cada vez mais complexos e, para que consigamos atender o mercado, estamos adotando ferramentas de produtividade para escrever código e frameworks (bibliotecas, serviços na nuvem) que resolvem bem problemas conhecidos.

É fundamental que utilizemos estes recursos. Mas, o que temos percebido é que, com muita frequência, esses frameworks são utilizados de forma imprópria porque os “profissionais” não conhecem o ABC.

Outro problema é que há uma pluralidade enorme desses recursos. A maioria resolvendo o mais do mesmo (só que de uma forma ligeiramente diferente). Houve quem disse que nossa “melhor característica” deveria ser “saber aprender”. Eu acrescento “saber selecionar”!

No longo prazo, entendemos que entender as abstrações (desenvolvidas a partir do ABC), ajuda a aprender mais rápido um framework novo ou banco de dados exótico.

Você aprenderá Neo4J bem mais rápido se souber grafos. Seu SQL (LINQ) vai ser muito mais “poderoso” se você souber trabalhar com conjuntos. Você usará TPL com mais tranquilidade se entender sobre processos, semáforos, mutexes. Seu Regex vai ser bem mais performático se você conhecer máquinas de estados.

[tweet]É realmente uma postura profissional programar com base em tentativa e erro?[/tweet]

Sobre atender o cliente

Houve quem disse que nossa classe está atendendo os clientes e que isso é importante. Foi dito que “estamos entregando software”!

Sites que não suportam uma escalada prevista de demanda (como ocorre na black friday); Aplicativos de companhias áreas que não conseguem concluir um check-in e não informam o usuário sobre o que há de errado; Aplicativos bancários que apresentam dados inconsistentes (um de nossos bancos, todos os meses, indica falha para fazer um TED quando este ocorre com sucesso [houve um caso em que fizemos dois TEDs e tivemos que contar com a boa vontade do beneficiário para reaver nosso dinheiro]); Centrais de atendimento que não conseguem dar um bom atendimento porque o “sistema está lento”; Restaurantes que não conseguem “fechar a conta” porque o sistema parou de funcionar (presenciamos isso duas vezes, em dois restaurantes diferentes, em apenas um dia); Aplicativos para gestão de contrato da companhia telefônica que não consegue mostrar meu saldo devedor, nem gerar um boleto para pagamento (obrigando o cliente a contatar o suporte todos os meses).

Estamos mesmo? Honestamente?  Não há mesmo nada de nossa responsabilidade em exemplos como os listados na citação? Eles são raros? Nunca viu acontecer com algo de sua empresa? O problema, nesses casos, foi causado por escolha de frameworks incorretos? Não seria mais assertivo admitir que o problema está nos “detalhes” e os detalhes vem dos fundamentos?

[tweet]A atitude mais “profissional” é mesmo deixar o erro estourar e fazer nosso cliente perder dinheiro para, então, pesquisar ativando círculo virtuoso do aprendizado reativo? [/tweet]

Sobre júnior, pleno e sênior

Nem todos precisam ter o mesmo nível de conhecimento! Concordo! Mas, assim como escrever, somar e multiplicar e dividir é básico. Conceitos de escrita de algoritmos e adoção de estruturas de dados corretas também deveriam ser. Não?

Um júnior deveria ter autonomia para escrever código e saber se ele vai performar bem (analisando a complexidade do algoritmo). Não deveria? Da mesma forma, o júnior precisaria saber que um “IndexOf” em um List de strings vai ser mais lento que um “Contains” em um Set. Não acha? Como o júnior vai saber escolher entre opções que ele nem sabe que existem? No “mundo real”, parece que as pessoas só sabem usar List e Dictionary. Por que será?

NOTA DO ELEMAR: Há muitos anos (mais de 20), eu tinha o desafio de resolver um problema de performance em um produto em que estava trabalhando. Depois de pesquisar horas em livros (internet não era tão rica quanto hoje), achei o que considerava ser uma boa solução.

Quando fui apresentar essa “boa solução” para meu chefe, na época, fui questionado sobre o porquê da minha escolha. Não soube explicar, senão por dizer que havia visto a resposta em um livro. Meu chefe argumentou, sabiamente, que “justificar uma escolha com base em opinião de outros, é perigoso”. Nunca mais esqueci disso!

Um pleno deveria saber escrever uma expressão regular decente (sem copiar do StackOverflow). Não? Deveria saber quando usar um Dictionary ou um Set. Deveria entender se é mesmo necessário dar aquele ToList() depois de uma consulta. Por que nossos códigos ficam tão presos a frameworks e temos tanta dificuldade de fazer substituições?

Um sênior deveria conseguir fazer um uso correto da TPL. Não acha? Um sênior deveria conseguir rodar uma “task” de importação de um arquivo texto sem “estourar a memória” e nem a “janela de tempo de processamento”. Não? Por que isso é dor?

Se sairmos de .NET e irmos trabalhar com Java (e vice-versa), o sênior não deveria virar júnior. Certo?

[tweet]É profissional dedicar nossas carreiras a sermos “programadores de framework”, tão descartáveis quanto eles ficam em períodos cada vez mais curtos?[/tweet]

Sobre faculdades

Houve quem entendesse que estávamos defendendo cursos acadêmicos. Não estávamos! Mas também não estávamos condenando.

Nossa posição é que um plano estruturado de estudos pode te ajudar a aprender mais rápido. Além disso, há gente com muito mais expertise que nós que há muitos anos vem preparando bons materiais para que possamos acelerar nosso aprendizado.

Queiramos ou não, o ABC ainda está bem refletido em parte dos currículos acadêmicos. Não podemos ignorar isso. Por outro lado, cabe a nós, de mercado, tentar aplicar o que aprendemos além de “passar na prova”

Sobre rótulos e humildade

Leia novamente a seção “Sobre júnior, pleno e sênior”.

Como você definiria o “profissional” que está no mercado sem conseguir cumprir bem aqueles requisitos?

Entendemos que a palavra “amador” talvez tenha te perturbado. Desculpe-nos!

ANALOGIA SIMPLES: Lembre daquela pessoa no caixa da padaria que usa a calculadora para tudo, por ter dificuldade com as operações fundamentais.

Quando ela precisar usar “juros compostos”, primeiro vai precisar descobrir o que é isso (ou lembrar, afinal deve ter aprendido esse conceito sem importância na escola. Mas, por não usar no dia a dia, escolheu esquecer [afinal, o cérebro humano é limitado]). Então vai precisar aprender que botões apertar… enquanto a fila cresce (ou a fila na posição do caixa anda, e a pessoa na operação vai “empatar fila” em outro lugar – sempre com muita humildade e boas intenções).

Permita-nos ser mais humildes e mais “inclusivos”:

[tweet]REVISÃO: Precisamos de programadores que saibam os conceitos fundamentais de sua disciplina. Os riscos são grandes demais para que sejamos APENAS uma classe egocêntrica de “profissionais de framework” remunerados.[/tweet]