The Dangers of Book Learnin'

Today’s software professional is under constant pressure to maintain a high skill level with an ever-changing palette of languages and tools, and the fear of potentially becoming somewhat irrelevant can be daunting.  Those that do not keep up with industry trends and movements are at some risk of losing marketability, but even those that do closely follow tech news need to make choices on which skills to pursue (time permitting), which to ignore, and what methods to use in the pursuit.

The first instinct to learn something new would naturally be to find some good resources online and perhaps acquire a couple books.  You can find presentation slides and videos, articles and blog posts, and even attend live meetups or conferences in addition to your reading.  Over the years I have seen hundreds of engineers (accomplished and junior) that invest an extraordinary amount of time to reading about different languages and tools, many of which they may never even get to use professionally.  Some even read with the goal of some certification, which they feel will demonstrate mastery of a new skill.

I have also come to know another group of technologists who are inclined to learning in a different manner.  This group starts off with some amount of reading as well, which might be limited to the product documentation and a quick tutorial, and then immediately transition into a more hands-on approach.  Once they have a basic understanding of a language or tool, they actually try to build something.

As a recruiter, I have had candidates do a quick study on a new language (used by the potential employer) and throw together some common interview coding problem or even a simple app in a GitHub repo.  As a Java user group leader, I have had presenters build small apps to help familiarize themselves with a framework they will be describing to others, and then demo the app live.  The offer to present could be “I think X looks pretty cool.  I’ve read about it but haven’t used it yet, but I’ll build something and present on my experience with X.  I can be ready in a month.”

It appears that many technologists are very comfortable with the reading portion of learning, but focus there too long and never get around to creating something.  This seems to be common for some college graduates, who obtain a wealth of classroom experience but very little time spentdoing.  Even if what you build is entirely useless to the world, your creation has value.  Learning by doing is not a new concept, so the educational value is obvious.  What other value is there?

Marketability and interview advantage
I was prompted to write this post about book learning when I was reviewing my recruiting placements for the past year.  The developers I’ve helped into new jobs over the past year have (with few exceptions) had one thing in common – a portfolio of products and code.  This was rarely the case ten or even five years go, but today it has become the norm.  The Android and iOS developers I’ve placed had at least one app available for download.  Web developers were able to demonstrate sites with accompanying code samples.  Even the programmers who focused on back end had something to show in interviews.

The biggest example of the value of ‘learning by doing’ and a portfolio is probably exemplified by the mobile app space.  It’s hard to sell yourself as a mobile developer if you don’t have any mobile app to show, and “Do you have an app?” is probably the first question mobile devs will be asked.  Software developers in most other areas are usually not subject to or judged on this direct a question.  Put simply, mobile developers know that in most cases having an available app makes you more marketable.

Programmers who work in more secure environments, such as those who build defense systems or financial software, often find it impossible to produce a work sample when seeking new employment.  Without being able to show your past work and with no personal projects, these candidates are much more liable to be subjected to a language interrogation and the game show style of interviews that many job seekers dread.  Marketability may be more tied to experience and somewhat arbitrary measurements of skill instead of demonstrable accomplishment for these candidates.

Interview advantageHaving a portfolio gives an interviewee a distinct advantage, in that the interviewee has at least some control over the topics that will arise.  Walk into an interview empty-handed and the possibilities for question topics are endless, and chances are you won’t have endless answers.  If a candidate brings a work sample to an interview, it will almost certainly be included in the discussion, and one would hope that the code’s author should fare better on questions regarding that sample than on questions on random topics.  Even average developers should see performance improvement in interviews when the topic is their own code.

tl;dr
Read enough to get going, then build something.  Don’t worry about whether your something is going to change the world.  Save what you build, and occasionally look back and improve upon it.  Bring what you build to interviews, and practice talking about your creations.