It's been a few years since Oliver kicked off his career, as a full-stack Java developer, in this BigCorp. Inc. He learned quite a bit, primarily working on the backend: writing features, plumbing APIs, debugging code, fixing bugs, DENTTAL (Documentation, Exception Handling, Null pointers, Time complexity, Test coverage, Analysis of code complexity, Logging) checking his code, shipping code to production quick and often. He also learned from his seniors that design patterns were an important thing. After all, why re-invent the wheel when you already have a pattern for that? 

It was time to make the switch. It would be a step-up in Oliver's career with a noticeable salary increment. In his tenure, he developed quite an interest in writing code and building scalable software. That was something he could take pride in. Also, with the ability to write the application's front-end, he could write his personal products solo, end to end. 

His eyes lit up as he clicked the keys on his keyboard. He mumbled, "job openings for a full stack developer." As he hits Enter and scans through several job openings, he leans back on his chair with a sinking feeling, looking at the ceiling. 

Most of the openings had these requirements in common: 

• Expertise in Java programming and the Spring framework.
• Experience building a large-scale distributed system involving large data volumes and real-time distribution.
• Experience in HTML5, CSS3, JavaScript, JQuery, TypeScript, React, Redux, GraphQL, Grunt, and Webpack.
• Experience in containerized software (Docker, Kubernetes). Knowledge of CI/CD, Git, and the DevOps toolchain. 
• Ability to write performant code. 
• SQL and experience working with data from various storage technologies, primarily NoSQL.
• Understanding of modern architectures based on microservices, REST APIs, and event-based architecture.
• Experience in full-stack AWS development technologies. 

"React!" he thinks to himself, taking a deep breath, "but I know Angular. I believe it was version 1.0 that I learned. Won't that be applicable anymore? Why do the majority of the jobs need React? And what on earth is Redux & TypeScript?"  

"Hmm ... Okay, and ... what about AWS?" —Oliver incessantly spins his pen— "I wonder how much time it's gonna take to learn this..." 

At his job, Oliver worked on the on-premise infrastructure setup; he hardly knew anything about AWS.  

He looks at his monitor contemplating, and after a long pause, starts to type again. After a few more hours of research, he is left even more confused. He finds that React isn't the sole leader in the UI universe. New frameworks like VueJS and Svelte are rising steadily and are at odds with React. The big guns are adopting them, and they say these are easy to learn. Moreover, nobody wants to use vanilla JavaScript & JQuery anymore. And some blogs even say WebAssembly is the future of web development.  

Oliver continues his contemplation with closed eyes, "What should I do? Should I learn VueJS or get on with React, or should I wait for the WebAssembly trend to catch up?"  

"What if React too declines in popularity just like Angular? and are these companies positive they expect one person to know all this stuff? Isn't it too much to ask? Hell, some are even asking for the fundamentals of machine learning."  

Oliver leans back and grips onto his chair firmly, "Do I defer my plans for a year and invest the time into upskilling? Or perhaps, I should switch my domain to maybe Data Science, Mobile dev, or possibly ML? That's pretty trending these days."  

"I mean, there are just too many things to keep track of. And what if the trends change again?" —Oliver shakes his head in disapproval, getting up from his chair— "Boy! ... It's just insane. I think I should call it a day."

We, as application developers, can so relate to Oliver's predicament. We need no substantiation on how the pressure of frequent upskilling is tormenting the devs. However, just for the record, I'll quickly bring up a couple of instances where technology changes are proving to be no less than a nightmare.

The Short Lifecycle Of JavaScript Frameworks

The most chaos is happening in the frontend layer of the applications in terms of technology advancement. When I started learning frontend development, I would write JavaScript code in a notepad file and run it in the browser. It was that simple. Even when JQuery came along, it almost had no learning curve. 

Things were simple and peaceful. Birds chirped, and I coded. With the simplicity of the UI development (Html, JavaScript, JQuery, Ajax, and a bit of CSS), I could focus more on the backend and the persistence technologies. 

Just when things looked perfect, the SPA (Single page application) trend set its foot in. And frameworks like Angular, Backbone, Knockout, and Ember started gaining traction. Developers began talking about implementing the MVC pattern and a whole lot more fancy stuff on the UI. This was when things started to get complex; that meant it was time to step on the upskill treadmill, and the rest is history. 

