Tag: development

With the vast amount of information available on the web today, it’s no wonder that most developers use it as the first go-to source for coding assistance.  The entry points may differ (e.g. Google search, Bing, stackoverflow, or others), but the intent is usually similar (I am stuck on a technical problem; I don’t know where to start; I would like to expand my knowledge on …).

That’s all well and good, but, for the novice developer, this may set a dangerous pattern of usage.  For much of what we get when we search the web for solutions are pieces of information without much context – or with widely varying context.  Gone are the days when the “how-to” book, or the language reference guide, or the system manual is the first item reached for when assistance is needed.  Those items tend to provide much more context for usage than the fragmented responses from web searching, but they often required a bigger investment in time and patience.

I recall when I first got into programming that I always had my “The C Programming Language – Second Edition” by my side, as well as my handy “vi Quick Reference Guide” and man pages for Korn shell scripting.  They were extremely valuable assets that provided the proper context I needed to help me understand which solutions worked best under which conditions.  I believe that having spent my software development adolescence  during the time of contextual references and how-tos helped to established a pattern of thinking that promotes solution composition, as opposed to solution replication.

Don’t get me wrong, there is amazing value in the collective knowledge of the web.  But picking the most appropriate parts out of that massive information repository, and then using it appropriately, takes some thought and becomes easier with experience.  It also helps to have a good grounding on how to think and apply knowledge.  There are strong temptations to apply a cut-and-paste workflow when applying web search results to a problem, that might look something like this:

have a problem -> search for problem -> get responses -> apply response 1 -> fail now -> apply response 2 -> fail now -> apply response 3 -> fail much later … -> rethink whole approach.

Instead I suggest a different approach, which involves some additional analysis of the problem and results.  It might go something like this:

have a problem -> determine desired solution outcome -> determine affected areas -> search for affected areas -> get responses -> analyze affect of responses -> chose effects that best align with desired solution outcome -> tweak/re-factor as necessary -> succeed a little later.

This approach may take a little more time, but should produce more resilient solutions in the long run.