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 spent doing. 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 advantage
Having 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.
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful. You can also follow Job Tips For Geeks on Facebook, Twitter, or Google+.
Job Tips For Geeks 
Of course what you write there makes sense. But speaking as a pretty typical busy person with a family, it’s far easier to leaf through a few chapters of a book on Clojure/Ruby/Scala/Design Patterns/whatever here and there than to write an application start to finish – even a pretty modest application. I can do five minutes of reading here and there when I have five minutes to spare. I have a hard time coding anything but the most trivial applications in disjoint five minute slots.
I’m not saying you are wrong to recommend published code over reading. I think you’re right. I just want to make an educated guess why many people accomplish more of the latter.
Mike – Thanks for reading. I think people would agree that reading a few chapters is one thing, but what I see is when most people have say 5 hours a week to learn something, they are more inclined to spending all 5 reading books. I appreciate the concept of having difficulty getting into a zone if you are only given 10 minute windows, where reading is a much better option than coding in most cases.
As I mentioned in the article, the biggest ‘bang for your buck’ and ROI from coding instead of reading is being able to show what you built instead of trying to prove what you read in interviews. Many coders are much worse at answering random questions on the spot, but can take you step by step through how they designed and built a system.
You make a really good point. I’ve recently realised that I was a big victim of this mindset and never actually provided working code, all I would do is read about technologies and the new stuff. I think it’s very important to specialize in a certain field and then produce something out of it that can be shown to employers and the such, employers are looking for people with proven abilities, they don’t care if you tell them you’ve read about web development if you have nothing to show for it. This applies even more to new grads.
Dany – Thanks. I had new grads in mind on this as well. It seems many aren’t aware of how valuable a portfolio is. Instead of deleting all those projects from college, keep them and improve upon them – I see many that show me a site they built a few years ago and abandoned, where now it can’t be used as a good work sample. If they were to clean it up a bit, it can be used for the portfolio. Even little projects from school are useful.
Totally agree with the author. The is no excuse not to have working project. Github, AWS allow developers to create and showcase almost anything.Learn by doing, just reading is not enough to understand programming topic deeply.
Great advice. I always tell students, don’t rely on your education. Instead, put together a portfolio showing one or more personal projects. That will demonstrate that you can actually DO the work, not just read about it and talk about it. And that you have a PASSION for doing the work.
Reblogged this on Sujith B.J.
Yeh.. you are right. I’m going to write some code.
This sounds pretty reasonable… frankly, I’d definitely prefer people that can provably demonstrate their coding abilities… but see, this is, basically, your private opinion, which almost coincides with mine. The thing is, there are as many interviewers as there are opinions; and since interviewers tend to be of more senior kind, this ilk is pretty probably far away from modern coding; the remember something from years when they were doing useful things, and they did read this or that web20 json ajax node.js comet bs, and they want you to prove to them that while you are of course dumber than they are, you are able to grasp what they say and follow their guidance. Which also means that people able to create freely may have problems.