The Jokers in a Deck of cards - on the ever-evolving Generalist Role
In our industry, some don’t fit into a single box. Being one of those people, I’ve felt somewhat constrained when hired for a “front-end” or a “back-end” role. I’ve felt more at home in the very vaguely defined “full-stack” role, but those roles can sometimes get a bit overwhelming. While I do enjoy the challenge of learning new things, infra and cloud stuff makes me want to cry. It’s me, AWS; it’s not you.
Now, the benefits of doing the cloudy stuff aren’t lost on me - but I prefer setting my own application server, HTTP servers, etc. I don’t dislike automation, but I like understanding what’s going on “under the hood” without having to wade through pages of (usually not great) documentation or getting consultants that point me towards one of the thousand available methods to load-balance something. Okay, rant over, back to the topic at hand.
What really inspired me to write this post is the following LinkedIn exchange:
And the comment that followed:
Bojan’s analogy is good and spot-on for multiple reasons. Having a flexible skillset does make you more valuable in the sense that you can jump in at any end of the proverbial stack and fill a role. Does that come with monetary benefits? It’s debatable, but in my experience, it doesn’t make that much of a difference. Should it? I could argue that it should, but that’s a topic for another post.
“Jokers” is an accurate analogy to what the generalist role usually is - a placeholder card, maybe a trump card, depending on the game. This is exactly what a generalist does - fill in a need or provide insights/big-picture ideas for a project.
Being in such a role comes with tradeoffs - some great, some not so much. Let’s dig deeper into those.
In the olden days, there was no such thing as stacks. I remember a time when front-end amounted to negotiating with the browser (I haven’t forgiven you IE) not to screw up the HTML, CSS and maybe some JS that you neatly packaged into a page via a templating engine. People who called themselves front-end developers invoked a very different set of ideas about what they did than what we do today. More often than not, there were expectations that you’d be able to do some design work, often using Photoshop - we used to have people that did “slicing”. It totally made sense, though. The web was a very different place than what it is today, tech-wise. So, if you were into web development, you were called a web developer. No front-end or back-end about it, let alone full-stack.
Being spread across the stack got even more complicated as a result. Considering the speed at which the front-end changes, plus having to stay on top of your back-end skills, it indeed requires a lot of effort to stay sharp and employable.
As always, things got more complicated. Enter the cloud.
Since everything has to be wEb ScAle these days, and herding servers isn’t the most fun experience in the world, we invented this magical thing known as the cloud. Now, I’m not a cloud skeptic. It has its uses, but it’s not the silver bullet that it’s often made out to be. It’s a tool, and like any tool, it has its upsides and drawbacks. But I digress.
On top of having to know your way across the front and back-end, often there were expectations of full-stack devs who knew their way around the cloud. As a sidebar, we also evolved sysadmins to DevOps, SREs, and infra people due to the advent of the cloud. So, we do have specialized or intersectional roles that deal with the cloud. Regardless, the expectation, explicit or otherwise, is often there - a full-stack person should know cloud stuff on top of an already diverse skillset.
Personally, I never liked the idea of having to deal with the cloud. I can and like setting my apps and servers on bare-metal or on VPSs. Yes, it’s not super-scalable, but the real question is: does it need to be cloud-scale? Quite often, investing in cloud stuff early in a product’s lifecycle just adds complexity on top. But I digress again.
My point is - the full-stack role and the expectations around it got even more complicated.
So, what does that all mean for the generalist full-stacker today? Depends on the company, but I feel the expectations are broader than ever. With no sign of slowing down. While I feel like we need to redefine what the full-stack means, really, one key thing is that it’s a role that’s constantly evolving. That constant evolution means that we, as generalists, must remain flexible and open to learning new things. Personally, I feel like that’s a good thing - you never really run the risk of getting bored with your “toys”. We all have our limits and ranges of interests (I’m looking at you, cloud). Still, the flexibility and the ability to jump up and down the stack will remain essential for the generalist of today and tomorrow.
My previous points may paint an interesting picture, but we all suffer from one key constraint - time and, more importantly, the time we dedicate to being focused on one single task. No matter how flexible of a skillset you possess, you still have the same hours in a day as your more specialized counterparts. Shifting your focus from writing CSS to imagining a new feature to writing a REST endpoint has a time overhead - 23 minutes, to be exact.
On top of that, your energy stores aren’t infinite. I don’t have the scientific research to prove it, but I feel more tired the more I switch context. So you’re left with a choice - either plan for context switches to minimize their cost and time overhead, or you’ll have to embrace the chaos and the overhead that comes with it.
That said, I’m not much of a daily-level planner. My usual operational mode for these shifts is to stick to one task as much as possible, fight against new piling tasks (unless they are super-super urgent, but the burden of urgency proof is on the requester), and ultimately embrace the chaos. It works most days, but it’s far from a perfect system. I’m experimenting with a more structured approach, we’ll see how that goes.
While the point of having a broad skillset and flexibility to be able to jump in and out of different tasks stands, we are limited by time. Strategy is vital, as we are prone to burnout.
With ups and downs covered, there’s one key aspect that we didn’t - you can specialize at any time. Being a generalist, you already have at least some basics of a specialized skillset. That gives you an advantage if you decide that you want to specialize in front-end, or back-end, or cloud, or whatever.
This is likely one of the most significant advantages of being a generalist. While nothing is stopping a developer who decided to be a specialist from the get-go to broaden their skills, it’s often a more arduous path to take compared to already having a skillset that you can build upon.
Nothing is limiting you from doing it twice. Or as many times as you feel like. In fact, I’d argue that the ultimate full-stack generalist ideal would be “a jack of all trades and a master of some”. Specializing doesn’t cost you flexibility; it simply adds depth to an already existing skill set.
Broad plus deep in some areas is a great combination to have, and it opens up a lot of opportunities.
Being a generalist, or full-stack, or having a broader skillset does come with a set of advantages and disadvantages. It’s not for everyone; it can be energy-consuming, and it can burn you out quickly if you don’t have a strategy. But it’s a rewarding family of roles and a perfect fit for the curious mind that likes to learn new things.
On the other hand, the role also provides a unique perspective, allowing for a greater understanding of the bigger picture in a project. The ability to see and work across the spectrum offers a holistic view that specialists might sometimes miss. This is beneficial not only to the individual but to the teams and companies they work for, as they can provide insights that bridge gaps, improve communication, and optimize processes.
Additionally, the path of a generalist is often a journey of continuous learning. It’s not just about staying updated with the latest technologies or methodologies, but it’s also about understanding how different parts of a system interact and influence each other. This constant need for learning and updating one’s skill set can be a strong motivator for those with an innate curiosity.
For those who thrive on variety, learning, and adaptability, it’s a path worth considering.