My favorite manager called this "the most important concept for a software engineer to grasp". How do you choose between DRY – do not repeat yourself – and Separation of Concerns?
This is fun because Do Not Repeat Yourself and Separation of Concerns are engineering maxims that we all parrot as essential rules of how software is built. But when they butt heads we get stuck because we understand the words, not the idea.
DRY – Do Not Repeat Yourself
DRY is the first rule every software engineer learns. My high school C professor loved to share this example from a parent-teacher conference. (yes I went to a weird school)
She once wrote an exam that said "Print numbers 1 to 5"
The student solved it like this:
printf("1\n");
printf("2\n");
printf("3\n");
printf("4\n")
printf("5\n")
And got an F. The parents complained. "Does this code not do what the question asked?"
Imagine the professor rubbing her temples in frustration. "Ugh yes, but it's wrong ... what if N was 100? Are you gonna add 100 more lines?"
"Yeah, that sounds easy. Would it not work?"
She was looking for something like this:
for (int i = 0; i < 5; i++) {
printf("%d\n", i)
}
You DRY up the print, make it take an integer parameter, and run the whole thing in a loop. Now there's only one place to ~~make a mistake~~ change when you want to update the output.
Separation of Concerns
Separation of Concerns is DRY's opposite cousin. It talks about detangling code so it can work in isolation.
Engineers learn this one by getting hit in the face with a shovel they left lying around. Unit testing and TDD are common tricks to encourage this practice. Can't test things in isolation if they're not isolated. 😉
The easiest tell that you need to separate concerns is when the word "and" sneaks into your description of a class, function, or component.
Imagine if sending an email also wiped your hard drive. You probably want different buttons for that ...
The superficial similarity trap
DRY and SoC are rules, ask anyone. Here's the nuance people miss: They aren't talking about code.
These are conceptual rules. You have to DRY concepts, not code. Same with separating conceptual concerns. Sending email and wiping drives need to be separated, but "turn off lights and music" is a perfectly sensible operation to perform when you leave the house.
Here's an example we're dealing with at work.
You have two database tables, they look like this:
Two tables, different names, same columns, both with a many-to-many relation to appointment types. Should you DRY them up?
NO!
That's the problem we're dealing with. Years of this being DRY because it looks similar and now it's a pain to detangle.
"Service Line" and "Care Type" are different concepts. Despite superficial similarities. Service lines are a marketing concept that drives how appointments appear to users. Care types are a clinical concept that drives which providers can do what.
Focus on the concepts
Forget if the code looks similar. Is it describing the same business concept? If yes, DRY. If no, separate.
Cheers,
~Swizec
Continue reading about DRY vs SoC, a difficult choice
Semantically similar articles hand-picked by GPT-4
- The code is not the goal
- DRY is a footgun, remember to YAGNI
- What I learned from Software Engineering at Google
- Forget complicated code, focus on the system
- My favorite lessons from Pragmatic Programmer
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 ❤️