When I first entered the field of software development, in order to become a so-called expert, we needed to learn a handful of technologies. It was challenging, but it was doable.

This is no longer possible.

Today, we need to be able to apply JIT (just-in-time) learning techniques to keep up. It’s just not possible to learn everything about a single tool, much less every tool we’ll need to use on a given project. In Microsoft’s .NET framework alone, there are thousands of classes. If you’re a .NET C# API.Web developer, you need to have at least a working knowledge of the .NET Core framework, the CLR, Visual Studio, C#, HTML, JavaScript, CSS, Windows, IIS, probably SQL (no matter what engine), and the specifics of a particular SQL engine. And in most systems, you may need to understand another handful of technologies, core concepts, and third party tools.

So when do you learn all of this? Just-in-time.

You can accumulate knowledge of the core technologies over several projects, yet still only touch the surface. And rarely does a new project come along where you wouldn’t need to learn at least one new technology you’ve never touched before, or may not have even heard of before.

So how do you keep up with all these tools and technology? Well, you can anticipate everything you’d think you’d need to learn, but aside from a few educated guesses, you’d have to be a clairvoyant to keep up with the changes in our field. It’s often like using a waterfall SDLC. I don’t think it’s really works anymore. There are too many unseen forces working just under the radar, and you’ll constantly be blindsided.

How do I keep up with this stuff? Just-in-time learning. For the most part, I learn as I go. Since most new tools we need to use build upon the core concepts we’ve built up over our experiences, the learning curve is usually not so large for adding something new. Part of my strategy is using supplemental learning to build up that core skill set, which I’ll discuss as well.

This is my current strategy for learning. Since we all learn somewhat differently (in our own combination of kinetic, visual, and auditory resources), your mileage may vary:

1. Research: Unless you have a team leader assigning which technologies to use on a project, you’ll likely be involved in researching the best solution for a particular requirement. For example, we wanted to start our project by using a framework to help drive the look and feel of our web apps, so we started comparing such tools. We decided upon Twitter’s Bootstrap framework. I watched intro tutorials, read reviews, viewed sample code, and experimented with the samples.
2. Video (Passive): Once I’ve decided what I want to learn, I usually start by watching a series of videos on the topic. Udemy and Pluralsight are my favorite choices for an intro of some of the most common technologies and tools, although more obscure or new tools may not (yet) be covered. YouTube is another great source for tutorials. Of course, strongly supported tools may have their own video tutorials, although I usually find those lacking. It seems to be an afterthought for a lot of companies, and production is often poor or inconsistent. Since in my role as a consultant I’m expected to be an expert on the tools I’m using (unless a new technology is dictated by the client), I normally use my breakfast time before business hours to watch these videos. It allows me to absorb myself into the technology in a passive manner, which helps get me acquainted before diving in hands-on. If you’re lucky enough to attend a local user group meeting on the topic, that’s also a great way to get an intro as well as allow for direct Q&A. But it’s rare to have such perfect timing, unless the technology you’re about to use is the new “flavor of the week,” and the rest of the world is learning about it at the same time.
3. Video (Active): Although I’m still in more of a passive state of mind at breakfast, by lunch I’ve usually been in coding mode, so this is a good time to re-watch parts of the video and actually try out some of the examples being discussed. Although video is great for pausing and rewinding, it’s a bit awkward to pinpoint the exact locations of what you want to re-watch, so if example files are available for download, I prefer playing around with those. Be careful, though, since it’s too easy to have the examples do the work for you, since they’re usually already fully written. Without the hands-on (read: typing in yourself), it usually won’t sink in as quickly.
4. Google == Stack Overflow: As you play around with examples, you’ll likely have some questions that aren’t yet explained by the point you’ve reached in the video course. I normally find that it’s easier to search for answers to my questions instead of trying to find it in the tool’s documentation (if it even exists). Since the best search results usually end up at Stack Overflow, I spend a lot of time reading answers there. Keep a close eye on the timestamp of the answers, though. They may be outdated. But if it’s a good answer, it may also have a direct link to a part of the documentation you’ll need.
5. Web Articles (Blog and Otherwise): When it comes time to dive into a specific piece of the technology I’m trying to use while learning, I start focusing on specific online articles.
6. Books: With all this JIT learning, there’s still that nagging feeling that you could be doing things better. I feel like that all the time, and it used to bother me. No longer. I’ve learned to become more pragmatic over the years. Job # 1 is to deliver a solid solution, making it as maintainable as feasible. But refactoring should be built into subsequent work, whether or not you do some refactoring during the TDD (or otherwise, unit test) process (if your shop encourages that — which it should). This is the time to supplement your knowledge with a deeper understanding and best practices in the technology and tool you JIT-learned. This is where books become useful to me. Even if a book is inherently a bit outdated, it could still be useful, because core concepts and best practices live longer than specifics. I rarely read technical books cover-to-cover anymore. I may read a few introductory chapters, but then I’d skim through specific chapters based upon where I’m focused.
7. Deep-Dive Videos: But I usually reach for a detailed video course instead of a book. Pluralsight and Udemy have some deep-dive topics in addition to their introductory tutorials. I was very happy when Pluralsight incorporated Rob Conery‘s TekPub videos. I always felt that they complement the Pluralsight videos quite well, and focus more on the deep-dives. They’re usually opinionated, and they often focus on best practices, and make you really understand the topic in ways you’ve never thought of before. Watching someone code and think out loud at the same time is often as valuable as pair programming. Both sites (and there are others) are well worth the investment in your future.

In between my JIT learning cycles, I spend those free hours supplementing my knowledge with deeper dives, as I described in points 6 and 7, above. I use those breakfast and lunch sessions to fill in any gaps, and do some soul-cleansing refactoring in subsequent sprints based on that learning. Such exercises helped me become a better coder over time.

I also use the off-cycles to learn other technologies I predict with some certainty that I’d be using within the next year or so. For example, learning or refreshing my knowledge on Python, Django, and Godot in anticipation of implementing some app ideas and restarting a previous venture.

As developers, our education will always be an ongoing process. There is just so much to learn. We must develop a strategy just to keep up or get ahead of the game, yet remain current and productive. Although your strategy may differ from mine, hopefully I’ve provided some ideas to get you started.