Over the past dozen years, the term “full stack developer” became a popular way to describe someone who can deliver a full product or solution – from design to delivery, from data to visualization, from bits to pixels. “We need a full stack developer!” was the war cry request among those who had ideas and money (or both) during the web 2.0 era who wished to capitalize upon the opportunities, but, had none of the skill or experience to implement them.
Over the past decade or so, and despite my potentially limited exposure to the truly great minds and programmers of my era, I have run into maybe a half dozen of these uniquely people (aka “unicorns”) and maybe half of those truly embodied the term. To say working with these minds was a privilege and good for my career is an understatement – I learned so much in such a short period of time – they literally changed the arc of my career by my simply watching how they thought. Of that half, perhaps only two were a true joy to collaborate with – their personalities embodying more social graces than the others, always turning collaborations into playful or challenging hackathons filled with big laughs and amazing victories. Truly rare individuals.
What is really interesting to me is how the term and the stack(s) evolved. One early but misguided example of a full stack developer was someone who implemented web-based solutions using a LAMP (Linux, Apache, MySql, PHP) stack – but – a LAMP stack developer is not a full stack developer.
A full stack developer, in additional to implementation skill with a programming language also has comprehension about servers, networks and hosting, data modeling, business logic and API/MVC/service layers, and of course, User Interface, Experience and the all important customer’s needs. This combination of experience and skill is the superset to a LAMP stack and to me what a true full stack developer is (remember that the next time you hear the term used while hiring and you’ll always know what questions to ask next during your interviews).
Thanks to Steve Jobs, Google and the folks at Blackberry, mobile became a dominant platform for building solutions – literally transforming that plastic in your belt holster from a simple messaging device to a secure (?) Point-of-Sale device – granting you access to information, entertainment and vast arrays of goods and services wherever you stood on planet earth (and could get signal). That era ushered in even more blocks and stacks to support workflows across multiple network types, multiple desktop operating systems and mobile device formats. We now have operating systems that run on both desktop and mobile device, and, applications that run on desktop, mobile and home devices like tablets, televisions…even appliances – all receiving and transmitting signals of varying forms, value and purpose in support of businesses around the globe.
Oh, have I mentioned cloud or virtualization yet? The foundation of most stacks turned from “iron” (stacks of servers in racks, copper or glass cabling, networking, HVAC, diesel backup power, etc.) into a nebulous virtual reality (aka your stack hosted on “someone else’s computer”). Using a web interface to control your virtual data center, expertise became “silo’d” by brands (AWS, vs Heroku vs Google vs Azure) but the cloud opened the access door wide to cheap high availability computing – supporting the advancement of these integrated signal processing stacks and the storage of their vast data sets – the combination of which of course resulted in System Reliability Engineering, DevOps and Big Data. Since I haven’t mentioned it once yet, Security topics like authentication and encryption are not only components of these stacks, but, now come in stacks themselves.
The polygamous marriage of these interwoven stacks and the skills required to use them combined with the sheer amount of signals generated by hundreds of millions of desktop and mobile device users interacting within and across these stacks resulted in tiers of technology stacks being integrated to support not just the size of the data sets but how best to seize upon the opportunities created by the integration problems themselves. The accurate processing and profiling of the interests and intentions of millions of users in graph databases (e.g. faceted searching, what others customers bought, what other movies in the same genre are popular, likelihood a target plant an IED, etc.) has been rebranded into Data Science.
Given the hubris that is rife in our industry, especially amongst those fresh out of a decent CS program or a PhD factory, it’s comical to imagine the amount of time it actually takes to become an expert in any of these areas above in order to embody, much less state with confidence, that one is a “full stack developer” – especially just after you announce your most recent years were spent drilling a few hundred feet into an array of CS topics, or, drilling miles into just one (note: remember this as you interview coming out of academia). Sure, once employed, the chances of keeping a gig during a catastrophic financial meltdown are HIGH if you are a truly gifted developer or engineer, but, your chances of finding your unicorn, in any economic period, is LOW.
I question the value of anyone claiming to be a full stack anything. In fact, after watching the integration of many tech stacks into tiers over the past decade, I think we face the risk of losing depth and advanced expertise within these stacks and the use of term should essentially die…unless you happen to find yourself operating within or hands-on managing the aspects of an integrated set of technology stacks as your day-to-day job, and, you have done so for a significant period of time (rare). I believe very few of my peers find themselves in this situation and it’s why so few can translate their experience into what these terms actually mean. There is also a distinction here between being a ‘user’ of stacks vs a ‘builder’ of stacks but neither of those necessarily satisfy the definition either.
So, given the gumbo of web “3.0” buzzwords above, let’s ask a more serious question: how does one go about assuring quality in a technology stack? Wait, more importantly, how does one get themselves into a position being being qualified to assure quality for a multi-tiered technology stack like solution?
I know, quite the setup (sort of like asking you to explain how HTTPS works after you gave me 20 minutes on all of the technology behind a button press in a browser web app creating in a row in a database on the other side of the globe using HTTP), but seriously….
If you’re not a genius PhD with a widely read thesis on the properties, algorithms and applications of Euclidean Distance Matrices for ML who also spends your free time making millions from your interest-graph based, AWS iOS mobile gaming empire…that you built, tested and deployed yourself after an epic hackathon weekend using Jenkins, Chef, Go, Apollo, ElasticSearch, Swift, Appium and BrowserMob…how else would you even be exposed to the technology engines driving the largest companies our economies today?
I’m sincerely asking a very simple question here because so much of what we know about success in technology today relies upon understanding how to accomplish all of the above accurately and securely, at speed.
What I will say is that I don’t believe there is such a thing as a full stack SDET. Ironically, in the dawn of the information age I think test automation has become is something akin to a generalist skill set even though the label is frowned upon (aka Cliff Clavin) and mostly incongruent to the specialist role that an SDET truly is. In fact, finding a good SDET is like trying to find a purple unicorn. Without a doubt, a good SDET must understand how the tech in your stack works if you want to automate any of it. But, SDET’s also need experience using this technology hands-on, perhaps implementing solutions with the same building blocks in your stack, to better understand their limitations and how to build the right automation frameworks for that which needs testing. Additionally, if an SDET is supporting an entire SDLC or a methodology (Agile) or practice (Continuous Integration), the frameworks must take those design requirements into account. These are all factors in the design decisions you will make when building automation framework to support layer after layer of tech. Ultimately, an automation framework itself becomes a tech stack.
After 20 years in the game, I believe SDETs that want to be successful and valuable to their organizations must obtain a deep understanding of what to test by merging the goals of a business with how the integration points of these technology stacks could negatively affect those goals. In most or nearly all cases, you will find the problems have already been solved, just remember that not every problem is a nail requiring a hammer and try not to recreate the wheel.
Ultimately, it’s the integration of multiple existing testing technologies into a framework that solves the problems – what you test, you become. How well you understand your problem space is how well you will solve the problems of verifying it. If you do not understand your problem space, you cannot understand how to test it. How you integrate the tech needed to reach your goals (and how quickly) is what defines your true value to your org. Suffering oriented programming is your mantra in this regard (first make it possible, then make it fast, then make it pretty) – use this to drive yourself towards victory. However, when working with stacks in a start-up, Essentialism (the pursuit of less) becomes the one and only key to achievement. Energy as we know is a mostly finite resource, certainly this is true in humans – you can only work so hard for so long before your body and mind start to work against you. What you put your focus on grows stronger, and consequently, what you take your focus away from grows weak and dies. So, choosing not to work on the wrong things is as important as choosing the right things. More importantly, picking one right thing to work on will get that one thing done faster. The juxtaposition of this focus as it relates to full stack should be colliding head-on in your mind at this point. Good.
It is the merger of these ideals and practices with reality of the technology in use by our industry that should pierce your ego and give you pause. And in that moment, I hope it triggers introspection about what you think you know vs what you know. The conclusions of such thoughts should improve your ability to design ways to best test these huge stacks, how to answer questions during your next job interview and how you interact with your peers intelligently to assure the quality of their solutions.
Images borrowed without any permission but with much appreciation for Peter Yared’s The Rise and Fall of the Full Stack Developer, Ben Gilbert’s Battle for virtual reality: Google, Samsung, Sony and Oculus VR, Greg McKeown’s Essentialism, Little Red Elephant’s Stack and Swivel Clown and basically the interwebz.