Skip to content
Swizec Teller - a geek with a hatswizec.com

The code is not the goal

Telling engineers that what code their does is more important than what it looks like is a lot like saying dark mode is cancer. I feel it in my gut to be true, but expressing it just right eludes me forever.

5vJxcTt

👆 me when I say either of those things

Dark mode is like pointing a bright spotlight at your face, thinking "Oh gosh that's too bright", and putting sunglasses on it. You know, instead of using the damn brightness setting.

Ok that was easy 😛

Explaining why it's most important for your code to achieve business objectives is harder. I've had many conversations with friends and internet strangers over the past 3 days.

Here's a recap

Click through for source
Click through for source

Maybe engineers fundamentally don't want to realize that what their code looks like isn't nearly as important as whether it gets the job done.

The usual argument goes something like, and I quote straight from a reply to my email,

I don't want to maintain any code that was reasoned to win few races, while the one reasoning was still interested about the project before moving on to some other "race". Stupid analogy that'll appeal to the lazy-minded, and is way too often used as an excuse for subpar Architecture. Don't win a race, win a marathon!

Dude's right. Maintaining bad code sucks.

But I think something a lot of folks fail to realize is that it is a luxury to have a product with a codebase so bad it makes you pull your hair out.

The product survived!

Yes it’s a big hairy mess now, but it lives

You now have the ability to fix it. You know where the design went wrong, you know where the traps are, you know what you want

that is wonderful

Most terrible architectures, in my experience, aren’t terrible because the code is bad or the engineers sucked.

They’re terrible because the whole product was still trying to figure out what it even wants to be and do.

It’s easy to look back and say "that is bad"

It is impossible to look forward and say "that will be bad".

Click through for source
Click through for source

Here's an old programming maxim

Make it work, make it right, make it fast

Your code has a job to do. It needs to work first. Then if it works well enough, you might get time to make it beautiful and fast. Iff that is important to the business.

Sometimes it isn't and that's okay.

Another analogy we came up with in a Slack group is that of a commercial kitchen. High pressure environment with tight deadlines where everything has to go just right to produce that perfect meal.

A lot like an engineering org.

First thing Gordon Ramsey does when saving a failing restaurant 👉 make the kitchen run smooth. If your kitchen is dirty, disorganized, and a huge mess, your restaurant will fail.

If your engineering is dirty, disorganized, and a huge mess, your company will fail. No doubt.

But your code is not your engineering org. Your code is the product.

An engineer worrying too much about perfect code is like a chef placing peas one by one on a plate of bangers and mash to make sure it looks perfect.

That's not a chef, that's a food photographer. Takes them 5 hours to make a burger for 1 photo shoot.

Would you wait 5 hours for the perfect burger at your local pub?

Of course not. That's ridiculous.

My main point is this 👉 the code is not the goal. Solving the problem is the goal.

Peace ✌️
~Swizec

Did you enjoy this article?

Published on July 31st, 2019 in Opinions

Learned something new?
Want to become a high value JavaScript expert?

Here's how it works 👇

Leave your email and I'll send you an Interactive Modern JavaScript Cheatsheet 📖right away. After that you'll get thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over my 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths.

Start with an interactive cheatsheet 📖

Then get thoughtful letters 💌 on mindsets, tactics, and technical skills for your career.

"Man, love your simple writing! Yours is the only email I open from marketers and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"

~ Ashish Kumar

Join over 10,000 engineers just like you already improving their JS careers with my letters, workshops, courses, and talks. ✌️

Have a burning question that you think I can answer? I don't have all of the answers, but I have some! Hit me up on twitter or book a 30min ama for in-depth help.

Ready to Stop copy pasting D3 examples and create data visualizations of your own?  Learn how to build scalable dataviz components your whole team can understand with React for Data Visualization

Curious about Serverless and the modern backend? Check out Serverless Handbook, modern backend for the frontend engineer.

Ready to learn how it all fits together and build a modern webapp from scratch? Learn how to launch a webapp and make your first 💰 on the side with ServerlessReact.Dev

Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com

By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️