Why you need to be up-to-date
I am not trying to contribute to the cliché that you have to be constantly working to keep up as Aaron Erickson notes in The Nomadic Developer as you can have a great career getting by with what you learned in the university a decade ago. But he also mentions that in software,
seniority and years of experience matters less relative to actual demonstrable expertise in a technology that renders something older as pretty much obsolete.
He suggests that to thrive as a developer, you must continue learning not only new technology but also learn about processes.
Your knowledge and experience are your most important assets.
How to invest in your knowledge
Fortunately, Andrew Hunt and David Thomas list five actions you can take in order to develop a strong knowledge portfolio.
Science shows that you get more out of reading regularly, and spread across time, than if you try to read a large amount all at once. If there is a section that you need to memorize, Barbara Oakley suggests in the book A Mind for Numbers that you should use “spaced repetition.” This is a technique where you study the same section several times, but spread across days, allowing your brain to process the material.
You can also face burnout if you take it to the extreme, so it is better to portion it in a pace you are comfortable with.
Do not become too narrow in your field, or you can end up in a situation where a new firm creates a new framework that make your bread and butter obsolete.
You should not only invest time in several topics – you should also try to be smart about which topic you should invest your time in. If you are unsure what to pick up next, visit ThoughtWorks radar. The site gives you suggestions on which technology that you should consider, but be aware, it is not written in stone. Not even the bright minds at ThoughtWorks have a crystal ball and can predict the future. If you are ready to take advice from a Microsoft guy, you can read Scott Hanselman’s post about which technologies to learn in 2014.
Buy low, sell high
If you are looking for the highest-paid job, you might want to take some risk and take a chance in an upcoming technology, allowing you to reap the benefits when and if it takes off. Even if you are betting on the wrong horse, you will most likely still have gained some transferable knowledge that you can benefit from in your current language.
Review and rebalance
Constantly review what you have been doing. I like the way Scott Hanselman does it, he schedules a meeting with himself once a week. Once a week might be bit often, but try on a monthly basis to go through the effort you put in to better yourself, and be critical of the rewards that you got out of it. You should evaluate each method, what worked and what did not. After a session like this, I decided that reading books was not enough, so I tried to improve the way I use books, both how I read and how I used my newly gained knowledge. Now I try to use the new knowledge either in pet projects, or tell others about it in a talk or in a blog post. I recently decided to enroll in a class at Coursera called Learning How to Learn, hoping it will increase the benefit I get from my learning efforts. It looks promising so far; I have already changed the way I read books.
I believe that you should strive for laying a sold foundation, built with knowledge that is technology agnostic, skills that you can utilize across frameworks. This is usually where your formal education comes in to play. With a good education, you should have learned the basics, and equally important is the ability to learn new skills and acquire new knowledge. Recruiters know this and this is in part why most of them only recruit students with a university degree. I am not saying that you need to have a fancy degree to be a good developer – there are many examples to the contrary – but a solid education ensures that you have all the basics, and a formal education can give you a common platform and lingo with most developers with a degree.
In his popular book, Clean Code, Robert C. Martin stated that
You should plan on working 60 hours per week. The first 40 are for your employer. The remaining 20 are for you. During this remaining 20 hours, you should be reading, practicing, learning, and otherwise enhancing your career.
Sixty hours are a lot and most are not ready to make that kind of commitment. I am not suggesting that everybody needs to invest twenty extra hours each week, but if your goal is to become a guru or an outlier, this might be a sacrifice you will have to make. I think good developers can easily spend five hours or less weekly to stay on top of all the latest and greatest and still maintain their position as a good developer or even become a better one. For those who are looking to drastically better themselves as developers, a little more effort might be required.
If you use your time wisely, twenty hours might not be all that. If you multithread, you can do household chores and still learn, or if you have a long commute, 5-10 hours can fly by if you use the commute to listen to audiobooks or read books on your e-book reader or smartphone.
I try not to focus on getting the twenty hours each week; instead, I try to find a pace that I can maintain and only do it when I feel like it. I try to find a way that integrates well with my regular life. I spread out the learning between several ways such as side projects, audiobooks, books, video courses, conferences and blog posts. Each method has its advantages and disadvantages. Summed up, all those things usually comes to around 20 hours over a whole week.
Many of you might have heard about the Pomodoro technique. You can also utilize this technique when reading. Try to turn off all distractions, pick up your book and read for 25 minutes. Then take five minutes, make yourself a cup of coffee, check your Facebook or take a short walk.
Pick up a book
Code Complete cited research from 1999 done by Timothy Lister and Tom DeMarco stating, that most programmers does not read even one book a year. Sure, there are other ways to gain the knowledge, but I find that books give me a deeper knowledge in a subject than many other ways. Books are also something you can discuss with other developers, and they have a much longer lifespan than a blog post. Most posts are only referable for a month, tops. You might be able to discuss the latest post from Jon Skeet, but go back a year and few will remember. Really good books can be talked about for decades. Discussing Code Complete is still possible with other developers, even if though the latest edition came out over ten years ago.
I travel a lot, and when I do, I always bring my Kindle, usually pre-stacked with a couple of new books. Internet can be a bit pricey in foreign countries, but you do not need Internet if your book is already downloaded or especially if you are old-school and buy your books paperback.
There are many books to choose from, but as I have discovered, I share the same opinion as Jeff Atwood. In the post Programmers Don’t Read Books, But You Should, he suggested that you should go for programming books that
transcend choice of language, IDE, or platform. They do not explain how but why.
Even though he has stopped reading books about a specific programming languages, I have not, but I find myself ordering far fewer than before. He has a list of suggested books. You should also check out Cory House’s list of audiobooks.
I want to leave you with one last quote from Benjamin Franklin
An investment in knowledge always pays the best interest.
- The Nomadic Developer: Surviving and Thriving in the World of Technology Consulting (Microsoft Technologies Series)
Coursera Course on how to learn: Learning How To Learn
Scott Hanselman blog post: Personal Productivity: Business vs. busyness vs. laziness
The Pragmatic Programmer: From Journeyman to Master
A Mind For Numbers: How to Excel at Math and Science (Even If You Flunked Algebra)
- Clean Code: A Handbook of Agile Software Craftsmanship
- Code Complete: A Practical Handbook of Software Construction, Second Edition