We, software developers, are a bit like sharks. Not in the sense of blood-seeking Wall Street brokers but in the sense of having a need for swimming or perishing. If you stop learning for a short number of years, the wiggling soup of acronyms that populates our environment will become total gibberish1.
We can learn on the job or in our free time although the former can be rather career-limiting unless it is complemented with the latter. Apart from reading books and posts, one of the most enriching things to do by yourself is known as deliberate practice: tackling problems focusing on what you want to get better at.
In my case, I work periodically on deliberate-practice exercises that get proposed in a mailing list of dev-minded friends of mine. I have observed that people tend to propose problems too big in scope and finally drop the initiative. People overestimate what can be done in hours or days and greatly underestimate what can be done in weeks or months so you can understand why the scope problem happens.
However, problems are not intended to be completed in just one sitting, even the ones with a reasonable size and this is an important trigger for procrastination.
I recently learned in the book of Oakley about learning2 that product-orientation, thinking on the complete products of our work, is way more to procrastination and quitting than process-orientation, focusing on the small steps driving us towards task completion. This means that we are having a difficult time without deliberate practice unless we manage our tendency to procrastinate.
What can we do about it? As Scott Young proposes, it makes sense to convert our side projects into habits and reap the benefits of process orientation. All sorts of tricks can help, like self-imposing peer pressure by working in groups or gamifying techniques like HabitRPG, an RPG-like “game” in which you lose HP points when not completing your tasks and gain XP ones when you do.
In the end this is a very personal subject and everyone should try and find out his own responses.
In practice just the details about concrete technologies is what is so fast paced, fundamental ideas evolve as slowly if not slower than in other fields. But that makes for another post by itself. ↩