Is premature optimization the root of all evil? Casey Muratori, @cmuratori, programmer and performance nerd, with three takeaways: #1 - Performance experts can't clean up after the fact “The idea is I'm just going to delay optimization work. I'm just going to make whatever I'm going to make and clean up the mess later. You call in some performance experts and they go, "There's nothing we could do for you. Sorry." Why? Because you created a serial dependency chain. All of your code looks like: wait for a network request to come back, do something. Wait for a network request to come back, do something. And that serial dependency chain can't really be shortened without just rewriting it." #2 - Engineering teams must think about performance upfront "At the top of every operation, you need to figure out all the things you might want to ask a server for, ask for all of those things and then you do all of your processing there. You only create a chain of dependencies if you absolutely couldn't have determined what it was you needed to ask a server for." #3 - Hotspot code bases are designed, not a given "You have to engineer upfront for a hotspot code base that people can then optimize. The crucial takeaway is everybody on your team who is making architectural decisions, those people must know performance. They must make decisions that will allow the other people downstream of them to use an architecture which can be optimized later. If you don't do that, you're just rolling the dice.”