Over my years as a software engineer I have picked up a very helpful protocol for solving problems. It works for most problems and it revolves around breaking problems down into smaller and smaller pieces while having the overall problem act as a final goal. It goes something like this:
Now, I am kind of pulling this out from under my hat but I think you get the idea. Perhaps you might want to modify the steps but the principal idea is to keep things simple and this includes keeping the problem solving solution a simple one.
Notice in the graphic below it follows this general path but i have added two or three very important steps to the end and that is to test the solution and draw conclusions. I have also added the step of determining IF there is a problem: RE: coke vs classic coke.
"If there is no solution, then it's not a problem"... Seth Godin
one of my favorite quotes!
In a sense, it is similar to the approach I use in solving complex engineering and design problems. The big problem I need to solve is end goal, but it consists of many different issues. The trick then is to break down the end goal into the various components that will lead to the end goal. After identifying the components, I then arrange them in order of importance as they affect the end goal. Solve them following the hierarchy and checking each step in an effort to achieve the best possible solution. This is a circular process that can take several iterations, but it is a process that is easily applied to computer programs to save time -- and energy.
ha ha Yep..we use a similar flow chart to handle software tech issues...ha ha ha
I was a diagnostician, but I did study computer science as well. I have had a few times when a vehicle would come in on the hook. Customer said "I was just driving down the road and it stopped working". They ran out of fuel. I think you need fuel for the vehicle to run... Had once where I got a ticket saying that the pickup would slide back a few feet when parked on a hill. We just had a snow storm. It was under warranty, so my boss said to do something. I put in diff clutches. I had once where I got a ticket saying "looses oil pressure when engine is off". Not joking.
You left out one key step, and possibly the most important - evaluate the possible solution(s) to the problem. You should know in IT, esp when you start to add in business needs, project managers, time lines, cost constraints, technology constraints, future plans, that there are typically many solutions that can be taken to address the problem.
You've over complicated the experience, I know where you're coming from I have a First Class FCC license and 40 years in and out of electronic repair and theory, including computers. As a Naval Hull Technician, we were literally trained to repair things with no parts. hell we were at see, radio shack or the auto parts store wasn't around the next wave. We had two solid rules. 1.) If it ain't broke don't fix it, 2.) If it's already broke, you can't hurt it, everything else is fair game.
Troubleshooting in a nutshell!
Exactly!!! fixing things around your house are pretty much the same