The Duality of Engineers
The Duality of Engineers
And why you're thinking of Full Stack incorrectly
The Strange Case of Dr. Jekyll and Mr. Hyde was written by Robert Louis Stevenson. Essentially this book came down to a single premise: the duality of man (or woman, for that matter). Plato also spoke about this very topic, largely about the mind vs. the body. The mind observes and thinks whereas the body moves and creates.
The software development industry has long been infatuated with the idea of some multiplier when it comes to engineers. After all, the “10x Engineer” was mostly cooked up and bandied about in Silicon Valley to talk about engineers that accomplish 10x more than that of your “average” engineer in the same amount of time. I don’t prescribe to that multiplier existing, for what it’s worth. Certainly not at 10x.
And then there’s the idea of a “Full Stack Developer”. While this title and role is more attainable (and possible) than that of a “10x Engineer”, companies and managers get perhaps a bit too enamored with the role and abilities of those than don the title. While there isn’t a definitive date of when the title came out, there started to be more of a proliferation of the title in the early/mid 2010s. Before I continue, it might be helpful to explain (roughly) what a “Full Stack Developer” is. This is just my own description:
A developer that has enough experience to contribute code in both the frontend user interface as well as the backend (API on down to the underlying data sources and systems).
I’ve intentionally said, “frontend user interface” and not “frontend web”, because it’s important to note that while the proliferation of the title over the last decade has largely been about frontend web and backend web development, full stack development has existed long before that simplification.
API developers have contributed to native app user interfaces (both on mobile and desktop) as well as on other platforms that have user interfaces (cars, for example). But those developers have largely been few and far between because those codebases have overwhelmingly been detached and decoupled from one another and the teams developing them sometimes in entirely different buildings, states or even countries. Think about it.
If you were an API developer in the early 2000s, chances are you were using Java, C/C++, Perl, PHP, C#, Visual Basic, or VB.NET. And that goes for web services and local API/SDK development. Web services weren’t nearly as ubiquitous as they are today. And for good reason. Strong cellular connectivity and native app development really didn’t start taking off until the late 2000s/early 2010s. This is a heavy reason why there were dedicated mobile web sites.
If you were a UI developer (see: frontend) during that period, your language of choice was some early form of JavaScript, C/C++, Visual Basic, Java, etc. There was very little intersection on the languages, codebases, or responsibilities. In the early 2000s, most of the frontend web was, believe it or not, rendered by server-side languages. Desktop apps were an entirely different beast.
Things started coming to a head in the late 2000s with the advent of the iPhone and Android, and certainly in the 2010s when there started to be a monumental competitor to native app development with a resurgence on the web — largely around responsive web development. As more and more platforms started to come into the picture, it became more and more important for companies to have a presence on each of those platforms. This is why cross-platform development was such a huge boon, and also why web technologies on mobile and desktop devices also got popular.
It became enticing for companies to try and find developers that could contribute to multiple platforms. This was a huge reason why platforms like Electron, Xamarin/Mono, PhoneGap, and the like became popular (which led the way to React Native, Flutter, etc.).
As more and more developers contributed to various UI platforms and underlying systems, along with that came a proliferation of ubiquitous languages. Java had this methodology back in the day, “Write once, run anywhere”. As did Flash. But there wasn’t necessarily a hegemony of one programming language in the 2000s or even the early 2010s. Backend programming languages routinely go in/out of vogue.
This video goes from 1965-2019 which aimed to show an animated trend of programming languages over the 6 decades presented. And it’s a fun watch.
Not to overly pick on Ruby, but it came in like a lion in 2005. Bypassing Perl in about 3 years. And by the mid 2010s, it started falling off the most popular Top 10 list. If you don’t want to watch the video, the video posits that the following are the Top 5 popular programming languages:
Python
JavaScript
Java
C#
PHP
Python started getting popular in the early 2000s and really taking off in the 2010s. This was largely driven by it being the go-to language for data processing analysis. There was an explosion of interest and adoption for these data centric needs around this time, and Python naturally fit the profile. Additionally, it was easy to pick up and learn (for a variety of reasons). Programming language popularity can be a full topic for another post, but suffice it to say, Python is the go-to language for the “backend”.
But there was one programming language that became more and more ubiquitous and never really lost market-share over the decades: JavaScript.
JavaScript can be used pretty much anywhere. In the web browser, desktop apps, mobile apps, progressive web apps (PWAs), cars, web servers, games, even Outlook add-ins. And plenty more. There are other programming languages that have broken out of being just a backend language: C#, Swift, Kotlin, and others. But JavaScript, by and large, had/has this by the horns.
If you’re interested in seeing how JavaScript made its way into backend servers, a quick Google of the V8 JavaScript engine in Chrome will show you the way. But here’s a real quick wrap-up from Node’s site:
The cool thing is that the JavaScript engine is independent of the browser in which it's hosted. This key feature enabled the rise of Node.js. V8 was chosen to be the engine that powered Node.js back in 2009, and as the popularity of Node.js exploded, V8 became the engine that now powers an incredible amount of server-side code written in JavaScript.
The Node.js ecosystem is huge and thanks to V8 which also powers desktop apps, with projects like Electron.
With JavaScript on the client as well as on the server, more and more the “Full Stack Developer” designation started to not just form — but spread! The promise was a developer being able to take their JavaScript knowledge from the browser and airdrop into the server code and not skip a beat!
But it’s really important for people to realize that Full Stack Developers aren’t built or created the same way. Very often, they’re experts in one vertical (backend, frontend) that get exposure to other layers over time. And they typically get into one vertical because they have a desire for that discipline. This is just a generalization, but frontend (UI) developers have a tendency to be more creative and visual types, whereas backend developers are more data driven. It’s important to keep this in mind, because what I’ve often seen is that Full Stack Developers usually specialize in one, not both.
If you think about how engineers are deployed on projects, unless they’re the only developer, they’re focusing on one vertical over the course of a project. That way projects can move faster. After all, if an engineer is doing both layers, the schedule will be elongated. You get the value of a Full Stack Developer in the early stages of a startup since you’re not paying for multiple roles and the codebase is constantly evolving. You’ll also get the value of a Full Stack Developer once a startup starts getting some maturity as that developer can bounce around and contribute to various layers throughout the project lifecycle. Where things get muddy is in between. Those that need maximum velocity will shore up expertise by specializing.
Even the Bootcamp industry tries and push the “Full Stack Developer” title. After all, thousands upon thousands of prospective developers are promised this ability upon completion of a 3-month (or similar) course. And why shouldn’t they? The title is very alluring for companies and hiring managers.
Which brings me full circle to the duality of (wo)man. We need to look at Full Stack Developers differently than the market purports them. To use a sports analogy: the market looks at Full Stack Developers as Shohei Ohtani. For those not familiar with who he is, Ohtani is a Major League Baseball player who can both hit and pitch. And he can do them both equally and incredibly as well. Suffice it to say, he’s a generational talent, and it’s incredibly rare.
The market should look at Full Stack Developers not as Shohei Ohtani. But as Ben Zobrist. Or DJ LeMahieu. People that can play multiple positions well, but not expected to be an All Star at both sides of the ball (hitting and pitching).
For hiring managers, there is no free lunch. A Full Stack Developer won’t get a project done markedly faster (or necessarily better!), but over the course of the typical ebbs and flows of a business, the ability to contribute to multiple layers is enticing — and it should be! Flexibility goes a long way. But let’s not expect the world out of every single Full Stack Developer. It’s time to reel those expectations in a tad.