Performant code is usually well architected code
Summary
Well-architected code and performant code aren't opposing forces—they're the same thing. Simple, readable code that follows architectural principles typically runs fast on standard hardware; complexity like excessive factories and microservices creates slow, unmaintainable systems.
Key Takeaways
- Prioritize simple, readable code as your default. It's usually fast enough on most hardware and leaves room for optimization later without architectural debt.
- Over-engineering with multiple design patterns (27 factories, 8,000 microservices) creates a false architecture that's slow, hard to read, and difficult to modify simultaneously.
- Aim for 'close enough' performance, not theoretical maximum. This prevents premature optimization while keeping the door open for future performance improvements.
- Design your code structure to allow performance optimization later. Good architecture means someone can boost performance without rewriting the foundation.
- Reject the false dichotomy between readability and performance. Code that's easy to maintain and easy to read almost always performs better than over-abstracted alternatives.
Related topics
Transcript Excerpt
What does good code mean to you, specifically? >> I have never really understood the sort of mentality of there's a difference between code that is well architected by some principles and code that runs quickly. Because in my experience usually the code that is architected properly is also the code that runs quickly. Most of the time, assuming you just want code that runs pretty darn well on most hardware, the simple, readable version of the code is actually very fast. It's only once you think you need to have [music] 27 factories and 8,000 microservices and all these things running that it starts to be this thing that's like good architecture but also hard to modify, hard to read, runs slowly, right? All these things. So, I tend to think good code, there's like this nice nexus of runs pre…