You’re full-stack enough

Lately it’s been fashionable to say full-stack developers are not a thing, or that it’s impossible to be full-stack in this day and age where the technology stack of most websites has ballooned to ludicrous proportions.

A quick visit to your favourite search engine returns multiple articles stating just that, and you know what they say: if it’s on the internet, it must be true!

Is it though?

Being a web developer in the 2000's

Let’s set the way back machine to ~20 years ago. Things used to be much simpler! There was no such thing as client-side frameworks back then. Javascript was only used to intercept a click here and there, add sparkling tails to the mouse cursor and show pop-ups (not modals - actual browser windows that popped up all over the place).

Nobody took Javascript seriously. It was an add-on, an afterthought. All logic was coded in the server-side using a variety of languages. HTML and CSS were put together on the server and sent straight to the browser. Perl and PHP were everywhere. Ruby on Rails and other MVC frameworks only really caught on around 2006, and while they did change everything, they mostly stuck to server-side rendering.

In other words, most developers were full-stack back then, to varying degrees. Of course some people were better at dealing with databases and business logic while others dedicated themselves to presentation logic.

The main difference was a certain lack of separation between data and presentation, but eventually the industry settled on progressive enhancement techniques: HTML for structure, CSS for formatting and Javascript for behaviour - with the understanding that it could be turned off by the user without preventing the use of main features. This is still a commendable goal and something the industry should revisit, but I digress.

2010's: the decade of the layer cake

Google Chrome was released in the late 2000's including a much faster Javascript engine that enabled everything we’re familiar with today. If it weren’t for V8 we’d probably be in a very different place (maybe with a better client-side language, who knows?). Without getting into much detail, it all started with hacky jQuery code talking to semi-consistent APIs and ended on the React/Babel/Webpack mess we’re in today.

The main difference is that instead of letting the server render data directly into HTML/CSS, we now have data-only APIs and large client-side applications doing 99% of the rendering. There are historical reasons for that, but it was mainly due to the arrival of the iPhone in 2007 and Android in 2008. Mobile browsers weren’t very fast, so most companies started making native apps with XML or JSON APIs backing them. We’re talking about true native apps here - not your React faux-native stuff (sorry!).

The jump from that to “we already have an API, why duplicate the effort?” is very small indeed. And that’s where we are now. 

This is where most people on the “full-stack is not a thing” side base their arguments. Back-end developers need to know how to deal with databases, designing APIs, handling security, performance and so on. This is without even mentioning server setup, automation and everything else we conveniently group under the “DevOps” label these days.

Client-side developers need to know at least one framework, wrangle ridiculously complicated build tools, deal with browser compatibility issues and have basic notions of UI/UX to hold everything together.

And if you look at it like that, it’s kinda true! I’ve been a web developer for more than 20 years (yes, twenty!) and I can mostly do it, but you’re always spending different amounts of time on each side of the HTTP fence instead of doing it all at once.

But that’s not the whole story, rather far from it!

You don’t need to know everything

In fact, you need very little to get started. It all depends on how much of the stack you’d like to control and customize.

It’s perfectly possible to create a fully functioning app if you’re only proficient on the client-side. There are plenty API-backed data persistence solutions requiring zero setup for free or at very affordable prices.

Google’s Firebase is a great example, and it even goes as far as hosting your client-side code and providing real-time functionality (ever wanted to build your own Slack clone?). Parse also provides similar features with fully open-source code if you plan to host it yourself. Pre-built Docker images are easy enough to find, making the setup virtually instant.

And then there’s Glitch. It provides a web-based editor which deploys your app at the push of a button. You don’t even have to worry about configuring a local development environment! It’s as close to “set it and forget it” as it gets.

And guess what, Glitch actually lowers the barrier of entry for back-end developers to build their applications too! No wrestling with Babel and Webpack to get a React setup running! Imagine that! You can complete your lazy stack by creating APIs with nearly no code by leveraging cloud functions on AWS Lambda or Google Cloud and you’re all set.

TL;DR: it’s all about gatekeeping

Is it fair to call developers using these tools “full-stack”? Absolutely yes! After all they’re creating fully functional applications. Anything else is beside the point.

Of course people will become more specialized on one thing or another, but it’s definitely possible to have a good enough understanding of the whole stack. The end results will be complete applications that perform just as well as organic, grass-fed code written absolutely from scratch. 

(Speaking of which: you wouldn’t write 100% of the code in that situation either - just look inside that conspicuous node_modules folder for a slice of humble pie.)

At TELUS Digital, we don’t expect our developers to start from scratch - we have a complete set of starter kits for isomorphic applications, APIs and so on. These kits provide automatic setup of build tools, automated testing, CI/CD tools and pretty much anything else a developer needs to get going - not to mention guidelines on best practices and coding style.

These tools are used by developers of all levels, and it’s a given that back-end and client-side developers will move freely around the code, collaborate and, yes, switch sides whenever needed. I can’t tell you how many times I heard the phrase “I’d like to become more full-stack, can we pair on this story?”. It all comes down to a matter of attitude.

Being a developer is hard, so it’s expected that we’ll constantly question our expertise. Impostor syndrome runs rampant in the industry, and many workplaces can be more stressful than necessary.

But this doesn’t give developers the right to get defensive on account of their own insecurities. One shouldn’t be ashamed to use available tools to make their own lives easier! You don’t see carpenters criticizing each other for using machines that cut, sand and turn pieces of wood, neither mechanics saying you’re not a real pro if you use hydraulic lifts, impact guns and compressors.

So yes, full-stack developers exist. They’re everywhere and you’re probably one of them. Let’s be nice to each other and build great things. 😎

Follow us on Instagram and Twitter @telusdigital for more events and updates. If you’re interested in joining our team, check out our careers page!