At the end of the day, most of my life in IT is spent in problem solving. I've come to learn a few tips and tricks about solving problems.
1. Use View > Source and right click > properties to see the parts behind the visual display. When you can locate the parts, you can often identify the particular component that is running the show behind the scenes. I did this with RoboHelp today as I was trying to hack the "traditional - no skin" theme to change the default tabs and background of the nav pane.
2. If you're having trouble with a theme, go to the Author's home page. The author is the expert, and they often have a forum of questions. For example, I was having trouble modifying the pages that appeared in the navigation of the Freshy theme, so I went to the author's home page and found the answer in the first few questions posed on his site.
3. Site-search specific sites where you think the answer may be. I use the query site:wordpress.org/support keyword in my Google searches all the time to search the WordPress forums. Replace keyword with the word you're searching for. Or put a phrase in quotes. This search returns on hits on the site specified. Omit the http://, but include the www if the site has one.
4. Use Google Groups. You've heard of all those Microsoft and Adobe MVPs? They hang out in Google Groups. This is the next generation of newsgroups. Google has made it incredibly easy to join and interact with these groups. If you're troubleshooting Wordpress, definitely use the WordPress forums. Each application seems to have its lounge where the experts hang out.
5. Search the forums for your answer. If you've got a question, most likely another user already asked it on the forum. Poke around the forum for your answer. Actually, just reading the forum about a theme or application you're using can be helpful. You can learn a lot just by reading questions and answers, and that's why I suspect the veterans hang around on them. Of course for some apps there are listservs that can be helpful, like the Yahoo HATT listserv.
6. Come back to problems you can't solve. If I'm staring at the same problem without a solution, if I simply come back to it in the morning, the solution often presents itself immediately. I'm not sure what the rest does, but perhaps it allows me to approach the problem fresh again. I may have been stuck in one mode of thoughts, and the rest gives me a fresh start. (And when you find the answer, be sure to record it somewhere you can access later!)
7. Google your error messages. If you keep getting an error message, write it down, put quotes around it, and Google it. You'll usually find the answer.
8. Think of an alternative way of doing something. IT is all about workarounds. If you can't get it to work one way, you can probably find a jerry-rigged solution to get around it. Just keep trying, thinking of alternatives.
9. Be patient. This should probably be number one on the list, but don't expect problems to be easily solvable. Remember that problem solving is what makes IT so fun. If you can't figure it out at first, that's good. The reward is sweeter in the end (most of the time). Take a few deep breaths and don't bang on your computer or swear at your monitor.
10. Break large problems up into small ones. I recently tackled single sourcing with RoboHelp. There were about 15 different problems with the printed output, but I tackled them one by one with macro workarounds over the course of a couple of weeks, and by the end I overcame most all of them. Had I tried to do it all at once, it would have been impossible. Little by little, with patience, you can do wonders.
11. Break it down into little pieces and then build it back up, one by one. This is no doubt a meticulous method, but if you can somehow break down your system into little pieces and test the pieces individually, you can rebuild it one by one and find where it breaks.
What are your tips for problem solving technical problems? I'd be happy to hear them. In fact, this would probably make a good podcast.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in , API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.