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. :)
aaronbrethorst•9h 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•9h 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•5h 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•2h ago
Having some fundamental skill of designing performant systems is critical on a team.