Translation of Dor Tzur's February 23, 2016 article on thefullstack.xyz website
“Excellence is never an accident. It is always the result of strong intention, sincere effort and intelligent execution. She represents the wise choice of many alternatives – for choices, not luck, determine your fate. – Aristotle
We all want to be great at what we do. But few of us put in the time and effort to make excellence a reality. Being excellent is hard work, in any profession.
Measuring the excellence of a JavaScript developer is very difficult.
What Makes a Great JavaScript Developer?
There are a lot of criteria we could use to guide our decision on whether a developer is great or not: The quality of the code, the respect of the schedules, the processing time of the tickets…. born are just a few options. Helping other team members in their tasks could also be a criterion to consider.
I don't think, however, that any of the above provides an accurate measure of the quality of a developer. Writing a masterpiece of code, but delaying the project for 2 months because you wanted to refactor everything isn't going to help anyone, not even you. Likewise we all know that closing tickets to close tickets doesn't make sense.
There are a lot of variables to consider and I'm sure if I asked 10 different programmers what they think makes a great developer, I would get 10 different answers.
I'm sure you, too, are thinking about your own definition of quality measurement right now.
So since I've been struggling with this definition for quite some time, I decided to try and spend some time analyzing and understanding it better.
“Down & Dirty”
I had to find something that all developers do. To then be able to rank a developer's performance based on “how” they do it.
Basing the measurement of the excellence of the profession as a whole on an activity is too simplistic. But am I going to do it anyway? and I will try to reassure you that the activity I have chosen is good. This must be an activity that every developer does, while keeping positive things separate from blocking things.
All developers write horrible code sometimes!
Let's face it, you and I know that from time to time we all end up writing some really horrible code: Shameful Code. Code that we hope no one will ever see.
We all have our reasons for sometimes writing horrible code. I'm not going to argue about what are valid reasons for writing horrible code, because we all have them. So let's run through our list of reasons.
Let's stop our noses so as not to smell the smell of code and let's go:
Some common reasons for writing horrible code
1. The need to deliver on time
"Not enough time" is by far the number one reason for writing horrible code. Commitment to a client, a tight schedule, or a pending release are all crime scene props.
2. A drop in an ocean of misery
The existing code is so horrible that you don't feel like putting in the effort to rewrite something decent. You know there's nothing you can do to save this horrible codebase from collapsing in on itself at some point.
3. “I just have to make this edit and move on”
As developers, we sometimes find ourselves coding in foreign lands. Imagine that you had to write or modify a few lines of code in another project.
Of course the person with the actual knowledge of this project is on leave and no one else is available for code review. You 'Commit', Push' the change and pray that there has been enough unit testing to ensure a minimum of security and quality.
Getting Real
So we've all written horrible code. Does that make us all bad developers?
Of course not. Since everyone does it from time to time, the activity itself doesn't indicate anything tangible. However, over the years I have come to understand this surprising truth about developers.
How we behave when writing terrible code is the ultimate deciding test to measure a developer's competence.
It's weird, but it's true. Being aware that the code you're writing right now is horrible, and the steps you're taking to prevent it from happening again in the future, says a lot about how you code and how you treat code in general .
What does horrible code have to do with a developer's measure of excellence?
All !
Let us take a few examples:
Ron wrote horrible code today. Ron wasn't happy. A pesky 5th level inheritance problem in the Backbone model prevented Ron from changing a single line of code without breaking everything.
Ron got around the problem by writing code that seriously sucks. But everyone was happy because Ron delivered on time. Everyone…except Ron.
Ron talked to his team leader about what happened. Together they went back and forth on how to solve this problem. They decided that breaking the inheritance chain into flat composable modules was probably the best course of action.
Ron then requested time to allow him to implement the refactoring that he and his team leader had discussed.
Roger also wrote horrible code today.
He told his developer friend about the amazing hack he developed to bypass the 5th level inheritance problem. He managed to work around the whole architecture, putting his code in the right place, and therefore delivering on time.
Roger was very happy. No further action is necessary.
The 4 Classes of JavaScript Developers
We can take the attitudes of the developers above and classify them into 4 categories: from bad to excellent.
Barney – A Bad JavaScript Developer
Barney doesn't care that he may have written horrible code. The only thing he cares about is getting the job done on time. Nothing else matters. If it works, it works.
Yet Barney writes horrible code that sometimes impedes the progress of the whole project. Even if the code works, it breaks so many things in its path that it's a disaster in terms of regressions. Barney does not question himself and does not think he has things to learn. He thinks he already knows everything about JavaScript, enough in any case to advance the projects properly.
Bill – A Mediocre JavaScript Developer
Bill doesn't know he's doing horrible code. He follows team conventions and rules and therefore thinks he is doing everything right. But it doesn't take the time to fully understand the structure of the whole project and how the different components interact.
The end result, unfortunately, is a bunch of poorly structured and fragile code.
Bill does not consult anyone before making impactful architectural choices. He skims over the subject. He read 3 blog posts a year ago that have been guiding his decisions ever since.
I often say digging into Bill's code is like running through a minefield. One false step and everything explodes in your face.
Roger – A Good Javascript Developer
We have met Roger before. Completely aware that he is writing horrible code. He knows how the code would have looked if he was writing good code. He pats himself on the back and moves on to writing that horrible piece of code.
Roger's main flaw is that he doesn't try to change anything. It does what it was asked to do and does it well. But Roger preferred to leave things as they are instead of taking the time and making the effort to change them.
Ron – An excellent Javascript developer
Ron is an excellent programmer. But it still sometimes write horrible code.
What sets Ron apart is that while he's writing the smelly code, he's thinking about how to make sure it doesn't happen again. That it doesn't repeat itself for him, but also not for anyone else either. Ron thinks about what kind of refactoring will be needed, and what methods need to be changed or improved.
Ron then acts on his findings, taking action to set change in motion.
The hard truth:
I have a confession to make:
I am Roger. But I'm also Ron.
And I'm sure I've often left salty additions unknowingly on more than one occasion.
Honestly, I don't think I've ever acted like a bad Barney, but who knows.
We all come and go on a continuum of excellence. Sometimes we are mediocre, sometimes we are good or excellent. Always trying not to be bad.
It's who we end up being most of the time that defines us as developers.
Truth be told, the leap from mediocre to good requires a developer to gain more knowledge and experience among other things. But to make the leap from good to great you just need to change one thing: Attitude .
Remember that:
“before you can be great, you've got to be good. Before you can be good, you've got to be bad. But before you can even be bad, you've got to try.” – Art Williams
Translation of Dor Tzur's February 23, 2016 article on thefullstack.xyz website
