Blog Bugginho Academy

Não seja “aquele” programador. Seja um profissional.

Saudações amigos profissionais. Por acaso você já ouviu falar na frase “a informática surgiu para resolver problemas que não existiam antes de sua criação”?

Desde os primórdios da computação o homem criou e resolveu problemas relacionados à tecnologia, desde necessidades como transmitir uma mensagem de texto entre dois locais distintos do planeta até soluções para cirurgias à distância ou criação de robôs ajudantes. Mas sempre existiu um fator, digamos problemático, que são os programadores “pouco profissionais”.

Não quero que me julgue mal e tome a dor para si, mas eu diria que mais de 60% de vocês que estão lendo este artigo agora são programadores pouco profissionais.

Veja bem, não estou dizendo que você é incompetente ou que programa mal. Conheço muitos programadores que dominam muito bem uma linguagem, mas mesmo assim fazem coisas que alguém como o Tio Bob (alguém aí conhece Robert C. Martin aka Uncle Bob?) jamais faria. Reparou que deixei em itálico a palavra uma?

Chega de causar desconforto e vamos começar a falar o que é ser um programador profissional. Costumo dizer que você e somente você é culpado pelo desastre que é o software o qual está sob seus cuidados. Na maioria das vezes a culpa dos erros trazidos pela aplicação foi herdada por um programador que já nem faz mais parte do corpo de colaboradores da empresa, mas mesmo assim o peso dos erros do passado cai sob as costas de quem hoje está à frente da IDE, você, programador.

E definitivamente não há palavras que façam seu gerente mudar de ideia com relação a isso, seu destino é sofrer chibatadas incessantemente até que a exaustão tome conta do seu ser e você desista de continuar doando seu sangue à empresa. Exageros à parte, você decide que não quer mais assumir os erros dos outros e suas gambiarras (lê-se Soluções Técnico-Alternativas) já não conseguem mais atender às demandas do cliente.

Mas por que isso continua acontecendo nessa porção tão grande das empresas brasileiras?

Responsa sem pensar, quantas vezes essa semana você barrou uma certa funcionalidade por conta de ausência de informações ou pouco entendimento dos requisitos? Quantas vezes você disse sim sem nem sequer saber qual o tamanho de uma determinada funcionalidade solicitada pelo cliente? Quantas vezes você se comprometeu a entregar alguma coisa e extrapolou o tempo de desenvolvimento em 25% ou mais de 75%? Sabe o que isso significa? Imaturidade.

Quer um exemplo? Esqueça tudo sobre tecnologia, imagine-se como um engenheiro. Seu cliente quer que você continue uma ponte que foi começada há 5 anos, mas até hoje não foi concluída. Você olha para o visual dela e aparentemente ela possui apenas um pouco de limo, rachaduras superficiais e algumas manchas que parecem ferrugem que escorreu nas pilastras durante as chuvas de todo o tempo que ela ficou desprotegida. Seu cliente pede para terminar a construção de 250m em 2 semanas, pois haverá um evento importante na cidade e precisa que tudo esteja ok, porém o orçamento está apertado e não há tempo para corrigir as imperfeições da estrutura. Qual seria sua atitude? Aceitar o desafio e colocar seu nome em risco, atrasando a execução, consumindo mais recursos e correndo o risco de que aquela estrutura desabe ou seria um profissional solicitando mais tempo, apontando falhas e definindo um plano de ação?

Se engenheiros civis construíssem coisas com o mesmo cuidado que engenheiros de software constroem sistemas, o primeiro pica-pau a chegar poderia destruir a civilização como a conhecemos.

Vamos a um outro exemplo. Um médico não treina operações em seus pacientes. São necessários anos de faculdade e mais alguns de residência para que ele se torne apto a fazer uma cirurgia. Normalmente usam pedaços de carne do açougue (sim, tenho quem confirme) e treinam para que tudo saia como o planejado na “hora H”.

Entende o quão é importante um comportamento adequado na arte de produzir softwares? O ponto principal que quero chegar é que não adianta você reclamar que existe um problema, pois estes irão sempre existir. O que precisa ser mudada é a sua postura em relação ao problema. Vamos exemplificar melhor.

