Opinion: The New Full-Stack Dev
Praneet Loke
Posted on June 8, 2020
There was a time when calling oneself a full-stack dev was met with confused faces. It was a fairly new idea. No one really understood what it really meant and if it was real. It was sort of like gluten and people claiming gluten allergy.
Years later, both couldn't be more real. In the early days of being a full-stack dev, it meant you could write services powering the UI (aka the backend), as well as some really cool jQuery selectors (like $("#someDiv .items:nth-child(2)")
-- I'll let you figure out what that means.), some HTML and some CSS. If you knew jQuery you were the dev to go to at work.
The full-stack developer movement couldn't have started without javascript templating, backbone.js, and later SASS. Pretty soon after those were introduced a lot more developers claimed to be full-stack developers, which was bolstered by the creation of Twitter's Bootstrap. And suddenly, there was an explosion in the number of developers who could comfortably write both UI, and backend services. The gates to UI development were knocked-down pretty hard. There was probably a hot new frontend framework every week. From BackboneJS (the OG of bringing Model/View/Collection paradigm to frontend development, in my opinion) to today's React/Angular/Vue -- today's big 3.
A new framework was announced on JS Weekly!? SWIIITCH!!
-- Web Developer
From there it was a natural progression for developers to try and tackle writing mobile apps with PhoneGap, which was later renamed Apache Cordova. Arguably one of the most contested ways to write a mobile app. It was nonetheless a way for a web developer to also try their hand at mobile development too. To this day, there are numerous frameworks that promise the "write-once-run-anywhere" type of semantics. Xamarin, Flutter, React Native, NativeScript, Ionic Framework are all popular frameworks in that space. Regardless of what you and I believe the best way to build a mobile app to be, it was yet another skill a full-stack developer could add to their skillset.
Other Developments
Back when cloud services were first introduced, almost no one cared how you got to "the cloud", so as long as you were "on the cloud". Scripting languages became uber-popular in the ops area. Knowledge of bash, and PowerShell were (and probably still are) indispensable. Tools like Chef, Puppet invigorated the infrastructure space with their ideas. There are probably more tools that I have probably never even heard of.
All this while every major cloud provider was cooking up their own template-based toolset to deploy services to their respective clouds. Surely all of the great minds that thought of the amazing ways to build software for the cloud could have seen the problem a mile away, right? Nope.
AWS has CloudFormation templates, Azure has ARM templates, and Google has...uh, I don't even know and I don't want to. This is a clear and present problem.
This is a clear and present problem. It is what kept the infrastructure space away from the general reach of your average developer who just wants to deploy a simple service to the cloud.
Redefining Full-Stack Dev
With HashiCorp's Terraform, this changed. Infrastructure "gurus" started to see the need for a system that would let them deploy repeatable, and predictable infrastructure to the cloud. This works really well if this is what you want. But if you don't want to learn a new DSL?
If you noticed at the beginning of this post, every innovative piece of technology introduced in the developer ecosystem, involved taking something that was accessible to a niche of developers and turning it into a programmable thing. HTML became JS template, CSS was too brittle, so SASS was created which brought some general-purpose programming language paradigms to CSS (when was the last time you wrote CSS? I mean, raw CSS, not SCSS as you know it today.), mobile apps could be built frontend frameworks. At each stage, the adoption of the respective technology was through-the-roof.
We have been going about trying to solve the cloud infrastructure tooling the wrong way all this time.
Allowing developers to do what they do best -- write software, will certainly bring infrastructure to the masses. This is why tools like Pulumi will disrupt this space. The movement to bring infrastructure to the masses has begun. Pulumi brings the programmability, the "coding" aspect to infrastructure. For the first time, it really feels like I can truly program the cloud.
That is not to say the tools that have been created so far have no place in building infrastructure. Nope. Quite the opposite. I think there is a need for these tools. For instance, not everyone is using the cloud the way cloud providers want us to use them. Many of them are tied to legacy on-premise systems, leading to the so-called "Hybrid Environments". Whatever the setup, there is a place for each of those tools.
And for those of us building something new for the cloud, there's Pulumi. So let me define the new full-stack dev...
A developer who can work on all tiers of an application, including the infrastructure.
What do you think?
Posted on June 8, 2020
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.