←back to thread

The best programmers I know

(endler.dev)
628 points kiyanwang | 1 comments | 09 Apr 25 06:02 UTC | HN request time: 0.202s | source
Show context
DeathArrow ◴[09 Apr 25 07:42 UTC] No.43629781[source]▶
I agree with all but one of his assertions.

>Don’t Guess

If you are working on critical software like code running in a rocket or medical device, sure, never guess is mandatory.

But I and many other people can be in a hurry. We have to or want to move fast where it matters. I don't have the time to research every single detail nor I am interested in knowing every single detail.

I am mostly interested in building something or solving a problem, I don't care about implementation details as much. Sure, some times details do matter a lot but it's a part of the job to have an understanding of which details matter more and which matter less.

So, I don't guess out of laziness, but because I have things that are more important and more interesting to do and time is a finite resource.

Many decisions can be reverted with minimal loss if they will be proved wrong in the future. Bugs can be solved with ease.

I'm not saying to move fast and move things, but learn how to do the right trade-offs and making educated guesses is a valuable tool.

So I would add another assertion to the the list:

Learn to value time, don't procrastinate, avoid analysis paralysis.

replies(5): >>43629821 #>>43629837 #>>43629951 #>>43629991 #>>43630026 #
rowanG077 ◴[09 Apr 25 07:52 UTC] No.43629837[source]▶
This. In fact a lot of what I do are guesses. And then check whether it works. I think if you don't work like this you will be completely paralyzed to achieve anything.
replies(1): >>43630161 #
1. jpap ◴[09 Apr 25 08:48 UTC] No.43630161[source]▶
Agreed; I do this all the time as well. I don't think it as "guessing" per se, I think of it as forming a hypothesis based on the intersection of my existing knowledge of the problem and any new observations [1], then testing it to figure out if the hypothesis was correct. If proven incorrect, the process helps me reform into a new hypothesis and the cycle continues until the problem area becomes clear enough to solve outright.

[1] By reading more of the code, RTFM, observing logs, tracing with a debugger, varying inputs, etc.