Drinking from the Fire Hose
We all love drinking from the fire hose of new tech. Almost as much as we love hearing the phrase repeated ad infinitum. It is a reality however that we’re bombarded with constant change in this industry.
As developers and technologists it’s imperative that we stay abreast of the quickly evolving software landscape. How best to do so? Well, I expect what’s best will depend heavily on your individual learning style.
I’ll share the approach that I’ve adopted and maybe it will be of some value to others.
Overcoming Overwhelm
One of the biggest challenges I’ve found in drinking from the fire hose is overcoming overwhelm. There’s just so much on so many fronts for us to learn that you’re tempted to just throw up your hands.
In all honesty, it’s crossed my mind that some days I’d rather just go back to programming COBOL on the Mainframe. At least in that world, it felt like you had a stable platform that wasn’t changing drastically every couple of years.
But most would agree that stapling yourself to a legacy platform is not a good long-term strategy. So we can at least take solace in the fact that we’re in the same boat as our fellow technologists who also struggle with our rapidly changing world.
I’ve just had to accept that I need to get comfortable with being uncomfortable. Uncomfortable in the sense that I’m not going to be able to master all the new tech that I’ll have to work with. Oftentimes this means learning the macro concepts of a tech in order to work with it and then Googling like mad when it comes time to write the syntax.
Choose a Lane
After pushing past the general malaise of overwhelm, I’ve found it helpful to pick a general area I want to learn. For example, do I want to learn Microservices or Machine Learning or Grid Computing?
While there will certainly be plenty of overlap in these more general categories, it helps identify a specific tech stack to focus on. I use this as a reducing valve. In other words, I need to eliminate a huge swath of the tech fire hose spray in order to leave myself with a manageable portion that I can digest.
While I’d love to learn Python and Machine Learning and LISP and Q#, I just don’t have the time. Not with a full time job and a family and other obligations. I suspect most readers will also have similar time constraints.
Build a Roadmap
Once you’ve picked your general lane, it’s time to map out what tech is most important within it. For example, if you wanted to learn Cloud Native Java development you’d start building a tech list. This list might look something like this:
- Cloud Providers
- AWS, Azure, GCP
- Containerization
- Docker
- 12 Factor Principles
- Microservices
- Spring Boot
- Spring Cloud
- Cloud Providers
Once you have a roadmap of tech, then you need to prioritize. What’s the most important tech to learn first? What are the dependencies? For example, does it make sense to try to start learning AWS without first learning about Containerization and Docker?
You’ll likely run into some circular dependencies at which point you just need to pick an order and go with it! It’s easy to fall into the trap of doing nothing because it’s not clear what the priority ordering should be. You can always reprioritize later if needed.
Do!
I’ve found I generally need to do in order to learn. This means building things myself and not just passively consuming content. I suspect this will be the case for most others as well.
For example, if I want to learn Quarkus, then I need to build my own app using this tech. Simply listening to a podcast or reading a book about Quarkus is not going to get me very far. What little I retain from such endeavors is quickly forgotten over time.
However, if I build my own app with Quarkus, even if it’s fairly basic I retain far more. I need to discover the gaps in my knowledge by solving them on something I’ve built. I’ve also found this to be a far more efficient way for me to learn.
I do listen to podcasts and use other resources that are passive in nature. However, I like to use these as high-level introductions or reference materials. Mostly to be done while doing other things, for example listening to podcasts while at the gym or during drive time.
I know I’m not going to retain a huge amount from these mediums, but they can give me a head-start when it comes time to build on my own.
Finally, I like to keep a consistent cadence to my learning. For example, I know I’m going to be busy most weekdays so I accept that I won’t be working on my projects during this time.
However, I can carve out hours on the weekends to dedicate to my projects so that’s what I do. Even if it’s only a small commit or two on my projects, I strive for consistency.
Summary
Drinking from the fire hose of new technology is a fact of life to a software developer. Moreover, we should devise a strategy to do so as effectively and efficiently as possible.
It’s important to overcome feeling overwhelmed by the endless change in our industry. We can accomplish this by filtering and prioritizing well. Our time is limited, so we must decide what will give us the most bang for our buck.
Picking a topic of interest and building a road map of the critical technologies can serve as a reducing valve. By doing so we can learn at a manageable pace while accepting that we will never be able to learn everything the fire hose shoots at us.
Many favor active learning by doing over passive learning activities. I would agree with this approach. We tend to retain more by doing and iterating than passively consuming content.