You have to design it to perform; optimization speeds up hotspots in the design. But no optimization will make your app scalable or perform well under load. You can throw money at it by scaling vertically or horizontally, but that won't fix bad design (though it'll keep things going).
Don't obsess over this. Obsess over documenting your design decisions - why you decided one algorithm or pattern over another and why. Then _if_ after load testing you need to optimise you'll understand some of the tradeoffs you'll have to make (all decisions are tradeoffs).
I mean, I make a lot of money as performance specialist, but it's still a dumb waste when you see failing products and companies because their rockstar developers refused to spend 30 minutes thinking about how well their architecture and code performs. You can't fix everything later.
You don't have performance issues if you don't have a product that people want. :)
Also, it costs you VERY little to spend some brainpower to design your product to perform well. I honestly really don't understand why so many developers behave like it's physically painful to think for a bit before starting to bash out code.
Noone expects you to write microoptimizations, but applying basic knowledge learned in CS classes and knowledge you can read in blogs should not be physically painful. And you can do that outright at the start, at __NO__ cost to your development velocity.
My reading of "obsess over it" _is_ micro-optimisations which are a distraction if you've got no market fit
Then if you detect inefficiency you can optimize the code and not the architecture.
I am building something with this mindset now, hopefully it will work
Nothing to do with architecture - rather ensuring you understand what decisions you're making, what other options you might have and why you're choosing not to do something (eg opportunity costs wrt delivery v time optimising)
aaronbrethorst•6mo ago
Personally, I like Sentry. They have a pretty generous free tier and a great code/db tracing tool.
(And yes I see that the author lists ‘measure’ as their second point. I think they’re mistaken.)
ivanmontillam•6mo ago
This article cannot be read by software developers that still fall into premature optimizations traps.
Basically, you must be first experienced or this kind of advice will hurt your codebase.
atomicnumber3•6mo ago
In my career, the worst "oh shit this doesn't scale" problems have been encountered in systems that were grossly over-designed - to the point that development had a noticeable "tax" due to dealing with it - and then the first time they encounter actual load (a customer writes a tight for loop on our API, or a customer decides to make 100000 of our widgets via automation, etc) it immediately shits the bed because they had no idea something would need to scale along a certain axis.
And mind you, that's really no ding on the original devs. Except for 2 points: they'd been banging on about how big-brain the original architecture is, and now the unanticipated scaling axis is orthogonal to the one we had originally invested so much in scaling along and it's significantly hampered by it.
It's really just best to write something simple that works and just doesn't commit any obvious sins. Then when you learn your REAL requirements, it'll be easy to adapt the code to them.
izacus•6mo ago
Having some fundamental skill of designing performant systems is critical on a team.
aaronbrethorst•6mo ago