Os 4 Hábitos Que Tornam Você Um Programador Ineficiente
Você não é um programador ruim. Você pode apenas ter hábitos de um programador ruim. E neste artigo eu vou destacar 4 destes hábitos, o que vai dar uma clareada sobre o que pode estar acontecendo.
E de largada eu já digo:
É muito importante você aprender a diferença entre “ser algo” e “estar algo”
Por exemplo, quando as pessoas escrevem nos comentários dos vídeos no meu canal do YouTube algo do tipo: “Putz, eu não sou um bom programador…”
Eu fico louco! Porque eu leio isso como se fosse: “Putz, eu sou cansado…"
Ué, não! Você pode “estar” cansado, assim como você pode talvez “estar” num estágio de um programador ruim.
Não sei se vocês já perceberam, mas o cérebro as vezes se faz de burro… Já notaram isso? É muito massa… O pedaço de carne mais sofisticado desse planeta terra inteiro, se depara com duas escolhas: Uma que vai gerar talvez um progresso, mas com um desconforto garantido, e outra que não vai gerar progresso, mas pelo menos tem o conforto como garantia.
Daí você pode estar se perguntando:
"Bom só pra confirmar: você não está garantindo progresso, mas está me garantindo desconforto?"
Sim, e é por isso que vídeos como A história da Ana geram a mesma quantidade de desconforto e progresso. E se você parar pra pensar, se não tivesse gerado o desconforto, não teria chance nenhuma de ter gerado o progresso que gerou. Se você ainda não viu esse vídeo, cuidado pois a sensação é de levar um soco no estômago!
Este artigo aqui foi feito baseado em um outro escrito pelo Daan, que se intitula “4 Habits That Make You an Inefficient Developer”. Ele não vai gerar o mesmo nível de desconforto, mas vai gerar aquele "Vrahh! Preciso parar de fazer essas coisas!". Então vamos lá:
Hábito ruim #1 — Falar Sim para tudo
Assim como o autor do artigo escreveu, falar sim para tudo e tentar ajudar todo mundo é de fato uma postura louvável. Agora, a vida vai te ensinar rapidinho que a promessa que você faz para uma pessoa, na verdade, é uma “dívida” e você precisa tomar muito cuidado ao ficar fazendo dívidas fora do controle, porque o limite do seu tempo vai estourar e os juros são extremamente caros. E mesmo que você dê conta de dizer sim para todo mundo, é bem possível que a sua performance em programar, a sua produtividade, vai lá para baixo de tantas interrupções você vai sofrer.
Eu sempre fui um dos que falava sim, principalmente quando começava a trabalhar em algum local novo, o que é um comportamento super normal. Inclusive, se você está entrando numa tribo nova, comece servindo para mostrar pra galera que está te olhando como um ser desconhecido que você serve para algo.
Agora, tinha vezes que eu percebia que eu virava uma espécie de nicotina. As pessoas ficavam viciadas em ter que escutar a minha opinião sobre algo que elas estavam para fazer, ou um risco que elas iam tomar. Por exemplo, a pessoa escrevia um email que era perigoso de enviar, e pedia para eu ler pra saber a minha opinião. Chegou a um ponto em que eu lia o email, mas aí eu falava pra ela que eu só ia dar a minha opinião depois que ela tivesse enviado o email. E eu fazia isso por um motivo simples. Se eu revisasse, desse minha opinião e talvez fizesse alguma alteração, se esse email desse errado a gente ia dividir a culpa, e se desse certo, a gente ia dividir a conquista. É muito mais poderoso pra pessoa assumir 100% do risco e 100% do retorno. São dessas pequenas oportunidades (e tem várias), que você vai destravando novas lideranças dentro da empresa, ao invés de ficar diluindo uma única pessoa.
Você já pode ter trabalhado numa empresa que só roda se aquela pessoa "x" for destravando as outras pessoas… O que é péssimo, um baita gargalo! Isso leva a outra condição que eu passava onde, algumas pessoas que se encontravam com alguma dúvida, vinham me perguntar qual era a resposta. Mas eu notava que elas vinham com o cérebro… não sei, parece que desligado! Ai eu falava:
"Hum, interessante… Eu sei sim a resposta, mas eu não vou te falar. Você tem ferramentas o suficiente dentro da sua cabeça para descobrir a resposta também."
Aí parecia que o cérebro da pessoa ligava de volta, era maravilhoso!
Agora, por favor, percebam o nível de senioridade da pessoa e se o objetivo é compatível com o risco que ela está assumindo. Não vai deixar uma pessoa que acabou de entrar na empresa, mal sabe programar, e que ganhou acesso a um banco de dados de produção (sabe-se lá porquê) sem resposta para uma pergunta como essa:
"Preciso rodar essa query aqui no banco de produção para atualizar o nome de um cliente, o que você acha?"
Quem entende de SQL sabe que dia divertido vai ser esse na firma, não é mesmo?
Bom, no artigo ele destaca uma frase do Paulo Coelho, que diz o seguinte:
“Quando disser “sim” para os outros, certifique-se de não estar dizendo “não” para si mesmo.”
E eu adicionaria que, se você estiver diluindo a toda hora o risco das pessoas, você também pode estar inibindo a formação de novos líderes na empresa.
Hábito ruim # 2: Sua definição da palavra “Pronto” possivelmente não é “Pronto” na verdade
Programação tem uma característica interessante: digitar letras e números que formam um código é apenas “uma” das milhares de coisas que um programador precisa fazer. E é visível o comportamento de um programador que entende isso, comparado a um que não entende.
Se você acredita que pegar uma issue, programar ela de primeira, entregar e marcar como completa lá no Jira significa que o trabalho está “pronto”? É bem possível que esteja muito longe disso:
- Você olhou para o seu código de forma crítica, ao ponto de se questionar se algum outro desenvolvedor conseguiria entender ele com facilidade? Se não, essa é a maior margem que você tem para refatorar um código. Então o seu trabalho não está pronto! Você entregou apenas um rascunho.
- Fora isso, a alteração que você fez tem algum reflexo em alguma documentação? E quando você está na posição de fazer o review de algum pull request, você olha o diff somente a procura de fazer sugestões de code style — o que é a coisa mais fácil — e acaba pegando mais leve em estressar o mais importante que é a regra de negócio, só porque essa é bem mais difícil?
- E por último, você testou somente o caminho feliz dessa nova implementação? Se sim, chegou a hora de irmos para o próximo item.
Hábito ruim #3: Não testar o seu próprio código
Nessa parte do artigo o autor trata de um contexto que tenha um programador e um QA. QA significa “Quality Assurance”, que é a pessoa que vai testar o seu código. Independente se na sua empresa essa é a configuração ou não, se você só testar o caminho feliz do seu código, é meio que tão besta quanto você me falar que você concorda com a sua própria opinião.
Você precisa aprender a escrever testes automatizados, não interessa se vai ser somente E2E porque o seu código não está dividido em unidades testáveis, ou testes de integração ou de unidade. Comece o quanto antes com essa prática para você ganhar velocidade e entender como que o próprio código de testes vai te enganar um dia, vai ser lindo!
Então garanta que as coisas deveriam funcionar, e também quando elas deveriam retornar mensagens de erro.
Hábito ruim #4: Fazer commits gigantescos
Esse é fácil. Qual é a sensação que você tem quando precisa fazer o review de um commit ou um pull request gigantesco? É um saco! Você não sabe quando aquilo vai terminar e não tem nem a vontade de começar.
Tome muito cuidado porque isso pode ser reflexo também de um sistema sem modelagem, mal arquitetado. Isso porque, da mesma forma que os componentes do sistema não têm início, meio e fim, o escopo da alteração também não vai ter. Você vai poder ir colocando para sempre alterações dentro de um commit ou pull request. E mesmo que você tenha que fazer um pull request grande, procure separar o progresso em pequenos commits e se certifique que cada commit, cada passo, continua sendo funcional.O que quero dizer com isso é, se um commit quebra um teste, e daí em seguida você faz outro commit para consertar o teste, procure daqui para frente fazer o código e o teste passarem no mesmo commit.Transforme ele numa unidade de alteração funcional, e não num diário. Você vai ver como cada commit vai se transformar em algo mais valioso, mais modelado.
E você percebe que tudo isso está relacionado a ser um programador melhor, com menos hábitos ruins e, como consequência, mais hábitos bons? Super conectado a isso tem um outro artigo meu aqui no Medium em que eu mostro para você e para o seu chefe porquê os bons desenvolvedores deveriam ser muito bem remunerados. É um artigo que, no formato de vídeo, bombou no meu canal do YouTube e, se você procura ser valorizado na nossa área, é mandatório que você leia o artigo ou assista ao vídeo do início ao fim. Esse artigo se chama "Checklist do Programador Sênior: 10 Itens Para Você Ser um Programador MUITO Acima da Média".
Obrigado por ter lido até aqui!
