Mastering the Entire Stack
I had an enjoyable meeting with a peer of web dev wizardry the other week. He was illustrating a development framework for web apps that he created, talking me through the many layers of the architecture. While enjoying the discourse there was one small thing that he said that I thought profound: “no one’s a master of the entire [web technology] stack”. He said it so matter-of-factly, no big deal, just a transition sentence to frame an illustration of the beauty of one smart abstraction or another in his framework.
No one is a master of the entire web tech stack.
(For those of you not familiar with such nerd speak, the “stack” we’re referring to is the several varied technologies, each layered upon the previous, which collectively comprise and power web applications. Server runs upon operating system, database runs on a server, business logic uses database, and so on.)
No one is a master of the entire web stack. Conventional wisdom. Self evident. But of course.
I disagree. My musings in the last few months have led me to curiosity about my staunch opposition to conventional wisdom that [non-trivial] application development requires a large team, large budget, and long time lines: am I full of it? Is there something I’m missing? Where’s the loophole?
Mastering the entire stack might be that loophole.
(A quick technical caveat for the nerdy purists in the house: I don’t pretend that I’ve mastered the literal entire stack, for example I know only a little about the L in LAMP stack1. But since you do things nearly identically on the so-called WAMP stack (swap in Windows for the operating system), I don’t think my craft suffers for it. This suggests there are some shortcuts one can take while effectively maintaining mastery over the technologies that make a difference when creating web applications. Similarly, one can get by with only crude [or even zero] knowledge of, say, hardware level logic gates and assembly language, which are also part of the rigorously defined entire stack.)
For this discourse I say the entire web stack that matters in web application development is comprised of: database, server side language, HTML, CSS, JavaScript, and enough knowledge about server software and hardware performance to not be blindsided by rookie mistakes nor dumbfounded by scalability challenges. That’s it, and there is plenty of depth and mastery in each of these layers. Regarding this web stack, my friend was approximately right: developers who are masters of it all are super rare2.
This I think may be my loophole. In a world where designations like “database admin”, “front end developer”, and “back end developer” comprise commonplace job titles, it’s obvious that most teams and individuals in my trade are sold on segmentation of skills along slices of the technology stack as the best way to do it. Specialization and depth over broad, general skill sets. Makes sense, our civilization has been going in that direction for centuries.
But does it need to be? It’s certainly not ideal: communication overhead and inflexibility makes it easy for me to best most teams on price, time and quality, I have enough client horror stories to assure me of that. So then is your average developer stuck in a niche, unable to branch out their mastery because it’s too much to handle? Am I just a genius? I don’t think so.
I think above all it’s a matter of just trying. Overcome that little voice in your head that says “who am I to design a schema without the fancy title of Database Administrator?” and just do it3. Play with a nice JS framework and make some cool AJAX stuff happen on the client side of things, most of the hard stuff is done for you anyway. Learn a few CSS tricks and experiment with making things pretty instead of stark utilitarian. I bet the average pigeon-holed developer could explore in other parts of the stack and be at least baseline proficient in all of it with just a few weeks of dabbling on the side. It’s those Renaissance-type developers that you really want.
Notes:
- For the non-nerds hanging along, LAMP stack refers to Linux operating system, Apache web server, MySQL database, PHP server-side language. ↩
- Add in ability to represent strong in the boardroom talking business needs behind the software, and they’re damn near impossible to find. Ahem. ↩
- I dealt with this very concern when I built my first web application to manage my department at MonsterCommerce. It wasn’t that scary, I learned what I needed to as I went and cleaned up any rookie sloppiness as I got better. ↩
Next: The Right to Demand Satisfaction
This is Programmer for Hire, a series of essays and explorations on the art of being a great programmer doing on-demand custom software development.
Hey John,
Might I compliment you on your beautiful name?
I had a similar experience at a conference in October. An entrepreneur was giving a talk on building start-ups based on a specific web framework. He started to talk about hiring programmers and made the claim that, “back end developers only are good at back end and front end at front end, don’t ever hire someone who says they can do both.”
I thought, “that’s odd, I’m good at both.” Later on he happened to catch me working on something while listening to someone speak. He seemed amazed that I was building it while I listened. It was a front end interface, and while I’m no slouch on the front end, I am much stronger on the server side.
I do agree with you that it’s possible to find developers who are proficient across a spectrum of related technologies, as I believe myself to be (Yay LAMP!), but I think that it is highly improbable to find someone who can truly be considered a master of more than two disciplines, let alone three or more. Really, to master one is extremely difficult and to be applauded (I believe that mastery is far beyond being able to adeptly use a technology.)
When you begin to interweave indirectly related experience and knowledge that is critical to performance, like project management, software architecture, specific frameworks, specific web based apps, design patterns, build tools, unit testing tools, integration testing tools, IDEs, image manipulation software, mobile device constraints, common API architecture, and etc. “mastery” gets even trickier to attain.
To sum up: Padawans aplenty, Jedi Knights uncommon, Jedi Masters exceedingly rare. I agree however, that real Jedi Knights are strong enough to handle most multi-fauceted challenges. And we deserve every penny we get (though hopefully not at an hourly rate ;) )
@John Hooley
Hi John,
You make a great point about the definition of mastery. My operating definition in this essay is somewhere between competent proficiency and the level of the mystical, a la Jedi Master: that level at which one is able to flow through the work quickly & efficiently, make it appear effortless, and if there are any skills or deep knowledge one lacks, a savvy observer would be hard pressed to recognize as much.
Thanks for adding your thoughts–I dig your style and ethos!
Interesting topic. With respect, I disagree with both John’s here, and agree with the originator of the statement:
“No one is a master of the entire web technology stack. ”
There are two issues with any caveats employed around this statement:
1) Mastery is *mastery*.
From a novice’s perspective a sufficiently advanced user may appear to be a master – but then again any sufficiently advanced technology is indistinguishable from magic :)
2) The entire stack is the *entire* stack.
Including the bits we don’t need to touch often, or ever. There’s a lot of stuff we can consider “black box” and never touch, but they are part of the stack.
Some of it we really can abstract away from – e.g. OS internals, particularly in a closed source OS. But there are parts of the stack that we can influence but in most cases don’t even need to. Take OS configuration for performance – that’s something that few will ever need to know and only when working in high performance datacentres. Not being a master of that doesn’t prohibit claims of being a master of all technologies required to deploy a high performance site.
Perhaps it’s a question of Known Unknowns and Unknown Unknowns.
I’m certain that the author and many of the readers here are masters of some – even most – components in the web technology stack, but not all. And I don’t think there’s any problem with that.