Here's a few common abstraction traps that suck you in, look like they improve your code, then turn into bad ideas as your system grows.
- DRY – do not repeat yourself is an important skill the industry encourages in beginners. It becomes a trap when you avoid repeating code that just happens to look similar. You want to avoid repeating semantic meaning, but don't worry about the code itself. If it's going to evolve in different directions, it's fine to repeat.
- Horizontal separation into layers based on technology looks great at first: You have a layer that cares about data, a layer for presentation, and so on. At first your code feels organized. But as the system grows into multiple business domains, horizontal separation leads to lasagna code where every update requires touching dozens of files and muddles your semantics. Why does invoicing code live next to content sharing?
- Hammer factory factory is a subset of aggressive DRY – you notice a pattern of repeated operations and create a factory. But the business semantics are different and now your factory is hard to use. Easiest to spot when a bunch of boolean arguments show up to configure your function, class, or component.
- Util files feel like the natural place to put small utilities that everyone needs. Want reusable code? You know where to find it! But this leads to code that reaches across business contexts, ties disparate domains at the hip, and has little to no indication of purpose. Utils are a breeding ground for spooky bugs where changing one part of the system breaks code you've never heard of.
- Lots of small functions is a common pattern for engineers who swing towards the Do One Thing and Do It Well principle. You get lots of small functions, classes, or components that can't do anything meaningful on their own. Every business operation assembles a bunch of these into a chain, which leads to fragile code that's hard to work with.
Aim to write abstractions based on intent instead of implementation. The implementation will change but the "invoice customer for service" goal will not.
One way to measure this is architectural complexity.
Cheers,
~Swizec
Continue reading about Common abstraction traps
Semantically similar articles hand-picked by GPT-4
- Say no to abstract code
- You can't fix the wrong abstraction
- DRY vs SoC, a difficult choice
- Forget complicated code, focus on the system
- Why even care about code structure
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 ❤️