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
It's funny, every time I try to articulate this idea it kind of falls flat. 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.
โ Swizec Teller (@Swizec) July 29, 2019
I will continue trying https://t.co/f499MwAqA9
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".
โ Roman Kopaฤ (@rkopac) July 29, 2019
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
Continue reading about The code is not the goal
Semantically similar articles hand-picked by GPT-4
- 4 years of coding in San Francisco, lessons learned
- Better is good
- Let small fires burn
- What's more productive, a team or a talented soloist?
- What's your code for?
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below ๐
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails ๐ on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open 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. ๐"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help ๐ swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers ๐ ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
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 โค๏ธ