Hacker News new | comments | show | ask | jobs | submit login

For the former, I always preferred Joe Armstrong's quote in Erlang and OTP in Action. “Make it work, then make it beautiful, then if you really, really have to, make it fast. 90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!”

It's the same idea as the Knuth quote, but gives you guidance over what to optimize for (rather than just leaving you with the idea you shouldn't optimize for anything). Beautiful code will oftentimes include an elegant, efficient algorithm. Many times I've found that when I've had a performance bottleneck, the fix also made the code more correct (not just on a performance standard, but things like "Oh...yeah, we totally didn't need that there" or "tweaking that to be faster also meant we just fixed a possible, if unlikely, race condition"), or more beautiful ("oh, we just removed a duplication of effort...that when called this way was turning an O(N) operation into an O(N^2) operation"); had I just adhered more stringently to those two, I would have had the performance already.




Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: