Ha! I’ll bet you thought this blog was dead. Well, in the words of Miracle Max, only mostly dead.
I’m in the process of reading a new programming book (well, not new to some … new to me). I’ll probably post a review in a week or so (yeah, right).
Anyways, it got me to thinking about some of the questions I’ve been asked in the past … and I’ve noticed a trend.
Often the questions are completely lacking in context.
The question itself is fairly straight forward and simple … “How do I do so and so?” And the answer is quite often just as simple … “Oh, that’s easy, just do this, that, and the other thing.”
The thing that is unsaid, however, is the CONTEXT of the question. After I answer such a question, I get to thinking … WHY did I just get asked that question?
More often than not, when I ask a few questions of my own about WHY they asked the original question, I get a significant amount of context … and, usually, it turns out they were trying to work around a perceived problem. Said problem is usually not a problem at all … but a misunderstanding of how the function works. Once I get more details about the problem, I can usually offer a better solution or explain the functionality in such a way that the problem is recognized as a feature and not a bug.
Oddly enough, this happens as much with co-workers as with customers.
What should you take away from this post? Two things mainly …
- When asking a question, make sure you provide enough context so the person you are asking can give you the best answer possible.
- When being asked a question … don’t take a simple question at face value … ALWAYS ask for the context so you can provide the best answer possible. This may frustrate some questioners, as it can delay delivery of the answer. In these cases (you’ll have to be the judge), provide a preliminary answer quickly … but follow up immediately with more questions so you can provide the best answer possible. Something along the lines of … “Well, you can do it many ways, way X is the easiest … but tell me a bit about the problem, maybe there’s a better way.”
These same concepts also apply to programming assignments (after all, a programming assignment is just another question you’ve been asked to answer … only the answer is a program). Before you jump into writing, or modifying, a program to solve a problem …. make sure you know WHY the change is being requested. You’ll probably find that many change requests are submitted because people don’t really understand the problem they are trying to get solved.
Providing context along with a question will make programmers and end-users happier in the long run.
Hope this little bit of wisdom helps you solve some problems in the best way possible.
David is a Principal Software Engineer for PTC, Integrity Business Unit. He cut his teeth on the S/36 and has more than 25 years of experience on the IBM i / System i / iSeries / AS400. He primarily works in Java and ILE RPG specializing in cross platform integrations. David has received the COMMON Distinguished Service award and was named an IBM Power Systems Champion. David is an active volunteer with the American Diabetes Association's Tour de Cure fundraising bike ride. He is currently captain of Team RED Chicago. David runs and maintains midrange.com. His personal blog is Geeky Ramblings.