Semantic Internets Yeah, I'm an…

Common Principles to Solving Problems:

• Every time you look at something, ask yourself: “does this make sense”.   Seriously; I’m not kidding.
• Do not assume you know a solution until you have all of the details and understand the problem.  Assuming makes an ass out of you, me, your team, your project, your company, your school, your mom, your dad, your country, and the human race.
• Don’t listen to argue, listen to understand.  Ask questions to understand, not to accuse e.g. “Why would you do that?” vs.  “What are they key advantages to doing it like this?”
• Archive your email, use a tool to index/search it -  It is very bothersome when someone asks me a question and I search my email and find I have already answered it for them previously, it is even worse when I search my email and find they answered the question to me previously.
• Try and understand what you are doing.  Automatons and Drinking Birds can press buttons; you are more valuable than them because you can understand things.
• Understand the impacts of any changes that you make.  Don’t assume a small change will have a small impact.   If you do not understand the impact of the change you are making, get a coffee, then come back and think about it again.
• Everyone makes mistakes. – Just because someone said they tested it correctly, do not hesitate to retest.
• Don’t be a dick.  Good things happen to good people.  Treat everyone like you would like to be treated (unless you like it when people treat you badly, then you should seek counseling).   If people like you, they will not hesitate to help you out.
• Care about important things that matter, don’t care about things that don’t matter.  This sounds easy, the trick is learning to differentiate between the two.
• Doing the things that others don’t want to do will differentiate you.  Did Michael Jordan want to practice drills for 10 hours a day, hell no, he practice because he wanted to be the best.  Do things that others say are hard and don’t want to do, this will set you apart from the pack.
• Have Goals, Write Them Down, Look at Them – Do you want to be sitting in your same desk writing and testing code 20 years from now? I am guessing no. Do you have other goals? Have you ever bothered to write them down and think about them and visualize how to achieve them.  If you don’t you will be sitting here writing and testing code for the next 20 years.

Problem Solving Steps:

1. Understand the problem:

• What is the problem?
• What are the steps to reproduce the problem?
• What is the impact of the problem, when does it need to be solved?
• Why is it a problem?
• Is this a new problem or existing problem?
• Is there a baseline, or how should it behave?
• When did it start happening?
• Did it ever work?
• What components does it involve?
• What Data does it involve?
• Is it functional, technical, both, or unknown?
• Can you decompose the problem into its parts?
• What are the simple reasons the problem could have occurred?

Is it a functional problem:

• Do I understand how the process should work?
• Is the problem related to data?
• Is the problem related to timing, order, or sequence?
• Do we have a copy of the data that caused the problem?

Is it a technical problem:

• What locations or environment is it happening in?
• Do I understand what components are involved?
• Are there any steps to validate the environment?
• Run diffs of things that have changed.
• What tools do I have at my disposal to test this (remote debugging, soap sonar, ethereal, web service studio, benthic, toad, test harnesses, debug logs)?
• Look at logs before and after.
• Look at all of the log information available.
• Look at the code and data for yourself, don’t take someone’s word for it
• Research the problem online

2. Identify a solution to the problem

• If this problem has occurred before, check my emails to get details on it (Google desktop,  coppernic, ms search)?
• Is there a solution for this type of problem already (check KX, emails, project, account, and internet)?
• Is there a solution for a similar type of problem?
• What solution is the quickest and has the least amount of impact?
• Are there any creative solutions we have not thought of yet?

3. Implement solution (validate it works)

• Ensure that solution is agreed upon by peers, and superiors;
• If it is a production solution, it will need to be agreed by the client.
• Once the solution is in place make sure that the problem is gone.
• If anyone is impacted by the solution, do they need to be notified that it is fixed?

4. Identify what can be done better next time to avoid the problem.

• Did I send an email of the problem and the steps to solve it to everyone involved?
• Is the process documented correctly?
• Is the problem solving approach documented correctly?
• If there is change that could prevent this problem in the future?