Today, just to run simple JavaScript code, we are required to set up a development environment with a lot of dependencies and whatnot. JQuery has taken a nose-dive in popularity amongst the modern frontend developer fraternity to the point that the latest version of Bootstrap, version 5, has removed JQuery dependency. 

Taking into account today's application development landscape to have that frontend or full-stack developer badge on our shoulder, we must know: the fundamentals of the web, HTML5, a bit of CSS, JavaScript, responsive page design, latest versions of in-vogue frameworks like React, Vue, Angular, take your pick. We must also be familiar with the libraries commonly used with these frameworks, such as Redux, NgRx, and so on. 

Besides these, to run the application, we are expected to be well-versed with the tool ecosystem: task runners like Gulp, module bundlers like Webpack, Linters, and formatters like JSLint, ESLint, type checkers like Flow, TypeScript, testing frameworks like Jest, Jasmine and so on. 

As we learn these, we also have to keep an eye on the development trends and adapt accordingly to avoid crashing into a dead-end in the future. And did I forget to bring up PWAs (Progressive Web Apps) and WebAssembly? 

Imagine explaining this to someone just starting his web dev career? I would so want to see the look on their faces. 

Cloud Computing Platforms and Container Wars

Speaking of the cloud, Amazon Web Service (AWS), having the first-mover advantage, has the most significant market share in the cloud computing space. AWS powers a big percentage of the enterprise, small-scale, and indie software today. And thus, its knowledge gives devs a leg up in most of the job openings.  

The biggest rival of AWS Is Microsoft's Azure, and it is steadily gaining ground, surpassing Google Cloud. As per Gartner, Microsoft had a staggering growth of 60% in IaaS (Infrastructure as a Service) market share in 2020, compared to Amazon's growth of 28.7%, which still leads the worldwide IaaS market. 

Shall Azure or any other cloud platform beat AWS with its better product offerings and continual innovation in the future; the employers would then expect that particular cloud platform experience from the developers. Try to see this from a developer standpoint. Does this sound like something that would make them happy? 

Zeroing further into the cloud space, Docker debuted in the year 2013, changing the DevOps landscape forever. The advent of containers totally transformed the way we build and run applications.  

And then, the race began for the container orchestration software. The industry needed a product to manage the containers. Products like Apache Mesos, Docker Swarm, Google's Kubernetes, VMware Photon, HashiCorp Nomad, and Openstack Magnum were all in contention to be at the top. Initially, it appeared like Mesos would win, but when the dust finally settled, Kubernetes emerged as the leader. 

The enterprises that ran their containers on a container orchestrator other than Kubernetes had to consider migrating to Kubernetes reluctantly. Mesos and Docker Swarm experts had to learn a new container orchestrator tech that was Kubernetes.

The emergence of every new technology in the market brings along a whole lot of speculation, promises of disruption, ongoing debates, and the emotions associated with it. Some dread it, some welcome it.  

The popularity of Scala made quite some waves, and all I could read online at that point was that it would replace Java. Prophecies were made, "Java is dead; OOP is so dead now. Functional programming will be everything in the future." The same happened with the advent of Rust, Swift, and NoSQL. 

We need to realize that every tech has specific use cases and trade-offs. There is no silver bullet. We tend to embrace the new ones, reluctantly or willingly, primarily because: 

A. Our minds suffer from Shiny object syndrome. Boredom kicks in after a while as we continually work on a particular technology stack. Granted, that's human nature. 

B. We experience FOMO (Fear of missing out) when we hear our peers discussing shiny new technologies.   

C. The new tech is truly disruptive and drops an A-bomb on the existing technologies and development practices.   

We'll discuss the road map for upskilling, picking the right technology, switching through different domains, side projects, and more in this course in great detail.  

I believe you have realized that we are treading through an unforgiving landscape. Regardless of the application layer we work on; the industry expects us to continue upskilling to avoid becoming dinosaurs. And that means staying on that treadmill. 

There is no expiry date for technology evolution, but we do indeed have one. The question is, how can we stay hireable and creative, avoiding burnout.

Let's start discussing our roadmap in the lesson up next.