The curly thing about “Full-Stack”
I’ve been coding for a pretty long time. Since 1994 if you include the early Q-BASIC programs I wrote as a teenager. I’ve always believed that if there were important gaps in my knowledge I could work to fill them pretty quickly. As the web development world emerged in the late 90’s this belief caused me to form the opinion that all web developers should be “full-stack”.
A “full-stack” developer (while a pretty overused term) is generally accepted to mean that the developer is capable of writing code for both the server and client (browser) parts of a web application. For many years, I considered myself a full-stack developer. Much of my web development was done in frameworks like Ruby on Rails which made it pretty easy to write everything from the database migrations all the way through to the CSS.
In the first ten years or so of this century, the requirements for front-end code were really pretty basic. Usually, sites were mostly static, fairly simply designed and with minimal JavaScript. In 2008, my JavaScript code was barely more than a couple of jQuery selectors and I still remember when AJAX was a novelty!
But fast-forward to 2018 and the front-end world is vastly different. The browser is home to increasingly complex and sophisticated code that manages state, handles events, supervises complex data manipulations and generates incredible graphics. This is a far cry from the early days of the web and is oddly reminiscent of the desktop client-server model the web was intended to replace.
So, is it time to challenge the idea of a full-stack developer?
I reflect on my own recent professional development: for the past 12 months I’ve invested in learning and deeply understanding Elixir and functional programming. I’ve barely written a line of React or JavaScript in a year and in that time things have really moved ahead!
In the blink-and-miss-a-new-framework front-end world, 12 months out of the loop is too long for me to be immediately productive on front-end code. I find myself now having to play catch up! On the other hand, my back-end skills have had the biggest jump in 10 years as I’ve really cozied up to functional programming.
Stronger Boundaries, Clearer Responsibilities
Another reason one might reconsider their position on the idea of a full-stack developer is how modern applications are architected.
As the web has matured, so too has the technologies that underpin it. Where once the boundary of client-side to server-side was murky (think back to handling complex form validations in a traditional MVC) it is now crisp and palpable (for well designed systems at least).
The ubiquity of RESTful APIs and the increasing adoption of the GraphQL ecosystem as well as the belated but burgeoning investment in JavaScript as a “grown-up” language has given rise to complex, modular browser-based applications. Throw in React Native, Cordova, Phonegap and the plethora of hybrid mobile frameworks, Progressive Web Applications and even desktop frameworks such as Electron, not to mention WCAG, build pipelines and package management tools; it is little wonder that being a front-end developer has become a full-time job!
Where once, only the back-end world was the domain of algorithm design, an understanding of execution complexity and the continual making of tradeoffs between speed, consistency and resource usage, these concepts increasingly find necessity in front-end applications.
The front-end developer has truly become the front-end engineer and I believe that in contemporary web development specialisation between front and back will become the norm (if it hasn’t already!). A true full-stack developer is a rare beast indeed.
