Some people are great at problem solving, others not so much. The people I meet that are good at problem solving always have one very important skill, the ability to break stuff down into its constituent parts. With practice, it can seem like they are making massive leaps of faith, but that is based on their experience. That experience came from breaking problems down and dealing with the little stuff. Here are some examples, including some you may not consider as classic problem solving, but illustrate the point.
Books: Ask somebody to write a book and they will crap themselves. The thought of writing a book is really daunting. Ask them to write a chapter and they might still be scared, but less so. Ask them to write a page and most people would probably grudgingly do it. A book is a collection of pages. If you can write a page, you can write a book. I’m not saying it’s a good book of course, but you get my point. So the problem of writing a book and be broken down into very manageable pieces.
Development: I’ve been involved in some really complicated development projects in my career. When you’ve finished, you take a look back and think, how the hell did we manage to do that? When you look at the individual bits, they are all pretty simple. The skill is breaking down that massively complex development into manageable chunks. The classic top-down or bottom-up approaches to programming encouraged this. Agile, when done properly, also encourages this approach of breaking down problems to small units of work, delivered on a regular basis. So the big problem is broken down to little bits, that get put together and you end up with something that seems bigger than the sum of its parts.
Infrastructure: When you are dealing with multi-tier architectures, finding the cause of a problem can be quite complicated. You get questions like, “this URL is not working, why not?”. Based on experience of your environment, you might know likely candidates, but if not, you may have to take the long route, which may look like this:
- Can I connect to the database?
- If I connect directly to the App Server, rather than via the web layer (Load balancer, Reverse Proxy, web server) does the application work?
- If I connect via the web layer, does the application work?
- If I connect from different network zones, does the application work?
Based on the answers to those questions, I will know which part of the chain is broken and I can look at that specific section and break it down further, eventually finding the root cause and getting the relevant people involved to fix it.
SQL Tuning: Looking at a 10 page execution plan is really scary. What is a plan made up of? Lots of individual steps that combine to form the whole plan. If you work your way through the plan in order, operation by operation, it is often very obvious what is going wrong. Typically, a bad cardinality estimate somewhere causes the optimizer to make a bad decision, which kind-of propagates up the plan. Fix that cardinality estimate, or help the optimizer by “shaping” the plan in a more sensible fashion and things often fall into place. If you get a chance to see Jonathan Lewis talking about SQL tuning and shaping execution plans, or Kyle Hailey speaking about his approach to SQL tuning, you will see they both focus on breaking stuff down to their constituent parts, and you will realise the “black magic” they perform is actually very doable by mere mortals like us if we take a consistent and meticulous approach.
Life is all about breaking down big and daunting tasks into smaller, more manageable tasks. You can either get used to it, or spend the rest of your life achieving nothing and wondering what magic button everyone else is using! 🙂
Cheers
Tim…
PS. I understand there are lots of ways to achieve a goal and successful people will find a way of working that suites them. 🙂