Os 4 hábitos que tornam você um programador ineficiente

Comentando: Os 4 hábitos que tornam você um programador ineficiente

1
Você não é um desenvolvedor ruim, apenas tem alguns maus hábitos - Daan

Os comentários vão esta neste formato.

Os 4 hábitos que tornam você um programador ineficiente

Todos nós temos eles. Maus hábitos. Nenhuma pessoa nesta terra é perfeita.

Ter maus hábitos como desenvolvedor pode prejudicar seriamente sua eficiência. Eles também podem impactar as pessoas ao seu redor.

Jack Canfield diz: “Seus hábitos determinarão seu futuro”. Se você quer crescer como desenvolvedor, precisa quebrar seus maus hábitos. Se você conseguir, sua eficiência aumentará dramaticamente.

Vamos rever os maus hábitos que você deve tentar quebrar o mais rápido possível.

Os nossos hábitos estão enraizados a nossa cultura de desenvolvimento . Eles providenciam um meio confortável para desenvolver software com nossos colegas. Identificar que hábitos promovem ou não um desenvolvimento mais eficiente é um passo importante para melhorar nossa produtividade.

1º - Falar “sim” para tudo.

Deixe-me começar dizendo que é admiravelmente humilde e altruísta dizer sim a tudo. Isso significa que você está disposto a ajudar outras pessoas, provavelmente às suas próprias custas.

Mas dizer sim a tudo é um enorme matador de produtividade. No final do dia, você provavelmente precisará entregar algum código.

Não estou dizendo que você não deve ajudar outros desenvolvedores. Só estou dizendo que isso não deve matar sua produtividade. Alguns desenvolvedores tendem a fazer muitas perguntas - para cada pequena coisa que eles vêm à sua mesa pedindo ajuda.

Paulo Coelho acertou em cheio quando disse:

1
Quando você diz "sim" aos outros, certifique-se de não dizer "não" a si mesmo.

Se você tiver dificuldades em dizer não, isso poderá ajudá-lo se você deixar as pessoas chegarem à sua mesa em determinados momentos - dando a si mesmo um “tempo de foco” onde você poderá realizar algum trabalho.

Isso também força outras pessoas a começarem a procurar uma solução antes de marcharem cegamente para sua mesa. Se eles realmente não conseguem encontrar uma solução, eles podem escrever a pergunta ou o problema. Eventualmente, eles aparecem com uma lista de perguntas em sua mesa. Isso economiza muito tempo, porque você será interrompido apenas uma vez em vez de ser interrompido por cada pergunta da lista, uma por uma.

Esta primeira dica é mais orientada para desenvolvedores senior. Envolve uma certa complexidade na análise do que deve-se ou não atender e quando atender.

O ideal é explicar a equipe o impacto destas “interrupções” no trabalho e definir um método para que cada um avalie melhor qual o melhor momento e que outras fontes deve-se utilizar.

Em algumas equipes eu oriento como deve-se avaliar e tirar uma dúvida e também promovo uma “hierarquia” para tirar estas dúvidas.

Um colega meu foi mais radical colocou uma placa de “Não pertube” sobre o computador dele.

Um exemplo é um colega júnior chega com um problema trivial de negócio, você sabe que ele pode chegar na resposta mas pelo perfil dele ele vai demorar 4 horas. Você pode diminuir para 2 minutos este tempo, ou seja , você vai dar um ganho para equipe de 4 horas de trabalho deste colega, mas vai perder os 2 minutos da explicação mais o tempo que você vai gastar para focar novamente no trabalho que estava fazendo e vai motivar ele a parar. , mas por outro lado ele não consegue responder a questão pois não ter lido o manual do usuário da aplicação. Uma opção que tem é não responder a questão mas informar que a resposta está no manual o que vai fazer ele ficar algumas horas lendo no manual, ou dar a resposta, e orientar para ele ler o manual, neste ponto vale a avaliação que se faz do profissional o que vai orientar a melhor forma de agir.

2º - A sua definição da palavra “pronto”, possivelmente, não é pronto, na verdade.

A razão pela qual a definição da palavra “pronto” difere para desenvolvedores e outras pessoas é provavelmente que eles têm 10.000 outras coisas para fazer. Ao trabalhar em uma equipe ágil, por exemplo, os desenvolvedores desejam finalizar o sprint. Isso está dentro de um prazo estrito. Os desenvolvedores sentem que não têm tempo a perder.

