"The Best Programming Advice I Ever Got" with Chris Sells
- Developer at Spanlink Communications, now a telephony division of Cisco
- Developer at Intel
- Instructor at DevelopMentor
- Principal Program Manager at Microsoft
- Vice President at Telerik
Most Notable Achievement:
Finishing up book #14but no more after this one!
Most Frequently Used Programming Language:
I’d say that the best programming advice I ever got was “don’t trust the docs.” I don’t know if it was explicit or implicit advice based on the behavior of my fellow instructors at DevelopMentor in the ‘90s, but this advice has led to my ability to sit down with any component, library, control, sample, or framework and figure it out.
That’s not to say that sometimes the docs aren’t usefulthey’re often a starting point. But too often I’ve read docs of the form “The GetZebras method of the Zoo class retrieves zebras.” From where? How many? What if I’m building and arc and I only need two, but they have to be in a male/female pair? Too often, the docs are written by non-developers that doesn’t have any more idea that I do what the GetZebras method does and the developers that do know didn’t take the time to write down what it does for anyone else.
So, how do I figure out what the GetZebras method does? In the old days when I was given the advice to distrust the docs, I would write 10s or sometimes 100s of tiny samples, filling my temp folder up with foo1.sln through foo452.sln (the solution auto-naming feature in Visual Studio is one of my very most favorite). Now, in addition to the clues that the docs may provide, internet searches reveal StackOverflow answers, blog posts and samples, which help narrow the number of samples I have to write to understand a piece of code down to 1 or 2.
Of course, you should be wary of the information from any source that you haven’t verified yourself, whether that comes in the form of official documentation or not. I guess the real advice is “trust but verify,” as President Reagan is famous for saying. I don’t believe he was a programmer, but he was certainly right about this.