Troubleshooting code is one of my favorite things. No, really! I find great pleasure in taking something broken and making it work again. I am challenged to employ my personality traits of dog-headed persistance, logical analysis and puzzle-solving ability. Of course, with any worthy endeavor, there are frustrations. But, the exhilaration of finding that missing tag, or misspelled word, or rewriting a function with fewer lines of code, is satisfying. But the main reason I enjoy troubleshooting is that it causes me to learn more.
When I begin to learn a new language, one of the first things I want to understand are the tools to troubleshoot my programming. Throughout my schooling, the most frustrating language I learned was ASP .NET. Having recently picked it back up again, I realized why I struggled. The textbook we used placed troubleshooting at least two-thirds of the way through the text. We covered the text chronologically, so for many, many weeks, if I encountered a problem with my code, I was limited in what I could do to resolve it. More than once, I simply scrapped the page (which is also not easy to do in Visual Studio) and started again. I felt that I was being robbed of the learning that results from identifying and resolving an error, no matter how insignificant that error might have been.
Recently, I have had the pleasure of encountering a variety of problems to troubleshoot. A long-time client finally had a failure of an elderly WordPress plugin that hadn't been maintained in four years. While devising a new work around to solve the problem in the quickest and least expensive way possible, I also discovered the server was still running an ancient version of PHP. Note to self: when doing website maintenance updates, also check PHP version. I'm not sure if the plugin would run with the updated PHP, but access to this particular website is critical at this time, as the organization has an impending conference. We are still working out little kinks, but we are mostly back in business.
The other issue was an HTML/CSS bug in a website I regularly follow. I was able to help interpret what was going on technically to other users, and offer some workarounds until the site owner was able to repair the problem. While I didn't implement any coding myself, the exercise in interpretting technical issues for a non-technically literate audience was worthwhile. As a freelancer, I cannot take my users level of knowledge for granted, and am always challenging myself to explain things in as simple a manner as possible without insulting people's intelligence.
I'm not going to go into the technical aspects of trouble-shooting in this post (hint, Google is your friend!), but rather offer encouragement that finding your own solutions is rewarding beyond having a functioning website, function or script again. When people ask me how to get better at coding, my basic answer is to break stuff. Making mistakes is inevitable. Being able to fix them shows you are well on the path of mastering the skill.