3 ms·

I've seen this advice many times before. While I do generally agree, it can easily become an excuse for not thinking things through from the start. If you hav

I've seen this advice many times before. While I do generally agree, it can easily become an excuse for not thinking things through from the start. If you have the wrong architecture it might be very difficult or even impossible to optimize performance later on. Also: If working on a project for a client, performance can be difficult to sell when the feature already works. But that feature might break when it's put under load. My advice would be to always have performance in mind. But otherwise to stay away from "optimizations" until they are needed.

jacquesm 5y ago
It's older than me. Thinking things through from the start is harder than it may seem for some classes of problems. Frequently the 'right' solution is several levels of insight removed from the ones that you will be able to achieve if you just sit down and 'think things through'. Only after you build it, benchmark your code against a large body of input and verify correctness will you have the appropriate insight required to really solve the problem. God level programmers (of which I've met exactly one and know about one other over my whole career) can do this the first time around.
- jeppester 5y ago
  You are absolutely right. It was not my intention to claim that you will get things right the first time if you just think hard enough. Iteration is needed very often. What I've seen many times is "best practices" like this being thoughtlessly applied. A react component that rerenders 20 times, but passes the test. A database with no indices, no problem (until the number of records grow). Things like that can easily be defended with "no need to optimise prematurely" or "I wrote the least amount of code to make the test pass".
  - jacquesm 5y ago
    Indeed, in that context your comment makes good sense. What helps in those cases: to have a good idea of how long you think something should take and then to verify that it indeed is within an order of magnitude of that first estimate. If it is much slower you are probably in trouble, if it is much faster than you will have to check if you are really doing all the work that you should be doing. Colin Wright (also on HN) wrote: "You can't make computers faster, but you can make them do less work". The corollary is that if your program is faster than expected that may be because it is doing less work!

jacquesm 5y ago

It's older than me. Thinking things through from the start is harder than it may seem for some classes of problems. Frequently the 'right' solution is several levels of insight removed from the ones that you will be able to achieve if you just sit down and 'think things through'. Only after you build it, benchmark your code against a large body of input and verify correctness will you have the appropriate insight required to really solve the problem. God level programmers (of which I've met exactly one and know about one other over my whole career) can do this the first time around.

jeppester 5y ago
You are absolutely right. It was not my intention to claim that you will get things right the first time if you just think hard enough. Iteration is needed very often. What I've seen many times is "best practices" like this being thoughtlessly applied. A react component that rerenders 20 times, but passes the test. A database with no indices, no problem (until the number of records grow). Things like that can easily be defended with "no need to optimise prematurely" or "I wrote the least amount of code to make the test pass".
- jacquesm 5y ago
  Indeed, in that context your comment makes good sense. What helps in those cases: to have a good idea of how long you think something should take and then to verify that it indeed is within an order of magnitude of that first estimate. If it is much slower you are probably in trouble, if it is much faster than you will have to check if you are really doing all the work that you should be doing. Colin Wright (also on HN) wrote: "You can't make computers faster, but you can make them do less work". The corollary is that if your program is faster than expected that may be because it is doing less work!