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.

πŸ‘† 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

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

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 ✌️

Learned something new? Want to improve your skills?

Join over 10,000 engineers just like you already improving their skills!

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.

PS: You should also follow me on twitter πŸ‘‰ here.
It's where I go to shoot the shit about programming.