[michaelmior]

> The one very important thing to keep in mind though is that you're going to need to peel back the abstractions and understand what's happening under the hood.

I agree with this although I think it can sometimes be a red herring for those new to optimization. It's possible to spend a lot of time digging deeper when that's not really what's needed. For example, you might find a particular database query that's really slow and start looking at what configuration tweaks you can make to your database server. But maybe if you structure the application a bit differently, that query isn't necessary at all.

It's a great skill to be able to peel back layers of abstraction and continuing to optimize all the way down. But it's an equally important skill to be able to know what later really needs optimizing.

[tonyarkles]

Apologies for the super late reply, I was travelling.

I totally agree, and that’s where experience comes into play and building a more holistic understanding of how the systems you’re using actually work. If I had a slow query in, say, Postgres, the very first thing I would be doing is “explain analyze” to see what the query plan is and what steps the database will be doing to execute it. 98% of the time doing that will either give you insight into how you might restructure your query or which indices you need to add to make it faster.