Learning an unfamiliar technology is like learning to drive

Date August 4, 2009

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?

Enjoyed this post? Share it!

  • description
  • del.icio.us
  • Digg
  • Google
  • Technorati
  • StumbleUpon
  • Furl
  • Reddit

4 Responses to “Learning an unfamiliar technology is like learning to drive”

  1. crazydaysorg said:

    When picking up a new open source library, I will often find another project which uses the library for an example of how to use the library properly. Searching through other folk’s code certainly helps to understand how a library can be used.

  2. Vishwajeet Singh said:

    Great article I should say…. I really have experienced talking to coworkers help alot…even if they are not capable of solving the problem but it helps immensely to discuss as it changes your though process and you solve your problem on your own.

  3. Nirav Assar said:

    One thing I would add to this topic is that on any assignment, if a new technology is involved there might be added anxiety characterized by the fact a developer id unfamilar with new concepts or technology. This may manifest itself into blame of the technology. We can avoid this pitfall by allocating time on the job and away for research and really absorbing underlying principles and purposes of any new technology. This will give us added clarity and lead us to understand how to appropriately use a technology to get our job done. Basically, upfront know that there are things to find out, figure out and research, and this should alleviate some axiety and ultimately some undue blame.

  4. links for 2009-08-09 « pabloidz said:

    […] Learning an unfamiliar technology is like learning to drive solutionsfit.com | Jacob Orshalick (tags: learning) […]

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>