“Excellence is never an accident. It is always the result of high intention, sincere effort, and intelligent execution; it represents the wise choice of many alternatives – choice, not chance, determines your destiny.” – Aristotle
We all want to be excellent 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 a JavaScript developer’s excellence is a hard thing to do.
What makes for an excellent JavaScript developer?
There are a lot of criteria we could use to guide our decision.
The quality of code, always delivering on time and solving tickets in record speed are a few options. Helping other team members with their tickets could also be taken into account.
I think none of the above provides an accurate measurement. Writing a beautiful code masterpiece but delaying the project for 2 months because you just had to refactor everything doesn’t help anyone. And we all know that closing tickets don’t mean anything.
There are so many variables to consider. I’m sure that if I asked 10 different programmers what they thought makes an excellent developer, I would get 10 different answers.
I’m sure you’re thinking about your definition right now too.
I’ve been struggling with this definition for some time, so I decided to try and figure it out.
Down and Dirty
I want to find something that all developers do. I would then be able to categorize a developer’s performance based on “how” they do it.
Basing an entire profession’s excellence measurement on one activity is overly simplistic. But I’m going to do it anyway 😃
Now is the time to take your grain of salt.
I’ll try to make sure the activity I choose is a good one. It needs to be something that every developer does, but still separates the pros from the schmoes.
All developers write horrible code sometimes
Let’s face it, You and I both know that from time to time we all end up writing truly horrible code. Shameful code. Code that we hope no one will ever see.
We all have our reasons for writing terrible code sometimes. I’m not going to argue what are justifiable reasons for writing horrible code, just that we all have them.
Before we perform our little coding atrocities, we go over our list of reasons. We then shut our noses to prevent the code smell from getting in, and get to it.
A few common reasons for writing horrible code
1. Need to ship 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 accessories to this crime.
2. A drop in a sea of misery
The existing codebase is so horrible that you just don’t feel like making any effort into writing something decent. You know that there’s nothing you can do to save this awful codebase to from collapsing into itself at some point.
3. “I just need to do this one thing and move on”
As developers, we sometimes find ourselves coding on foreign land. Imagine you need to drop in a few lines of code in a different project. Not something big enough to bother anyone.
The guy who actually knows the project is on his day off, no one else is available to code review. You commit, push and pray that there are enough unit tests to keep you safe.
Getting Real
So we all write horrible code sometimes. Does that make all of us bad developers?
Of course not. Since everyone does it on occasion, the activity itself doesn’t indicate anything. However, over the years, I’ve come to find this one surprising truth about developers.
How we behave when writing horrible code is the ultimate litmus test for developer competency.
It’s weird but it’s true. Being aware that the code you’re writing right now is horrible, and the actions you take to prevent it from happening in the future, tells a lot about how you code and how you treat code in general.
What does horrible code have to do with measuring developer excellence?
A lot.
Let’s take Ron as an example. Ron wrote horrible code today. Ron was not happy about it. A nasty 5 level deep Backbone Model inheritance chain prevented Ron from changing a single line of code without breaking everything.
Ron bypassed the issue by writing seriously horrible code. Everyone was happy because Ron delivered on time. Everyone except Ron.
He spoke with his team leader about what had happened. Together they went back and forth about how to solve this issue. They decided that breaking the inheritance chain into flat composable modules is the best course of action.
Ron then requested that time will be allocated for him to implement the refactor he and his team leader had discussed.
Roger also wrote horrible code today. He told his developer friend about he wrote this incredible hack that bypassed a monstrous 5 level deep Backbone Model inheritance chain. He managed to bypass the entire architecture, get his code in there and deliver on time.
Roger was very happy with himself. No further action is needed.
The 4 Classes of JavaScript Developers
You could take the attitude of developers towards writing horrible code and divide them up into 4 classes. Ranging from bad to excellent.
Tell me you haven’t run into all of these 4 developers at one point or another.
Barney – A Bad Javascript Developer
Barney doesn’t care that he’s writing horrible code. The only thing he cares about getting the job done and on time. Nothing else matters. If it works, it works.
Barney writes horrible code which sometimes hinders the entire project’s progress. While the code works, it breaks so many things along the way that it sets the project back. Barney doesn’t feel like he needs to learn anything new.
He already knows everything there is to learn about JavaScript in order to get things done.
Bill – A Mediocre JavaScript Developer
Bill is unaware that he’s writing horrible code. He’s following the team’s conventions and lint rules and thinks he’s doing ok. But he doesn’t take the time fully understand the entire project’s structure and how the different components interact.
The end result, unfortunately, is a pile of brittle mess.
Bill doesn’t consult with anyone before making huge design choices. He wings it. He read 3 blog posts a year ago and they have been guiding his decisions ever since.
I often say jumping into Bill’s code feels like a landmine. One wrong move and everything blows up in your face.
Roger – A Good Javascript Developer
We’ve met Roger before. Completely aware of the fact that he’s 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 writing that piece of horrible code.
Roger’s main fault is that he doesn’t try to change anything. He does what he’s been asked to do and does it well. But Roger would rather 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 he still has to write horrible code at times.
What sets Ron apart is that while he’s writing smelly code, he thinks hard how to make sure the situation doesn’t repeat itself. Not for him and not for anyone else. Ron figures out what type of refactoring is needed, and what methodologies can be changed or improved.
Ron then acts on his findings, taking action to put change in motion.
The Cold Hard Truth
I have a confession to make.
I’m Roger. But I’m also Ron. And I’m sure I’ve been a Bill without even knowing it on more than one occasion.
I honestly don’t think I’ve ever acted like a Bad Barney, but who knows.
We’re all moving back and forth on a continuum of excellence. Sometimes we’re mediocre, sometimes we’re 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 jump from mediocre to good requires that a developer will gain more knowledge and experience, among other things. But to make the leap from good to excellent you only have to change one thing.
Attitude.
“Remember, 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