True, although not knowing what needs to be optimized guarantees that you don't know how to optimize it :).

> knowing more about how to actually write optimized code can help you make more informed decisions earlier on in the development process.

Totally agree though, despite poking a bit of fun.

This is something that I've been decently good at for many years. If I had to give someone new to it advice, it'd be:

- learn how to repeatably measure your system without introducing too much overhead. If you get this wrong, you're going to end up tricking yourself into believing you've made an improvement but instead got lucky/unlucky.

- once you've found the repeatably-measureable hotspots, the optimization approach is going to depend dramatically on the problem domain. Optimizing for database disk throughput is different than optimizing for http server response-latency is different than squeezing more polygons into a frame in a game.

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. This applies to both parts. Maybe the way to measure what's happening in your network service is to use tcpdump to capture the raw packets and see that you're sending a bunch of small writes into a socket instead of a single big write (why is that a problem? :D). Or something like NVidia NSight can provide a ton of insight into what's happening on your CPUs and GPU frame-to-frame.

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.

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.