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.