Como é trabalhar com um programador experiente

Argumentei com meus programadores seniores que seria mais fácil trabalhar com um programador experiente porque pensei que poderia facilmente ensinar a ele o que sei. Mas, infelizmente, não é o caso. Esse cara com quem trabalhei já tinha uma prática em mente que ele seguiria, a menos que sua mente lhe dissesse o contrário.

Mas nunca imaginei que trabalhar com um programador experiente me daria tanta dor de cabeça. Aqui está o porquê:

1. Ele começa a codificar sem analisar o problema. Pela simples razão de que definir o comportamento durante a análise custa vinte segundos, enquanto corrigi-lo no código é exponencialmente mais longo.
2. Ele reclama do código legado e quer “refazê-lo do zero”. Infelizmente, os iniciantes não podem se relacionar com a condição passada que criou o código legado e muitas vezes perdem a importância de “simplesmente funcionar” em uma empresa.
3. Ele não comenta o código e usa nomes sem sentido para as variáveis. Embora eu seja adepto do código autodescritivo, certos comportamentos complexos só podem ser bem explicados.
4. Ele pratica redundância em bancos de dados. Infelizmente, muitas vezes isso se deve à análise redutiva, afetando a integridade do projeto.
5. Ele sempre quer usar a mesma linguagem/tecnologia/estrutura. Cada aplicação é diferente e os pré-requisitos devem ser identificados antes de iniciar.
6. Ele sempre quer usar a linguagem/tecnologia mais “in” do momento. Especialmente para projetos de longo prazo e de grande porte, o apoio de uma comunidade bem aparada pode ser crucial na escolha das ferramentas de trabalho.
7. Ele introduz dependências entre componentes de diferentes módulos. Erro um pouco menos trivial que os anteriores, mas terrível quando você precisa fazer alterações e nada funciona mais.
8. Ele nega ter cometido um erro. É um instinto que alguns iniciantes podem ter que salvar a cara. Particularmente prejudicial em uma equipe quando um problema se transforma em uma “caça às bruxas” que mina a confiança e a eficácia dos desenvolvedores.
9. Ele não testa o código , nem entende porque deveria “perder tempo” com testes. Além disso , escrever código sem uma visão clara do problema não escreve código limpo, e depois de um dia, ele já tem medo de colocar as mãos nele (imagine depois de um mês para uma atualização ou intervenção para manutenção e bugs! ).
10. Ele não considera o consumo de memória e o desempenho do que está criando , por exemplo, usando um número inadequado de threads em programação paralela ou não leva em consideração como as transações são gerenciadas no momento de vários usuários conectados.
11. Ele não se pergunta o que acontece quando o aplicativo não é usado da maneira que você pensa. Por exemplo, suponha que você receba um nome de usuário e senha em um formulário em que você solicita um nome de usuário e uma senha e não algum código que possa de alguma forma explorar uma falha em seu sistema.

Mais conteúdo em PlainEnglish.io . Assine nosso boletim informativo semanal gratuito . Siga-nos no Twitter e LinkedIn . Junte-se à nossa comunidade Discord .