What is "Full-Stack"?
What is "full-stack" development? What does a "full-stack" developer do?
Typically, developers who feel that they can effectively program across all layers of an application refer to themselves as "full-stack". While I've heard this explanation on numerous occasions, I'm reminded of the current state of affairs in the application development space every time I go through another round of interviewing candidates for a development position, or a recruiter knocks on my door conjuring up the term "full-stack" once again, not understanding the implications of their use of the term. Note that "effectively program" means proficiency in a particular area. The need for (i.e. not simply the desire of) someone else to clean up code after the initial development is done, whether to make the UI "pretty" or otherwise, indicates probable lack of proficiency.
As I write this blog post, there are actually 3 things from my experience that immediately come to mind.
The first is a particular discussion with a prior architect colleague a few years ago who argued that essentially all that matters on a development project is the Java code. Of course, we were working on a Java project at the time, so substitute whatever core technology applies in your domain. In response, I listed a number of other technologies that were being used on the project, and raised my hand, forming a small circle with my fingers to visually describe the amount of Java code that existed relative to the rest of the project (and the enterprise, for that matter), which I subsequently described by forming a large circle with my arms outstretched around the top of my head. Their response: "Everything else other than the actual Java code is 'infrastructure'." And what did "infrastructure" mean to this individual? "Everything else exists to support the Java code."
(In response to readers, note that other technologies being used on a given project can include an increasingly growing and evolving area of the enterprise called "DevOps", associated with the automation of software delivery and infrastructure changes, tooling of which can fall into a variety of areas such as continuous integration, version control, configuration, and monitoring. The idea here was to limit scope of this discussion to the actual application stack, which admittedly comes from a traditional viewpoint. While it might be debatable whether this type of work should be included in a discussion of full-stack development, however, in my view what is not debatable is whether everything else in the enterprise simply exists to support application code, or in this case, a subset of the code that is written for an application that likely provides job security for some. It does not – and this was the point of my referencing this earlier discussion.)