Some history

Long time ago I took a decision: I stayed at the company I was because of slightly more money compared to another offer I had in front of me. That offer would have put me working in Central London 4 years earlier than when I did, and it would have meant that, even if I would have been using the same language (C#), I would have been using quite a different tooling set, a completely different architecture and a completely different Business Domain. Once I moved (I did move to a place that payed less) I only kept thinking about the 2 or 3 years of my career I lost staying. (I did win some good friends with whom I still communicate, so from the social aspect it was a gain).

I did not think I lost all four years. Because of two reasons: I kind of got lucky, and after getting my Scrum Certification (the certification is rubbish, but the two days learning properly about Scrum was illuminating), I was able to put into practices the use of Scrum and of technical practices that I have been learning; And the learning I did during that time was mostly based on what I read: Clean Code, Refactoring, Working Effectively with Legacy Code, The Art of Unit Testing: With Examples in .Net, Test-Driven Development: By Example, The Pragmatic Programmer: From Journeyman to Master, and a few others. I was not learning at my company, but I was learning on my own, and I was able to apply my learning. And the application of what I was learning told me that it was, indeed, useful, very useful.

Without that learning, once I changed to a different company, I think it would have been way more difficult to adapt and provide value.

Them vs Me

Manager 1 - What if we teach them and they leave?
Manager 2 - What if we don't and they stay?

There is always the discussion about if a company should provide learning for the employees. Maybe people learn new stuff (processes, tools, languages) and they leave. Yet, I have never seen anyone leaving because they have learned something while at the company, and left to do it somewhere else. They have always left because either there is a misalingment with the company (like lack of training) or because they have learned something on their own that they want to apply. The people that stay either are aligned with the company as it is, or are people that don’t want to change.

From the point of view of the company, I think is unwise not to provide training (both internal and external). Although they may be no silver bullet (and I don’t think that is the case) there are always practices, tools, languages that allow you to speed up and improve your development (if that wasn’t the case, we will still be using Assembly languages everywhere). Not using them is a disadvantage against competitors that do. Maybe the company has some other advantange (early in the market, good marketing/sales team, …) But you don’t know how long that will be the case, and maybe being much slower in providing improvements will doom them against a competitor that doesn’t have those advantages, but their development department can just fly.

Mind you, the above doesn’t exempt from responsibility to learn from the developer, most probably you reading this post. Is on your best interest to keep learning. First, you don’t become obsolete (unless you are doing COBOL), and second, it demonstrates that you are a person invested on your career, which gives a good image to current and future employers (or to investors if you setup your own company)

Free advise

Learn. Maybe a language, maybe a new process, maybe a new tool, but learn constantly. Don’t let the IT world pass you by while you are watching.