It seems common for developers to look for faults in established technologies when an issue is encountered.  As a developer struggling to learn an unfamiliar technology, it is easy to make mistakes.  These mistakes lead to frustration which, in turn, can lead the developer to blame the technology rather than taking the time to analyze the problem and identify the real issue.

Anyone can fall into this trap and I still feel myself being pulled by this temptation at times. When you are working with an established technology, it’s always necessary to realize that the problem is almost undoubtedly in your code, not the technology you are using. As we learn the technology and continue to increase our depth of knowledge, this temptation lessens with each problem encountered. Let’s take driving as an example.

When I was learning to drive, I was a poor driver (most teenagers are). To the frustration of my parents, I had several accidents, fortunately all were minor. After having an accident I was frustrated with myself for the mistakes I made while operating the vehicle. I didn’t have the gall to blame the vehicle, claiming faulty brakes or the steering went out… Sure, these were possibilities, but unlikely. It was much more likely that my inexperience in operating the vehicle led me to make poor driving decisions.

With this mind set I continued to drive and improve my skills through experience behind the wheel. Over time I built a kind of intuition while driving that helped me avoid those mistakes.  At some point I may realize that a different vehicle may be easier to drive, more suited to accident avoidance, safer, etc, but I can only come to that realization as an experienced driver.

So by taking this same stance when learning an unfamiliar technology, we can become better developers. Struggling through the mistakes and the frustration while gaining experience helps build the intuition of a top-notch developer. So, the next time you find yourself blaming the unfamiliar technology you are working with out of frustration, stop and think about it. Are you really frustrated by your inexperience or is the technology really to blame?

So let’s review some techniques that can help us when attempting to solve problems encountered with an unfamiliar technology.  I also covered several of the Agile practices mentioned here in my previous article, 5 steps to improving your development process.

Read the Manual

I can’t tell you how many times I have solved a problem by simply reading the portion of the manual describing the API I am attempting to use. This may seem like common sense, but unfortunately time constraints often seem to get the best of developers leading them to copy-and-paste Programming by Coincidence.

Isolate the Problem

While this may be an obvious approach to problem-solving, it may be easier said than done depending on your approach to development. TDD (Test-driven development) is a very effective technique to isolating the problem. If you know what you have already done is working as designed, you can be reasonably sure that the issue is isolated to the code just added. Now try to write a test to prove the issue with the newly added code which can drive you to the root cause of the issue.

Commit Regularly

Committing regularly to your VCS (Version Control System) is a necessity to obtain the benefits of continuous integration. This technique is also effective for allowing you to revert back to a working revision if you find yourself too far down the rabbit hole. I often use this approach to attempt various hypotheses to solving the problem. If a hypothesis proves incorrect, simply roll back and try the next hypothesis.

Logging is your Friend

I read an article recently on DZone by Bharath Ganesh that reviewed this basic principle. Look at the logs! While stack traces don’t always provide the most obvious indication of the issue, they at least give you something to search for. For an established technology, simply Google’ing the exception message will often provide at least an inkling of what the issue is related to.

Maintain a Positive Attitude

Sometimes this is easier said than done, but it is important to remain determined to solve the problem. This may require taking a break, discussing the problem with a co-worker, sleeping on it, etc.

What techniques do you recommend for problem solving with an unfamiliar technology?