The best programmers I know

> Read the Reference

> Don’t Guess

I find that, when working with a new "thing," I often like to guess for about an hour or so before I really do a deep dive into the reference. Or, I'll read a stackoverflow answer or two, play around with it, and then go to reference.

Why?

Often there's a lot of context in the reference that only makes sense once I've had some hands-on time with whatever the reference is describing.

This is especially the case when learning a new language or API: I'll go through a tutorial / quickstart; "guess" at making a change; and then go back and read the reference with a better understanding of the context.

BTW: This is why I like languages and IDEs that support things like intellisense. It's great to be able to see little bits of documentation show up in my IDE to help me in my "guess" stage of learning.

>> Read the Reference

>> Don’t Guess

> I find that, when working with a new "thing," I often like to guess for about an hour or so before I really do a deep dive into the reference. Or, I'll read a stackoverflow answer or two, play around with it, and then go to reference.

I think that's fair. I've definitely seen "not best" programmers only guess and only read stackoverflow, over and over, forever, and never read the reference. They have no idea what's going on and just spin making a mess in until something sticks. I kinda read that item as a response to people like that.

The trouble is that there is a strong correlation between being able to design good interfaces and being able to prepare good documentation. Meaning, where guessing fails, the reference is bound to also fail due to inaccuracies or failing to communicate what you need to know. Which stands to reason as both require concern for how the user perceives the product. That is a skill in its own right.

In practice, so many times I've spun my wheels thinking I just didn't understand the reference only to find out that there was a bug or change that invalidated the reference. Nowadays, if I must interface with a product built buy someone who doesn't understand the user, I'll go straight to the source code if guessing fails or resort to probing the system if code isn't available. Not only is it faster, but you'll gain a better understanding of what is going on than some stumbling attempt to describe it in natural language will ever be able to communicate.

Say what you will about Windows development, but back in the 90's the MSDN reference documentation that Microsoft shipped for Win32 and MFC was quite good. Almost gold standard good. That, plus Petzold and Prosise, and you pretty much could answer any API question you had without even going online.

Yet, we had engineers who would still just hunt and peck and stumble guess until they either accidentally got it working or they'd ask a more senior guy for help (who would always first say: did you read the documentation?) There was no excuse back then, the documentation was good and accurate, and if you followed it, it worked. Were there hidden dark corners of Win32? Sure, but the 99 percentile developer never needed to even go near them.