São 8:15 da manhã. A capacidade de desenvolvimento de sua equipe é de x por dia e seu gerente chega na sala solicitando uma funcionalidade de tamanho x * 2 para ainda hoje. A primeira vista o time já fica submisso, pois é o gerente quem está pedindo. Mas vocês já estão cheios de tarefas e não conseguem absorver a atividade e no final do dia, fracassam, mesmo fazendo o famoso esforço extra. Qual seria a atitude correta?

Lembrem-se de que os donos do código são vocês. Os programadores são quem tem contato diário com o código do sistema, portanto apenas vocês são os mais indicados para dizerem quanto tempo leva e o que precisam para que algo aconteça. O ideal, que ainda é difícil fazer acontecer, seria avisar ao gerente que a equipe não tem condições de absorver a demanda e negociar o que deve ser entregue primeiro. Definidas as prioridades a equipe fica ciente do novo plano e o segue para concluir sua missão.

O comportamento é apenas o primeiro passo na longa jornada para ser um programador profissional. Recomendo fortemente que, quem puder, compre e leia The Clean Coder (O Codificador Limpo) do Robert C. Martin, mas não confunda com The Clean Code também da mesma série de livros do Tio Bob. O Codificador Limpo deveria ser considerado livro de cabeceira de todos os profissionais de TI (programadores, gerentes, product owners, testers…), pois nele o Uncle Bob traz fatos reais de sua história que podemos tirar como experiência para nos tornarmos profissionais melhores.

Em nosso próximo encontro falaremos um pouco sobre Código Legado e como podemos lidar com ele utilizando o Código Limpo.

Marcos Rocha

Desenvolvedor desde 2004, atualmente desenvolve aplicações Android e iOS nativamente. Possui várias linguagens em seu "vocabulário" e é apaixonado por ensinar e compartilhar seus conhecimentos.

2 comentários

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  • Um artigo desse tamanho pra dizer que não dizemos ‘não’ quando um chefe solicita algo pra ontem? Na maioria das vezes não somos nós que lidamos com o cliente, o chefe lida e só manda fazer. A preocupação de um programador deve ser estudar e ser proficiente nas linguagens e atribuições de seu ofício de modo a gerar poucos problemas. Uma empresa onde é o papel do programador dizer se uma funcionalidade deve ser implementada ou não, esta sim segue uma ideia imatura, pois é como diz o ditado, “quem quer sempre dá um jeito, quem não quer sempre arruma uma desculpa”.

    Existem programadores não profissionais no que diz a conduta de trabalho? sim.
    Mas pseudo-generalizar sem base em estatística alguma que uma porcentagem de programadores não são profissionais é pura introspecção. Talvez você tenha tido más experiências, só isso;

    • Olá Vinicius, que bom que você pensa dessa forma. Sim, o artigo deste tamanho para dizer que não dizemos ‘não’. Deixa eu te dizer uma coisa, já trabalhei em empresas do Paraná e em Santa Catarina e em nenhuma vi um comportamento legitimamente profissional vindo de um programador. ‘Dar um jeito’ é colocar seu nome na lista dos que mais falham ou que mais atrasam. Além do mais não estou dizendo que o programador deve sempre dizer não, você leu “O Codificador Limpo”? A ideia aqui é negociar com o gerente para que haja tempo de entrega. Eu sei que em times ágeis se trabalha com pouco. Mas esta não é a realidade da maioria das empresas brasileiras. Posso estar sendo introspectivo por ter tido más experiências? Sim. Mas acredite, não escrevi este artigo sem fundamentos, experiência vale muito, já vi muitas empresas onde a ‘coisa flui’. A intenção deste artigo foi sim mexer com o ego do leitor e indicar a leitura do livro que expõe muito mais situações que acontecem desde 1950 até hoje. Do mais… de base estatística uso esta http://marcosrocha.net/geral/resultado-pesquisa-desenvolvimento-sustentavel-de-software/ que não é um IBGE, mas demonstrou que muitos desenvolvedores ainda não utilizam ou não conhecem boas práticas de produção de software.

Your Header Sidebar area is currently empty. Hurry up and add some widgets.