Vícios e manias de quem aprende a programar sozinho

Fonte: http://matus76.deviantart.com/art/Self-Taught-411149744 - Matias Sierra

Fonte: http://matus76.deviantart.com/art/Self-Taught-411149744 – Matías Sierra

Atualmente é muito comum encontrar desenvolvedores, programadores e demais profissionais que aprenderam a programar sozinhos. Neste post 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 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 importe de 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.

Dificuldade no trabalho com uma equipe
Figura2_NoTeamWork

Quem aprende a programar sozinho e por conta 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 é um das habilidades (soft skills) extremamente importantes 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 admirável a 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 o 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 um 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

Figura3_CameCase
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 praticas 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
Figura4_FaltaConhecimento

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, digamos assim.

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 mais podem 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
Figura5_FaltaDocumentacao

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
Figura6_FocoImplementacao

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 post 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 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 heroico) é 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
Figura7_CopyPaste

Quando analiso 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 post 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.



Esta entrada foi publicada em Programação e marcada com a tag , , , , , , , , , . Adicione o link permanente aos seus favoritos.

17 respostas a Vícios e manias de quem aprende a programar sozinho

  1. Joao disse:

    Acho que o mesmo se aplica em muitos dos desenvolvedores que aprendem programacao por outros veiculos como universidade, etc. Pra maioria dos itens acima, eu atribuiria mais a falta de experiencia e nao a forma de aprendizado. Eh muito facil ler em um artigo que usar tal pratica de desenvolvimento eh bom, milagroso, etc, mas poder julgar em primeira pessoa por ter utilizado e ver quais os problemas que emergem utilizando tal metodo, eh o que faz a pessoa crescer como desenvolvedor.

  2. Antony disse:

    João disse tudo, isso tem mais a ver com a experiência e maus hábitos do que com aprender sozinho. Aprender sozinho não é aprender errado, desde que você aprenda com o conteúdo correto.

  3. daniel disse:

    Acho que a assetiva não é:

    “Em geral, quem aprende a programar sozinho desenvolve X, Y e Z vícios.”

    Mas:

    “Maus programadores – experientes ou não, em geral, não observam as melhores práticas e padrões reconhecidos”

    Somado com..

    “Ao aprender a programar sem a orientação adequada, em um contexto de exigência não-profisisional, é possível acabar-se descuidando do estudos das melhores práticas e padrões reconhecidos”.

  4. juliano disse:

    concordo com o colega acima, é pessoal e não tem a ver com aprender a programar “sozinho”.

  5. Faltou o “não separar o software em camadas”, ou seja, separar o código entre camada de apresentação (telas), negócio (regra de negócio) e persistência (armazenamento de dados).

  6. Eu, particularmente, não encontrei até hoje uma relação que se possa considerar como uma característica dos que possuem instrução formal dos que não possuem. Acho que varia de pessoa para pessoa.

    Estudo TI em uma universidade federal, considerada “entre as melhores”, onde os professores são quase todos “doutores”. Vários deles ensinam coisas totalmente desatualizadas, más práticas, gambiarras e tudo o que é depreciado nas linguagens. Vários nunca trabalharam de verdade, e alguns trabalharam por pouquíssimo tempo. Fora os que insistem em pregar para os alunos que linguagem X é melhor que linguagem Y, só por que é a linguagem que eles mais conhecem.

    No meu caso, a faculdade é 80% perda de tempo. 50% graças as coisas horríveis que são “ensinadas”. 30% é simplesmente por coisas que não estão na minha lista de objetivos em aprender. 20% é de coisas úteis.

    Nada como reflexão sobre o processo, muita leitura, muita prática, e ler código bom.

    Por outro lado, o artigo trás vários pontos interessantes para se pensar, e com certeza há muita gente que se enquadra nas características destacadas.

  7. Uma boa visão sobre o tema. Concordo em vários pontos e eu ainda adicionaria o fato de muitos programadores não investirem um tempo em aprender a programar com os 10 dedos. Isto melhora muito a produtividade. Vejo muitos ainda “catando milho” ao digitar. Parece que eles só tem 2 dedos!

  8. marcelo disse:

    Na realidade você atribuir a qualidade, vícios e outras coisas mais, jogar tudo isto no cesto e adjetivar como programadores que aprendem sozinho, desculpe, mas é sacanagem né?! Existem profissionais que conseguem com seu esforço entrar em empresas muito boas e aplicar e absorver conhecimento, outros seguem um perfil empreendedor e se mantém, fazem bons códigos. A TI é bem assim, sempre escrevem o mundo perfeito e dizem quem é o bom e mau da história. Hoje você estuda e gasta ($$$$$$$$$$$$$$$$) em certificações, quando vai fazer entrevista encontra muitas vezes uns babacas que se acham os poderosos só porque estão em empresas grandes e tem certeza que fazem tudo do jeito certo. Engraçado como tanto projeto bom começa dentro de casa, difundi entre grupos até que a iniciativa privada com a sua “capacidade de profissionais ultracertificados”, identados e polidos pagam milhões nesses produtos, as coisas não são tão simples como expostos aqui. Como já citado em outras opiniões aqui, a minha também é “Tudo varia de pessoa para pessoa”

  9. Talvez o título soe um pouco forte demais, mas temos que lembrar que o autor do artigo deixou claro que ele mesmo concorda que nem todo mundo que aprendeu programar “sozinho” possui as características citadas. Outra coisa é que o autor afirma falar de coisas que ele próprio presenciou. Talvez não seja o que outros de nós têm visto por aí, mas isso não quer dizer que o @pichiliani está errado em comentar experiências pelas quais ele passou ou passa.

  10. j0e disse:

    Quando você cita documentação do código, da forma como aborda, parece de certa maneira, ignorar o uso profissional de metodologias ágeis. Talvez isto, por não ter referenciado definições do que caracterizam documentações em diferentes metodologias. Apenas, IMHO. 🙂

  11. Vinícius disse:

    Você descreveu um mal programador (ou menos experiente), não um programador que aprendeu sozinho.

  12. Odecio disse:

    Programar pra mim sempre foi resolver o problema, o resto é palhaçada que não leva a lugar nenhum

  13. Salomao sal disse:

    As vezes o que acontece é que quando se está em um projeto complexo, se trabalha sozinho porque é complicado encontrar pessoas da mesma cidade para ajudar, ai certas coisas tem que serem feitas mais rápidas e abreviadas, más varia de pessoa para pessoa desenvolver vícios, e o que falta as vezes é falta de experiencia do programador iniciante, e o bom de se aprender sozinho é que aprendemos o que queremos, não perdemos tempo com coisas que não iremos usar, mantemos o foco naquilo que achamos que será o melhor, se os professores fossem bons mesmo, não dariam aulas, estariam criando coisas e ficando rico rsrs, porque quem é bom mesmo não vai querer dar aula e ganhar pouco, vai querer ganhar muito. #minhaopiniao

  14. Grégori disse:

    é realmente… eu que começei muito bem sei bem como é isso… talvez sou afetado pela falta de experienia com trabalho em equipe, no entanto apesar de já ter feito muita coisa “auxiliando” outros programadores que tem problemas com a lógica e a falta de conhecimento de uma API especfica…. meu problema vem mais da questão de escolha de linguagem, já que apesar de conhecer C suficientemente, tenho como linguagem principal o Freebasic, meu maior tesouro e quebrador de tabus :P… no entanto com relação a ter um supervisor, e outros tentando ditar como eu faço as coisas, isso eu realmente jamais aceitaria, porque pra mim não me interessa prazos apertados, ou falta disso e daquilo, se eu programo… é pra fazer com qualidade, e não me perimo reusar códigos com qualidade duvidosa, deixar código sem otimizar, e nada disso… ou eu faço direito, ou eu não faço… não existe coisa que mais odeio no mundo do que programador preguiçoso, ou que trabalha dando mais importancia pra uma “carreira” do que pra qualidade do que faz, e sempre sempre melhorar, e isso significa reescrever mais códigos do que reusar, fazendo sempre algo melhor com o aprendeu no trabalho anterior…

    o resto dos itens eu até entendendo, embora não seja uma problema pra mim, já que me forço a sempre fazer tudo certinho, comentar bem o código… e manter o meu estilo de código… ou com relutância usar o estilo definido pelo grupo…

  15. gilberto disse:

    A maior bobagem que já li na internet.

    Pela minha experiência, sei com absoluta certeza que a realidade é outra.

    Os melhores profissionais que conheço sequer fizeram faculdade e também tem alguns, até um pouco famosos, que não terminaram, como Steve Jobs, Bill Gates, Michael Dell e Mark Zuckerberg (diga a eles que o que eles fizeram não tem qualidade pois estudaram por conta própria).

    O problema de quem faz faculdade na área de tecnologia é achar que já sabe o suficiente, e depois descobre que a tecnologia muda todo dia, e para ele continuar no mercado de trabalho (sendo bom profissional) terá que continuar estudando por conta própria, se tornando um autodidata, o que ele poderia ter feito desde o início.

    http://gizmodo.uol.com.br/os-quatro-gigantes-da-tecnologia-que-nao-acabaram-a-faculdade/

    http://info.abril.com.br/noticias/carreira/8-executivos-que-nao-terminaram-a-faculdade-27122010-21.shl

  16. Rj InfoTec disse:

    Show de bola. Venho aprendendo bastante!

  17. Revoltz disse:

    Sobre o ponto de “trabalho em equipe” fica difícil quando você entra em uma empresa após anos de treinamento e se depara com “superiores” que têm conhecimento técnico inferior a você, sendo que a única habilidade que eles têm em “superior” é como estressar o funcionário permanentemente para que ele “renda mais” e como construir frases bonitinhas e impactantes para impressionar a todos na sala de reunião. É difícil trabalhar em equipe quando NADA que você faz é considerado bom, sempre tem um defeito. Quer saber? Foda-se essa merda então, vou virar freelancer!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *