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