Embora a definição da palavra “pronto” seja diferente, ela provavelmente inclui mais do que apenas escrever um pedaço de código para um recurso sofisticado. Sempre que você pensa que terminou, deve levar pelo menos as seguintes coisas em consideração.

Você refatorou seu código? E se você der uma olhada crítica no seu código, você acha que outros desenvolvedores o entendem? Se a resposta para uma das perguntas acima for “não” - corrija-a!

E a documentação? É necessário para esse recurso? Você deixou o testador saber como o recurso pode ser testado? Existem pré-requisitos que o testador precisa conhecer?

Informar ao testador como um recurso deve ser testado economiza muito tempo para vocês dois.

Você sabia que, de acordo com Gloria Mark, que estuda distração digital na Universidade da Califórnia, são necessários em média 23 minutos para retornar à sua tarefa original após uma interrupção?

Por último, mas não menos importante: você testou seu trabalho? Testando, quero dizer não apenas o cenário do caminho feliz. Falando em testes, isso nos leva ao próximo mau hábito.

Um abordagem aqui é trabalhar com a equipe um DOD - Definition of Done

3º - Não testar o seu próprio código.

A parte favorita de ser desenvolvedor definitivamente não é o teste. A maioria dos desenvolvedores é um pouco preguiçosa quando se trata de testar seu próprio código. Clicar no cenário do caminho feliz é provavelmente tudo que você obtém da maioria dos desenvolvedores.

Esse mau hábito levará muito tempo extra gasto na entrega do recurso correto. Se você não testar seu código, o testador provavelmente encontrará um bug dentro de um minuto, que você poderia ter facilmente farejado se tivesse acabado de testar seu código.

Quando o testador relata um bug, é necessário tocar no mesmo código novamente. Além disso, o testador precisa testar o recurso novamente depois de corrigir o bug. Isso não é muito eficiente em termos de tempo.
“Mas o teste aumenta o tempo de desenvolvimento.”

Não, não é. Este é um equívoco comum. O teste só aumenta o tempo de desenvolvimento inicialmente, quando você está começando a aprender como fazer o teste corretamente. Você deve cumpri-lo e torná-lo parte do processo de desenvolvimento para que ele se torne um bom hábito. Os testes pouparão muito tempo e dores de cabeça no futuro.

Este é um ponto muito importante , devemos efetuar todos os testes que esperamos que o QA faça. Para ajudar nossos esforços devemos automatizar os testes.

4º - Fazer commits gigantescos.

Um hábito muito ineficiente é tornar seus compromissos muito grandes. Compromissos grandes levam a não poder ver a floresta para as árvores. Como muitas coisas mudaram no commit, não está claro o que realmente mudou.

Além disso, como você se sentiria ao revisar um commit com mais de cem arquivos alterados? Você provavelmente estaria xingando. Você provavelmente se sentiria desmotivado ao revisar completamente o commit.

Commits pequenos são seus amigos. Eles possibilitam que o desenvolvedor forneça uma mensagem de confirmação descritiva. Sinto muito, mas “corrigimos alguns problemas” não é uma mensagem de confirmação descritiva.

As revisões de código ficam mais fáceis com pequenas confirmações. Eles possibilitam revisar uma alteração de cada vez, dando ao revisor a oportunidade de entender o processo de pensamento do desenvolvedor.

Fazendo pequenas confirmações, seu código também fica mais fácil para depurar. É fácil reverter para uma certa confirmação para testar se um bug também existe lá. Depois de descobrir onde o bug foi introduzido, não há muito código que poderia ter introduzido esse bug, se as confirmações forem pequenas.

Isso o tornará muito mais eficiente, sem muito esforço.

Para isso deve-se dominar o git para efetuar a consolidação dos commits. O Fábio Akita tem um vídeo legal.

O Felipe Deschamps fez um ótimo vídeo o que me motivou trazer o artigo comentado.

Artigo original: 4 Habits That Make You an Inefficient Developer (https://medium.com/better-programming/4-habits-that-make-you-an-inefficient-developer-f4384c4b9df5)