←back to thread

The best programmers I know

(endler.dev)
628 points kiyanwang | 3 comments | 09 Apr 25 06:02 UTC | HN request time: 0.623s | 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 #
1. pmg101 ◴[09 Apr 25 07:49 UTC] No.43629821[source]▶
I quite agree. It's simply a slider isn't it, with "no time, no knowledge, pure guesswork" at one end and "infinite time, thorough analysis, perfect understanding" at the other end.

Clearly the left end is dangerous but the right end can also be, due to opportunity costs. Making a judgment on where the slider should be for each decision/change is a key skill of the craft.

replies(1): >>43630564 #
2. actionfromafar ◴[09 Apr 25 10:12 UTC] No.43630564[source]▶
I also find that my "context windows" can only hold so much. I can't understand everything all at once. So if I do very deep dives, I tend to forget (temporarily) other parts of the problem/stack/task/whatever. The solution for me is to create as much as possible as self-contained testable units. Not always possible, but something to strive for.

And I find that this skill of organising is the limit for how large/complex systems I can build before they become unmaintable. This limit has increased over time, thankfully.

replies(1): >>43630925 #
3. DeathArrow ◴[09 Apr 25 11:19 UTC] No.43630925[source]▶
I think this is what the author meant by dividing complex problems in sub problems that are easier to tackle.