I can't help but steal the opening quote from this section of the book:
An investment in knowledge always pays the best interest
-- Benjamin Franklin
Your knowledge and experience are your most important assets. Just go ask any employer if they'd prefer a programmer fresh out of college, or one who has spent 10 years across multiple domains, languages and frameworks. And just guess who will get paid more?
The point is: this is your career. If you want to stay relevant and progress to higher responsibilities / more pay / more interesting work, you need to be constantly learning.
Your knowledge and experience doesn't just encompass your programming chops -- though that's an obviously important part of it. It also encompasses domain knowledge (my first programming job, for instance, was at a company who thought I'd be a better fit because of the Chemical Engineering degree I'd failed to get -- they assumed I'd know more about their business domain) and what we ironically call "soft skills", even though they're often harder to obtain:
- working in a team
- our profession is not a solo sport! It may seem like you don't need anyone, but trust me, you do!
- resolving conflicts with others
- because we're going to disagree -- it's how we move forward from there that matters
- ability to express yourself verbally and in the written word
- because people are going to judge your competency based on how you articulate yourself and your ideas are more likely to flourish if they can be communicated effectively
- and even your ability to learn
- in most of my positions, I've been known as the guy who can get up to speed with something new in a short amount of time. This means that I've been a bit of a "pinch hitter" on teams that needed immediate help, I've had the fun of trying out new languages and frameworks, and I've had the opportunity to learn even more, both technical and domain-wise
You need to set aside time to learn new things. I also highly recommend talking to your company to organise a time when the whole company is involved in learning new things. At Codeo, we have "10% time" on a Friday afternoon, during which it's highly discouraged to do production work (though sometimes there's an emergency). We break out to spend time learning something new, all the better if it aligns with a company goal, but not restricted to that. Chillisoft has a similar concept, although run a little differently.
Your learning path needs to be continual though. It can't just be once a year or "whenever you get to it". Technologies around us are evolving so quickly that it's not impossible for the skills you have today to become obsolete in a year or two.
Learn a new language. Learn progamming in a new paradigm / domain (if you write business apps for work, try work on a game, or some other useful utility, and vice-versa).
I only got the opportunity to work on a customer system in F# because I was known as the "guy who picks up new things quickly".
Fun fact: we wouldn't have LINQ today if it wasn't for the preparation which was being made to the internals of .NET to support F#.
Periodically, you need to review the knowledge in your bank:
- where is your knowledge outdated on technologies in active use?
- I've spoken with C# devs who are still living in the version 5 spec! They're missing out on some really cool features!
- what technologies have you been watching that are starting to make it big? which ones are falling by the wayside?
I often see people looking to change their jobs because they've been doing the same thing for the last five years. The problem I often see with these applicants is that they've been doing the same thing for the last five years. I don't mean in their daily work -- there are some companies who have tried-and-tested technologies that they stick to. You could be a catalyst for change and start trying to bring in new tech, but when that doesn't work, you have to make the time yourself to upskill if you want to move on.
I remember pouring myself into C# and ASP.NET MVC (2!) when I was looking to move out of a toxic company. I'd been working in C++ for about 5 years, and saw that the .NET ecosystem was just getting bigger and more in demand. Also, the work was fun! Since I'd had experience in asp classic, php and webforms, MVC was a new and exciting way to get web stuff done.
- Learn a new language every year
- every language I've learned (over 20 with reasonable proficiency) has helped to shape how I program. I take learnings of things I like from languages and apply them to my "daily driver" languages. I've also learned that there's no perfect language, framework, operating system, compiler, IDE... anything (:
- it doesn't matter if you never actually use this language for major work: the experience is worth it
- Try new tooling / environments
- Try out a Linux distro
- Try a different IDE / shell
- technical books, if you can afford them
- blog posts, articles on your tools and tools that seem interesting
- non-technical content, like books about human behavior and psychology
- go get an Audible subscription
- Online courses
- there are paid courses, but also a lot of good, free content
- Udemy practically always has a sale going on where you can pick up a course to keep for lifetime, for a low cost. Also, I've found that a lot of courses are kept up to date by their authors, so they stay relevant
- I don't have a lot of experience here, but I've heard a lot of good things!
- Learn things which are non-technical, stuff which is just plain interesting!
- I've done online courses in paleontology, game theory, data science. Pick something and do it (:
- Other people!
- join a local user-group
- take time to talk with your colleagues about stuff you've learned & learn from them
- if you're in a job where you're the solo developer, I highly suggest looking around for a job where you work on a small / medium team. You'll learn a lot from other people -- and perhaps you'll find (or become) a mentor!
- Stay current
- Always be prepared to learn
- have some ebooks or audio books on your phone, for those times when you're stuck waiting on some other process (like being in a queue, or broken-down car)