If nobody uses your abstraction, it's wrong.
Architects and urban planners call these desire paths – paths that develop in spite of their best carefully planned designs. People walk where they want to, not where you tell them to.
Engineers do the same with code and users do it with your UI. Nobody cares about your beautiful vision [name|], they just wanna get their work done. If your vision helps: great! If it doesn't: ignore.
The bitter lesson
The bitter lesson in software engineering is that messy fast iteration cycles beat careful upfront design.
— Swizec Teller (@Swizec) March 25, 2024
The bitter lesson in software engineering is that messy fast iteration cycles beat careful upfront design. Inspired by the bitter lesson in AI that the "throw more data at it" approach beats careful analysis and model building in the long-term.
"Beat" in this context means that fast iteration cycles deliver more working software faster. There's fewer bugs, users like using it more, and engineers find it easier to work with.
Yes that's not possible in every industry.
Medical devices and software are notoriously difficult to certify and require large upfront design costs. This is why consumers are starting to use airpods over official hearing aids – cheaper, easier to use, almost as good. And why there's an entire DIY movement for insulin pumps – consumers ain't got time to wait for your careful design and certification process. They want their problem solved!
This bitter lesson extends to all sorts of things you wouldn't expect.
The book How Big Things Get Done is all about how large scale projects benefit from fast iteration cycles and smaller more reusable designs. Think "how do we use one of 5 bridge designs here" instead of "how do we design the perfect bridge from scratch".
How Big Things Get Done posits that wasting time and resources on custom bespoke designs is how large projects fail. Better to take a known design off-the-shelf add a few iteration cycles, and get something good enough out there.
Yes you can't iterate on building a large bridge. That's what computer simulations and scale models are for. Shift left. Learn what's wrong earlier when it's cheap to fix.
But software is not a bridge. It's soft. We're always in the design stage! Iterate.
Design your code like a park trail
99pi has a great episode on how natural parks design trails.
Your favorite hiking path that naturally winds through the woods as if it's been there for eons? Designed! Someone built that for you. And made it look natural.
The trick trail designers use is to start with desire paths. You look for where people and animals want to walk, then turn it into a path. Reinforce the footing, make it safer, add some structure so it lasts, make sure to divert any water that would erode the construction, then see what happens.
Next year you come back, see where people walked off the path or cut corners and make adjustments. If you can't make it safe, put a large boulder in the way so people naturally don't wanna go there. If it works, make it the new official path.
Use that same approach when writing your code.
Build abstractions people want to use
Build a thing that works. See how it feels. Ask others how it feels. Observe.
Watch what people do not what they say. Doesn't matter how much they all agree your abstraction is beautiful and elegant if they don't use it.
Sit back. Do less. Wait until patterns develop. Don't try to guess. When others suggest an abstraction say "Let's wait a little, see what happens".
When it starts to hurt, when it becomes painfully obvious that you're doing the same thing over and over, then you make an abstraction. Take what everyone's already doing and make it official. Make it painless.
That's a winning abstraction. A rickety desire path made sturdy, easy to use, and well maintained.
Do that and you'll notice people naturally reaching for your abstraction. You put the abstraction where they're looking! No need for education, no need for grand announcements. Just the perfect abstraction exactly where it needs to be.
When your abstraction grows new desire paths, improve further. Iterate.
Cheers,
~Swizec
Continue reading about Architecture is like a path in the woods
Semantically similar articles hand-picked by GPT-4
- Own the outcome, not the work
- You can't fix the wrong abstraction
- The code is not the goal
- My favorite lessons from Pragmatic Programmer
- Path dependence or why existing code always looks bad
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 ❤️