Atualmente, é muito comum encontrar desenvolvedores, programadores e demais profissionais que aprenderam a programar sozinhos. Neste artigo vou comentar um pouco sobre os tipos de vícios e manias que acabo vendo em profissionais com este perfil.
Para começar, gostaria de destacar que fiz questão de não utilizar a palavra autodidata. O motivo é que este termo certamente não tem mais a mesma conotação e peso que tinha há algum tempo atrás. Isso se deve à necessidade de sempre aprender coisas novas da área e à grande quantidade e facilidade de acesso às informações disponível na Internet, especialmente para desenvolvedores. Sendo assim, não acredito que utilizar o termo autodidata contribui para expressar o tipo de pessoa que possui os comportamentos que vou descrever aqui. Afinal de contas, somos todos autodidatas em algum nível e isso não torna necessariamente alguém melhor ou pior que outra pessoa.
Outro aspecto que é importante citar antes de descrever os vícios e manias, é que tenho noção do fato que nem todo mundo que aprendeu a programar sozinho pode ter os vícios e manias que citei aqui. Sim, eu sei que muita gente passa longe das atitudes descritas, mas, infelizmente, durante a minha experiência profissional, tenho visto muitos perfis comprovando que, de fato, o aprendizado individual acaba fortalecendo vícios nada adequados para o ambiente de trabalho profissional com programação. Destaco também que não tenho nada contra quem aprende programação sozinho, até porquê sou um forte incentivador e produtor de conteúdo para este público.
Dificuldade no trabalho com uma equipe
Quem aprende a programar sozinho está acostumado a passar horas e horas isolado ou com pouca interação com outras pessoas. Enquanto este isolamento auxilia na concentração e esforço mental, ele possui um efeito colateral: a falta de entrosamento e a pouca aptidão para se trabalhar em equipe. Esta dificuldade envolve muitos pontos, mas vou me concentrar em apenas três: dificuldade de comunicação, desprezo por opiniões divergentes e atritos no relacionamento com superiores.
A comunicação é uma das mais importantes habilidades (soft skills) quando se trabalha com programação em uma equipe. É preciso saber avisar o que foi feito, pedir opiniões, comunicar problemas, descrever cenários, solicitar tarefas, negociar prazo e mais uma série de outras atividades que não podem ser feitas sem boas habilidades comunicativas. Contudo, as pessoas que aprendem a programar desenvolvem um vício que chamo de economia verbal, pois na mente destas pessoas quanto menos palavras forem ditas, melhor. É complicado conversar com um profissional com este vício em uma reunião, por exemplo, pois ele está tão aplicado em seu pensamento que praticamente despreza e dá o mínimo de atenção à comunicação.
Muitos programadores que conheci possuíam uma resistência e desprezo pelas sugestões, opiniões ou comentários relacionados aos códigos que eles escreveram, especialmente quando se cita alguma falha, problema ou possível melhoria. Estas atitudes mostram que há um forte senso de propriedade (algo como “o código é meu e eu sei o que faço!”) e falta de traquejo social para aceitar que nem sempre suas “crias” são as mais bonitas ou funcionam da melhor maneira possível. A provável razão deste comportamento é que quando a programação é realizada por uma pessoa que aprendeu sozinha, ela não recebeu críticas, aconselhamento, opiniões, revisão e outros inputs durante seu aprendizado. Esta falta de um par extra de olhos acaba levando o programador a adotar atitudes defensivas e, às vezes, até agressivas quando ele se depara com o que outras pessoas acham do seu código.
O aprendizado individual acaba reduzindo a noção de que durante o trabalho provavelmente teremos algum tipo de hierarquia, onde uma ou mais pessoas vão assumir papéis de liderança. Quando se aprende sozinho, o aprendiz é o seu próprio chefe e a cobrança é dele para ele mesmo. Contudo, no mundo real as coisas são um pouco diferentes, pois superiores (gerentes de projeto, supervisores, coordenadores e outros) possuem formas diferentes de pedir tarefas, cobrar resultados, trocar prioridades e gerenciar pessoas. Este conflito acaba levando a situações onde há algum nível de insubordinação que pode levar a ações punitivas. Na melhor das hipóteses, o aprendiz reconhece que ele deve ficar quieto, ouvir e obedecer. Na pior das hipóteses, pessoas abandonam equipes e juram que nunca mais vão trabalhar sob a supervisão de outros profissionais.
Falta de padronização na codificação
Quem aprende a programar sozinho presta pouca ou nenhuma atenção a detalhes como, por exemplo, a padronização dos nomes de elementos do programa. Se, por um lado, esta tarefa requer mais esforço e consome um pouco mais de tempo na codificação, por outro lado ela facilita muito a manutenção do código.
Apesar de muitos materiais didáticos, cursos, vídeos e outros recursos de ensino de programação recomendarem o uso de padrões de codificação, ainda é muito comum encontrar profissionais que ou fogem destas práticas ou as implementam de forma parcial. Este tipo de comportamento acontece com todo mundo durante a carreira, mas tenho visto uma tendência muito forte ao desrespeito aos padrões de codificação para nomes de variáveis, classes, métodos, funções, procedures, interfaces e outros elementos de programação em profissionais que aprenderam a programar sozinhos.
Em alguns momentos, a coisa ficou tão comum que já tive a impressão que estava perante uma epidemia de nomes ruins utilizados em variáveis, métodos, funções e procedures. A vacina? Revisão de código e regras que forçam certos padrões ao ponto do código fonte não ser utilizado por ter uma qualidade abaixo do mínimo aceitável para que outra pessoa trabalhe com ele no futuro – mesma se esta pessoa for o autor original deste código e que o programa esteja atendendo os requisitos funcionais.
Falta de conhecimento de ferramentas do mercado
Quem está aprendendo a programar geralmente escolhe alguma linguagem, ambiente, plataforma ou tecnologia para “pegar o jeito da coisa”. Agir desta maneira é OK, mas é preciso lembrar que uma coisa é como você está aprendendo e outra é como o mercado e as empresas usam esta tecnologia.
Por exemplo: durante o aprendizado básico de criação de CRUDs raramente são citados aspectos de controle de transação para situações, onde há a possibilidade de operações conflitantes. Já na realidade, é relativamente comum encontrar problemas clássicos como deadlocks, phanton records e outros que vêm de reboque quando um sistema começa a ter muitos usuários e alguma atitude para atender a escalabilidade já foi tomada.
Outro exemplo clássico é a falta de conhecimento e uso de sistemas de controle de versão. Afinal de contas, quem aprendeu sozinho não se depara com a necessidade de compartilhar seu código com outras pessoas. Esta falta de conhecimento e uso de ferramentas de controle de versão (GitHub, CVS, Mercurial, Team Foundation e outras) é tão notória quanto o desconhecimento de ferramentas de automação de build como o ANT, Maven e Gradle. Devido à necessidade de uso destas ferramentas nas empresas, é praticamente obrigatório um treinamento de novos colaboradores nestas tecnologias (o que acaba consumindo tempo e recursos valiosos que poderiam ser empregados em outras tarefas mais nobres).
Por fim, a prática de revisão de código (code review) soa como algo alienígena para quem estuda sozinho, afinal de contas por que eu pediria para alguém revisar o meu código enquanto estou aprendendo? Bem, sem entrar mais detalhes, basta dizer que sessões de revisão de código não podem mais ser consideradas um luxo, uma vez que seus benefícios já foram largamente comprovados em diversos estudos e situações reais.
Não investir na documentação
A documentação de código pode assumir vários formatos e, independente de como ela exista, é muito importante investir na sua criação. Esta documentação não é útil apenas para ajudar a esclarecer aspectos técnicos, mas também para organizar e gerenciar o trabalho de todos os profissionais envolvidos em um projeto de software, seja no presente ou no futuro.
Ao contrário do que alguns podem pensar, a documentação não é apenas um trabalho desnecessário que toma tempo e torna tudo mais lento. Ela é um item obrigatório em qualquer projeto, servindo a vários propósitos. Contudo, por questões culturais e outros motivos tradicionalmente o brasileiro não é conhecido pelas suas habilidades de organização e documentação.
Novamente, uma forma de traçar a origem deste sério problema é analisar quem aprende sozinho. Neste cenário, a tarefa de investir na criação de documentação recebe prioridade, pois o pensamento é que quem criou o código sempre vai se lembrar dele no futuro. Já escrevi um pouco sobre isso com foco no DBA, mas acredito que as lições e tipos de artefatos apresentados naquela ocasião ainda são válidos e podem ajudar quem dá pouca ou nenhuma atenção à documentação.
Foco na implementação e não no design
Durante o período de aprendizado, é comum gastar mais tempo tentando resolver os problemas do que analisando suas características. Isso já foi destacado no artigo que escrevi aqui no blog, onde discuti e apresentei recomendação sobre como focar no problema, ao invés da solução.
Quando me deparo com pessoas que aprenderam a programar sozinhas, na maioria das vezes fica claro o padrão de comportamento representado pela dificuldade de analisar, conceber e pensar no design da solução e como este design deve ser separado da implementação do código. A avidez por sair codificando e utilizando os recursos de produtividade das plataformas de desenvolvimento mostra que o design e arquitetura acabam ficando de lado perante aspectos de implementação.
Tal atitude também fortalece e favorece o trabalho customizado, no sentido de que a cada novo problema a maneira de resolvê-lo vai ser diferente da anterior. Este modo de trabalho ad hoc pode ser bom para cenários altamente voláteis e com requisitos imprevisíveis (algo raro) que tornam a previsão da próxima necessidade impossível de ser conhecida. Não obstante, geralmente o trabalho no dia a dia requer um nível alto de sistematização das atividades onde processos e práticas comuns são largamente empregadas sem muito desvio.
Este tipo de trabalho sistematizado, previsível e altamente compartimentalizado é visto com bons olhos na programação profissional, pois ele permite que sejam feitas previsões e que metas sejam completadas com sucesso dentro do prazo. O que quero dizer aqui é que o vício do modo cowboy de programação (também chamado de heróico) é muito comum em cenários onde o programador tem a convicção de resolver tudo sozinho e que sem sua “mágica” nada vai funcionar corretamente. Contudo, agir desta maneira pode acabar sendo contraproducente quando é preciso encarar a programação de modo profissional.
Muita duplicação de código e pouca reusabilidade
Quando analiso o código de outras pessoas, fico atento a um dos principais indícios que me permite identificar se estou lidando com alguém que aprendeu sozinho: o abuso dos recursos de copiar e colar representado pela alta taxa de duplicação de código e quase nenhuma usabilidade.
Os recursos de copiar e colar estão entre os principais truques que aumentam a produtividade de quem programa. E pela facilidade destas operações é quase uma consequência observar que tanta gente acaba duplicando de forma inadequada o código ao invés de utilizar técnicas adequadas de reusabilidade.
O abuso das técnicas de copiar e colar e códigos fontes é tão disseminado que uma vez conversando com um colega ele sugeriu uma atitude radical: a criação de um “polícia do copy & paste”. Esta polícia seria responsável por detectar, julgar, sentenciar, punir e criar novas leis para erradicar e obliterar o uso bizarro de copiar e colar em código fonte. Acho que não preciso dizer que este meu colega era responsável por dar manutenção em código fonte legado e não conhecia ou não praticava algumas das técnicas descritas para manipular código legado descritas em outro artigo meu.
Aqui vale a pena investir em design patters, refatoração, componentização, uso de frameworks e o tão negligenciado olhar focado no design através da boa modelagem de classes, relacionamentos, interfaces e outros elementos.
Para fechar este artigo, gostaria de terminar com um tom otimista: todas as pessoas que trabalham com programação possuem um ou outro hábito, vício ou mania ruim que pode ser melhorado. Isso faz parte do jogo. Mas acredito que nunca é tarde para para tentar reduzir o impacto que este hábito ruim pode trazer na vida profissional de um desenvolvedor.
—–
Artigo publicado no iMasters.
