--- > There's a common quote in the software world that you should "make it work, make it right, then make it fast." ... First, we *make it work*. In this step, you get something working. It should handle a basic case of the problem you're solving, but doesn't need to handle edge cases. Sometimes you might skip tests, sometimes you might make a mess. But you show that it *can* be done and figure out roughly what it will take. > Then, we *make it right*. This step is where you tighten up all the loose ends from the first step. Handle all the edge cases, test the code, clean up any messes, do any refactoring. The end result here is a working artifact that meets all the requirements. > And then, we *make it fast*. This is the step I see skipped all the time, and it's where you go back and speed things up. You do some profiling, see how things perform, then tweak and improve until you have satisfactory performance. --- > After you've gone through the trouble of making software right, if you have major performance problems, they are likely to be fundamental to the approach you took. You'll be able to speed things up somewhat, but major improvements will require more invasive and painful refactoring. ... The reality is that if you want to have a hope of making your software perform well, you have to think about performance from the beginning. You wouldn't start making the software without thinking about what correctness is. Nor should you start it without thinking about how to make it fast. --- > We don't need an aphorism to justify our work. We just have to remember that performance does matter (and is *part* of being correct for much software) and that it's a consideration throughout the entire process. - [View Highlight](https://read.readwise.io/read/01hb66xrbsrmkhn3ksq1n5qa77) ---