I’ve spent a lot of time browsing and participating in online technical forums. In my early years in the industry I asked a lot of questions, and as my skills grew I evolved to the point where I was answering more questions than I was asking. The questions and answers I encountered were quite varied, but there was one specific request I kept seeing:
“Please provide step-by-step instructions.”
There’s absolutely nothing wrong with asking for detailed help – in fact, I’ve been the recipient of such assistance in the past – but too often this type of request is made in the spirit of “I don’t care how it works, just tell me how to do it.” The problem with approaching challenges in this way is that it’s a never-ending cycle, creating a dependency on being fed by others. It’s like getting the answer key to a midterm exam; it helps right now, but doesn’t improve your ability to pass the next test.
Why Before How
I remember back in the early 2000s when I was learning object-oriented programming, mostly teaching myself with the help of books, online resources, and forum assistance. I recall spending a lot of time looking for the solutions to narrow problems (“How do I implement inheritance on this class?”) without regard to the bigger picture (“Why is inheritance important, and why does it apply to this problem I’m trying to solve?”). I spent an extraordinary amount of time chasing rabbits, and I’d routinely emerge from an hours-long troubleshooting session no closer to solving – or even understanding – the issue.
The problems we as technical professionals must solve today will look a little different than those we solve tomorrow and next week, so knowing how to address a specific problem domain without understanding it in context is a career-limiting mindset. Teaching someone how to implement restartability in a data warehouse ETL process is less important than teaching her why the concept of restartability is essential in a properly designed load architecture. A brand-new DBA with zero experience can be taught how to create an index in 5 minutes, but teaching him why indexes are necessary is a far more critical exercise.
A better approach is to understand the why before digging into the how. By taking the time to understand why things work the way that they do, why a particular design pattern is important, or why a system needs a specific feature will make us better equipped as technical professionals. There’s no getting around the fact that this approach takes longer, which is difficult for those of us who love to jump in and start solving problems immediately.
This is the approach I’ve started to steer my clients and mentees toward. For the larger audience of blog readers, I’ve started a new series on ETL best practices, which focuses less on how to solve specific problems and more on the reasons behind why key concepts are critical to get right.
Understanding why is an investment, but it is one that pays great dividends.
~~~
This post was originally published in my Data Geek Newsletter.
I was reminded of Stack Overflow as I read this article. The seasoned SO users often respond to questions with their own question (as a comment). For instance, “What have you tried so far?” Those users are usually pretty good about spotting the “I don’t care how it works, just tell me how to do it.” type of questions.
If I’m approached by someone that has no interest in “Why” and wants the “How” and nothing else, I may feel little incentive to help. But if I stop to think about it, hopefully I won’t be too hard on the questioner. He or she may show more interest in “Why” over time.
Great article, Tim!
It often reminds me of the people who wanted to copy my homework or cheat off me on a test. You’re more likely to get an answer you need “shooting the $#!+” when you don’t need the help!
I applaud your direction.
Nicely done. This is a lesson I wish that they would teach in MBA course work. It seems that the folks running a lot of the companies I work with get so confused about which should come first.
It’s interesting that one of the first questions we learn as children is, “Why?”, but it’s sometimes forgotten as we age. Engaging in busy work is easier than understanding the big picture.
It’s difficult to ask why in many work environments these days since it takes longer to absorb that information than it does to just fix the problem. So many companies don’t want to afford the time to learn the why, they just want the problem fixed or the objective met ASAP.
Personally I think it’s very important to learn the why so that one can understand why not under certain circumstances. Many times I’ve come into an environment where you see a so called best practice implemented which resulted in horrid performance because nobody understood the why in order to know why not in that specific scenario.
Kris, you’re right in that some companies care more about getting things right now than getting things right.