Hacker News Reader

Comment by jacquesm | Hacker News Reader

An old mantra that has served me well: first make it work, then make it fast.

So first get it to 100% compatibility, then, and only then concentrate on performance. Because if you don't do it that way you will end up foregoing compatibility because you'd have to say goodbye to your beautifully tuned code that unfortunately can't be 100% compatible. As long as it does not pass all the tests: it does not work. Even if it works for some selected cases, the devil is in the details, and those details can eat up performance like there is no tomorrow.

View on HN

I follow this advice with one small modification. Namely, mine goes:

    - Make it once.  
    - Make it right.  
    - Make it fast.

"Make it right" as the first step can trick an unseasoned developer into never finishing a prototype. I don't mind the first iteration of something being sloppy and then pursuing correctness with an existing solution to the problem in hand.

I'm curious if you've got a sense of the interplay between prototyping and correctness similar to your sense of the interplay between performance tuning and correctness? Any thoughts?

Yes, for green work that is a good scheme. I always joke I must be exceedingly stupid because I have to do everything three times before I get it done.

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.

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.

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".

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!

The coreutils consist of many individual binaries ('utils') which are more or less stand-alone[0], so I think this mantra doesn't apply here.

[0] https://github.com/uutils/coreutils/tree/main/src/uu

It absolutely does. Each utility is a program all by itself and the compatibility tests apply to each and every one of them. How fast they are is not relevant until they are 100% drop in replacements.

It might not apply for the whole project, but it certainly does apply for each individual per-command functionality (cp, mv, or even the general cross-command features like the filesystem interface).

It does, as many times as there are binaries.

Now that is something I fully agree with.

Reply on news.ycombinator.com