Wanna see me ride a flamingo wearing a cowboy hat? You're in luck! That was my outfit for a deeply technical talk to 700+ people last month 🤘
The talk is about architectural complexity. The flamingo is fun. My goal was to share how structuring your code into self-contained modules makes many debates about code quality feel silly. They just don't matter.
Here's a high level summary generated by the conference AI. It's pretty okay but the talk is better. Lots of visuals.
Setting Up System and Separating Concerns
You should focus on how you set up your entire system, your architecture. React's JSX and CSS in JS caused similar concerns in the past. Separating concerns by business domain is a different approach.
Lego Sets and Building Process
The Lego super car from the 90s came in a big box with 1,300 pieces. You would sort the pieces into different boxes. The Saturn 5, my second Lego set, had 1,969 pieces and came in baggies. Building the Saturn 5 rocket was easier and more fun because the pieces were separated by stage, making it easier to find and build.
Modular Construction and Prefab Units
Modular construction is a new trend where entire pieces of a building are prefabbed and stacked on top of each other like LEGOs. It's cheaper, faster, and more convenient. Prefab bathrooms and kitchens are also available, making the construction process quicker and easier.
Architectural Complexity and Productivity
The new separation of concerns is button, modal, list, etc., and you have a component that is self-contained and fulfills the function and knows everything it needs to do. The reason people do this or the reason people are excited about this modularity is architectural complexity. High architectural complexity leads to a 50% drop in productivity, a three-time increase in defect density, and a 10x increase in staff turnover. The more time you spent working on more complex files, the less productive you were, and the more likely you were to make a bug.
Measuring Architectural Complexity
To measure architectural complexity, think of your code as a dependency graph. Elements of your code can be functions, classes, files, or constants. When these elements call each other, lines can be drawn to represent dependencies. However, when lines cross the code base, it increases architectural complexity and makes the code harder to understand. By grouping related elements and creating modules, you can identify natural modules in your code. Experienced engineers already think about code at a higher level, understanding the components rather than individual elements.
Car Engine as a Module
A car engine, like a module in your code, has a simple API. Air and fuel go in, and exhaust and torque come out. By treating it as a module, you can easily connect it to your code and achieve your desired task.
Architectural Complexity and Best Practices
Architectural complexity can be identified through a tool that draws a dependency graph. Jumbled code, excessive use of dot, dot, dot slash imports, and circular dependencies indicate architectural complexity. To fix it, organize code by business domain and ensure tightly coupled code lives together. Clean and validate inputs on module boundaries and use prop drilling to pass data. When in doubt, prioritize separating concerns over copy-pasting similar code. Following these practices will help avoid architectural complexity.
I liked the talk. Hope you do too.
~Swizec
Continue reading about Forget Bad Code, Focus on the System – React Summit talk
Semantically similar articles hand-picked by GPT-4
- Finding modules in a Big Ball of Mud with ChatGPT
- You do have time to build it twice
- Forget complicated code, focus on the system
- You can't fix the wrong abstraction
- Two types of complexity and their impact
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 ❤️