There is no right way; only wrong ways.

This post has a couple of intentions:

  • for myself to better understand my own philosophies, and to encourage discourse around them.
  • to convince junior-level developers, and perhaps those who suffer from Imposter Syndrome, to stop worrying and just do it.

And like the title suggests, I’m wrong about all of the opinions I express below.

“Decisions, decisions – all of them wrong.” — Tamal on The Great British Bake Off: Series 6: Episode 6: Pastry

While pair-programming with a junior programmer he asked why I solved a problem in a certain way. He wanted to know why the way I chose was better than the solution he was thinking of. Before providing a real and thoughtful answer, I quickly, and mostly sarcastically, responded with:

There is no right way; only wrong ways.

I realized one of the problems this new programmer was struggling with was that he was always trying to make sure his solution was exactly the right way to do something, rather than just try something that is technically terrible just to see if it’d work. He would repeatedly write a line only to just delete it before running the code, unsure if the code was “right” .

Of course, the idea that “There is no right way; only wrong ways” isn’t completely true; there are solutions that will return incorrect results, where a different solution would absolutely return the correct result — and in an appropriately performant way. However, I thought about it later and came to the realization that, in a way, the statement is true.

Let’s go back to 2009. I’ve read all of jQuery’s source code, every single one of John Resig’s blog posts, and follow Paul Irish, Mathias Bynens, and Addy Osmani on Twitter religiously. I’m not afraid of the IE6 double-margin float bug. I wrote my own benchmark software to specifically test which style of looping over an array was fastest in each browser (hey, micro-optimization was all the rage back then). My own Imposter Syndrome would have stopped me from telling you I knew how to built a front-end website as well as anyone, but I probably could, and probably did.

But what about now? Here in {{currentYear}}? How’s that award-winning code looking? It’d probably still work in today’s browsers, maybe, but would anyone look at it today and think “That’s exactly how that problem should be solved”? Are all those industry best practices I enthusiastically followed still considered the best? I’d wager not, and I’d bet that much of the code I wrote only 3 years ago would be atrocious to me now.

First do it, then do it right, then do it better - this is my mantra for successfully getting things done. It's all about the iteration.

Addy Osmani

What I love about Addy’s mantra is the implication that doing it right isn’t the best way to do it. Doing it best isn’t mentioned. Perfection is unobtainable.

What I’ve realized is that over my past decade+ of professional software development I’ve come to develop a philosophy where a focus on current best practices isn’t paramount. When starting out, this wasn’t obvious to me. Sure, learn about the new JS development pipelines. Strive for precision and accuracy in your code. Become knowledgeable in React, Vue, Moon, or whatever is next. Understand the styles, architecture, and design patterns being implemented by your peers. Become the ultimate Scrum Master. But just don’t be convinced that the patterns and methodologies given by the current tech landscape are the best and correct ways to solve your current problem.

Solve your problems in a way that provides the solutions you need now, in a way that is manageable for you and others in the future. Find a mentor. Ask for help. Have others review your code. Learn from others. Teach. Iterate. Be okay with being wrong.

For me, the most important best practices/principles I like to keep in mind are:

  • D.R.Y.*
  • Be nice; be honest
  • Readability > Cleverness
  • Ship it

Of course, these principles of programming are guidelines, not rules. Break them when necessary!

My favorite quote sums this all up nicely:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability.

— John Woods, 1991


* A note about D.R.Y.: don't over do it. It’s easy to over-apply DRY principles and end up with an unwieldy abstraction that's difficult to maintain.

Comments for this blog entry