Tradução do artigo de Dor Tzur de 23 de fevereiro de 2016 no site thefullstack.xyz

“Excelência nunca é um acidente. É sempre o resultado de uma forte intenção, esforço sincero e execução inteligente. Ela representa a escolha sábia de muitas alternativas – pois escolhas, não sorte, determinam seu destino. – Aristóteles

Todos nós queremos ser ótimos no que fazemos. Mas poucos de nós dedicam tempo e esforço para tornar a excelência uma realidade. Ser excelente é um trabalho árduo, em qualquer profissão.
Medir a excelência de um desenvolvedor JavaScript é muito difícil.

O que faz um ótimo desenvolvedor JavaScript?

Há muitos critérios que podemos usar para orientar nossa decisão sobre se um desenvolvedor é ótimo ou não: A qualidade do código, o respeito dos horários, o tempo de processamento dos bilhetes…. nascermos são apenas algumas opções. Ajudar outros membros da equipe em suas tarefas também pode ser um critério a ser considerado.
Eu não acho, no entanto, que qualquer uma das opções acima forneça uma medida precisa da qualidade de um desenvolvedor. Escrever uma obra-prima de código, mas atrasar o projeto por 2 meses porque você queria refatorar tudo não vai ajudar ninguém, nem mesmo você. Da mesma forma, todos sabemos que fechar tickets para fechar tickets não faz sentido.
Há muitas variáveis ​​a serem consideradas e tenho certeza que se eu perguntasse a 10 programadores diferentes o que eles acham que faz um ótimo desenvolvedor, eu obteria 10 respostas diferentes.
Tenho certeza de que você também está pensando em sua própria definição de medição de qualidade agora.
Então, como venho lutando com essa definição há algum tempo, decidi tentar passar algum tempo analisando e entendendo melhor.

“Para baixo e sujo”

Eu tive que encontrar algo que todos os desenvolvedores fazem. Para então poder classificar o desempenho de um desenvolvedor com base em “como” ele o faz.
Basear a medição da excelência da profissão como um todo em uma atividade é muito simplista. Mas eu vou fazer isso de qualquer maneira? e tentarei assegurar-lhe que a atividade que escolhi é boa. Esta deve ser uma atividade que todo desenvolvedor faz, mantendo as coisas positivas separadas das coisas que bloqueiam.

Todos os desenvolvedores escrevem códigos horríveis às vezes!
 

Vamos ser sinceros, você e eu sabemos que, de vez em quando, todos nós acabamos escrevendo um código realmente horrível: Código Vergonhoso. Código que esperamos que ninguém veja.
Todos nós temos nossas razões para às vezes escrever códigos horríveis. Não vou discutir quais são as razões válidas para escrever códigos horríveis, porque todos nós as temos. Então, vamos percorrer nossa lista de razões.
Vamos tapar o nariz para não cheirar o cheiro do código  e vamos lá:

Algumas razões comuns para escrever código horrível

1. A necessidade de entregar no prazo

"Não há tempo suficiente" é de longe a razão número um para escrever códigos horríveis. Compromisso com um cliente, um cronograma apertado ou uma liberação pendente são todos adereços da cena do crime.

2. Uma gota em um oceano de miséria

O código existente é tão horrível que você não sente vontade de se esforçar para reescrever algo decente. Você sabe que não há nada que você possa fazer para evitar que essa horrível base de código entre em colapso em algum momento.

3. “Eu só tenho que fazer essa edição e seguir em frente”

Como desenvolvedores, às vezes nos encontramos codificando em terras estrangeiras. Imagine que você tivesse que escrever ou modificar algumas linhas de código em outro projeto.
Claro que a pessoa com o conhecimento real deste projeto está de licença e ninguém mais está disponível para revisão de código. Você 'Commit', Push' a mudança e reza para que tenha havido testes de unidade suficientes para garantir um mínimo de segurança e qualidade.

Caindo na Real

Então, todos nós escrevemos códigos horríveis. Isso nos torna todos maus desenvolvedores?
Claro que não. Como todo mundo faz isso de vez em quando, a atividade em si não indica nada tangível. No entanto, ao longo dos anos, entendi essa verdade surpreendente sobre os desenvolvedores.

Le comentar como nos comportamos ao escrever códigos horríveis é o teste decisivo para medir a habilidade de um desenvolvedor.

É estranho, mas é verdade. Estar ciente de que o código que você está escrevendo agora é horrível, e os passos que você está tomando para evitar que isso aconteça novamente no futuro, diz muito sobre como você codifica e como você trata o código em geral.

O que um código horrível tem a ver com a medida de excelência de um desenvolvedor?

