The best programmers I know

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.

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.

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.

For others: if company mostly consists of devs, or God forbid management, like that - run asap and never look back.

Sometimes you also encounter documentation that you either don't understand, or maybe it's just poorly written, in those cases I'd say it fair to guess to keep moving forward. Afterwards you should probably stop and think: "Why did/didn't this work?" and build up your understanding.

I've been reluctant to learn frontend development and our framework of choice is apparently fairly well documented, but I don't even understand large parts of the terminology, why certain solutions work, or why some are more correct. So I guess, and I learn, but you need to keep iterating for that to work.

If you just guess, or ask an LLM, and doesn't question your guess later, then I can see the point of simply not recommending guessing at all. Mostly I think flat out recommending againts guessing ignores how a large percentage of us learn.

I see what they're saying with "don't guess" and I also agree with you. I'd phrase it something more like "explicitly acknowledge when you're guessing". It's fine to guess with the understanding that you might have to walk it back later if you weren't lucky. What's not fine is stacking guesses on top of guesses, and ending up marooned way out in maybe-land. "Maybe A, and then maybe B, and then maybe C... so it must be D." No, the chances of D for this reason are P(A) * P(B|A) * P(C|B)... ~= 0.

Also don't guess when it's easy to test. "Maybe divisorValue is zero" well slap a printf() in there and see if it is! Often you don't have to guess. I've seen discussions go round in circles for hours asking "what if it's X" when it'd take 2 minutes to find out if it's X or not.

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.

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.

I think this is what the author meant by dividing complex problems in sub problems that are easier to tackle.