Todo !
Vejamos alguns exemplos:
Rum escreveu um código horrível hoje. Ron não estava feliz. Um incômodo problema de herança de 5º nível no modelo Backbone impediu que Ron alterasse uma única linha de código sem quebrar tudo.
Ron contornou o problema escrevendo um código muito ruim. Mas todos ficaram felizes porque Ron entregou no prazo. Todos... exceto Ron.
Ron conversou com o líder de sua equipe sobre o que aconteceu. Juntos, eles foram e voltaram sobre como resolver este problema. Eles decidiram que quebrar a cadeia de herança em módulos compostos planos era provavelmente o melhor curso de ação.
Ron então pediu tempo para permitir que ele implementasse a refatoração que ele e seu líder de equipe haviam discutido.
Roger também escreveu código horrível hoje.
Ele contou a seu amigo desenvolvedor sobre o incrível hack que ele desenvolveu para contornar o problema de herança de 5º nível. Ele conseguiu contornar toda a arquitetura, colocando seu código no lugar certo e, portanto, entregando no prazo.
Rogério ficou muito feliz. Nenhuma ação adicional é necessária.

As 4 classes de desenvolvedores JavaScript

Podemos pegar as atitudes dos desenvolvedores acima e classificá-las em 4 categorias: de ruim a excelente.

Barney – Um péssimo desenvolvedor de JavaScript

Barney não se importa que ele possa ter escrito um código horrível. A única coisa com que ele se importa é fazer o trabalho a tempo. Nada mais importa. Se funciona, funciona.
No entanto, Barney escreve códigos horríveis que às vezes impedem o progresso de todo o projeto. Mesmo que o código funcione, ele quebra tantas coisas em seu caminho que é um desastre em termos de regressões. Barney não se questiona e não acha que tem coisas a aprender. Ele acha que já sabe tudo sobre JavaScript, o suficiente de qualquer forma para avançar os projetos corretamente.

Bill – Um desenvolvedor JavaScript medíocre

Bill não sabe que está fazendo um código horrível. Ele segue as convenções e regras da equipe e, portanto, acha que está fazendo tudo certo. Mas não leva tempo para entender completamente a estrutura de todo o projeto e como os diferentes componentes interagem.
O resultado final, infelizmente, é um monte de código mal estruturado e frágil.
Bill não consulta ninguém antes de fazer escolhas arquitetônicas impactantes. Ele passa por cima do assunto. Ele leu 3 posts de blog um ano atrás que têm guiado suas decisões desde então.
Costumo dizer que cavar o código de Bill é como correr por um campo minado. Um passo em falso e tudo explode na sua cara.

Roger – Um bom desenvolvedor Javascript

Já conhecemos Roger antes. Completamente ciente de que ele está escrevendo um código horrível. Ele sabe como o código ficaria se estivesse escrevendo um bom código. Ele se dá um tapinha nas costas e começa a escrever aquele pedaço horrível de código.
A principal falha de Roger é que ele não tenta mudar nada. Ele faz o que foi pedido e faz bem. Mas Roger preferiu deixar as coisas como estão em vez de perder tempo e se esforçar para mudá-las.

Ron – Um excelente desenvolvedor Javascript

Ron é um excelente programador. Mas às vezes ainda escreve códigos horríveis.
O que diferencia Rony é que enquanto ele está escrevendo o código fedorento, ele está pensando em como ter certeza de que isso não aconteça novamente. Que não se repita para ele, mas também não para mais ninguém. Ron pensa sobre que tipo de refatoração será necessária e quais métodos precisam ser alterados ou melhorados.
Ron então age de acordo com suas descobertas, tomando medidas para colocar a mudança em movimento.

A dura verdade:

Eu tenho uma confissão a fazer:

Eu sou Rogério. Mas também sou Ron.

E tenho certeza de que muitas vezes deixei adições salgadas sem saber em mais de uma ocasião.
Honestamente, acho que nunca agi como um Barney ruim, mas quem sabe.
Todos nós entramos e saímos em um continuum de excelência. Às vezes somos medíocres, às vezes somos bons ou excelentes. Sempre tentando não ser ruim.
É quem acabamos sendo na maioria das vezes que nos define como desenvolvedores.
Verdade seja dita, o salto de medíocre para bom exige que um desenvolvedor ganhe mais conhecimento e experiência, entre outras coisas. Mas para dar o salto de bom para ótimo você só precisa mudar uma coisa: Atitude .
Lembre-se disso:

“Antes de ser grande, você tem que ser bom. Antes que você possa ser bom, você tem que ser mau. Mas antes que você possa ser ruim, você tem que tentar.” – Arte Willians

Tradução do artigo de Dor Tzur de 23 de fevereiro de 2016 no site thefullstack.xyz