The Full Stack Developer

When I think of the stack that a full stack developer has complete mastery of, I think of LAMP. This stack, comprised of Linux, Apache HTTPD, MySQL and Perl/PHP/Python, neatly summarises the components required to migrate from static websites to interactive web applications. My hat goes off to anyone who could configure Linux, install HTTPD, configure a database and then integrate all the components with a fledgling language like PHP 20 odd years ago, because I can only imagine the command line wizardry that would have gone into such a project.

To give you some idea of the kind of web applications that were being written 20 years ago when MySQL was released and the LAMP application stack gained its “M”, the term “blog” was still a few years away from being coined. These web applications were still comprised of mostly static content, but now with the ability to dynamically source some text from a database. In fact PHP used to stand for “Personal Home Page”, and it started life as a suite of scripts designed to track visits to the online resume of PHP’s inventor, Rasmus Lerdorf.

Web applications have come a long way since the first blogs. And unfortunately the term “full stack developer” can no longer describe a single employee who has a complete mastery of each component that goes into even a fairly standard web application by today’s standards.

Let’s take a brief look at some of the elements of the full stack that makes up a web application in 2015.

JavaScript and Whatever You Use on the Backend

The days of developers mastering only one programming language are gone.

The reality is that if you do anything that touches the web, you need a good understanding of JavaScript. JavaScript has won the war of the universal platform, fulfilling Java’s goal of “write once, run anywhere” (though JavaScript is currently closer to Java’s early days of “write once, debug everywhere”).

But mastery of JavaScript is only half the battle. If you write web applications, it won’t take long before you need to learn one of the many libraries that make up the JavaScript ecosystem. This is not as easy as it sounds:

Every six months, a hot new framework hits the mainstream, and our community explodes with excitement.

Don’t believe the hype.

That image is as humorous as it is accurate. The JavaScript ecosystem is awash in libraries and tools that require quite a serious amount of devotion to master, and you don’t get to learn just one.

Then, behind the scenes you’ll probably be running your backend on C#, Java or PHP. While these platforms don’t suffer quite so much from the frenetic pace of JavaScript libraries, it would be a mistake to think that they don’t take time to master. The image below shows Oracle’s certification path on Java EE. Even for a seasoned developer, each of those boxes represents a good few months of study to pass the exam. Mastering each then takes years more.

Security

What do Linked In, Target, Yahoo, Sony and Adobe all have in common? They have all been hacked, releasing millions of pieces of personal information and costing at least as many dollars.

20 years ago, not taking network security seriously meant someone might rewrite your blog. Embarrassing, but not devastating.

Today not taking network security seriously leaves you open to an entire subculture that will expose your company's private data and you customer’s personal details for lulz and profit. Not to mention that nation states aren’t shy about poking their noses into your network either.

The OWASP project has done a nice job of distilling the most common security vulnerabilities into a top 10 list. But don’t let the nice round number fool you. To actually identify and rectify these issues in legacy code bases is a specialised job. And while prevention is easier than cure, it does take a decent amount of experience to identify security flaws when planning and writing new code.

Testing

Testing is a simple idea that has incredible scope. Unit testing, integration testing, user acceptance testing, performance testing and black box security testing are just some of the kinds of tests that you will need to run at some point on a modern web application.

It takes great discipline to be able to write testable code, and quite often you’ll need to learn (or create yourself) different tools for each kind of test. And, of course, you’ll probably be testing two different languages, which also increases the number of tools you’ll need to learn.

UX

Apple took the world by storm with a beautifully designed mobile phone. Google has Material design, Microsoft its Modern design.

The effort that these companies have gone to in expressing their vision for how we should interact with our apps and devices is staggering. Consumers have an expectation that their digital experience will be natural and engaging, and today’s developers have to deliver.

To give you some idea of how detailed these UX specifications are, Microsoft has a training series called Windows 8.1 UX Design Jump Start which includes 9 hours of video. That is just the "jump start".

API Design

This is somewhat the reverse of UX design, designing an interface for developers to use, but the standards are just as high. With the API economy set to redefine how business is done, developers are expected to be able to construct standards compliant, expressive, secure and performant APIs.

Of course, there is no one way to design an API. Maybe you go with a well defined specification like SOAP, or maybe you embrace the newer REST paradigm and adopt a community standard like HAL, JSON-LD, Collection+JSON, SIREN or JSON API. Then you need to think about how you design these APIs, using something like Swagger or RAML.

Learning the intricacies of any of these standards or tools takes months, and because this discipline is evolving so rapidly you won’t have the luxury of learning just one.

And So On

I’ve picked some of the bigger responsibilities of developers these days, but the list goes on: documentation, database design and interaction, cloud deployments, source code management, log file analysis, machine learning, big data...

Facing Reality

The term “full stack developer” used to mean an individual who could reasonably be expected to understand, deploy, configure and maintain each component that went into an application.

The term no longer applies. There are just so many aspects to modern development these days that it is unreasonable to expect that any one person could have a high level of experience and expertise in more than a few components of the stack.

But this is not to say that there is no such thing as a full stack developer.

I would contend that today a full stack developer is someone who has enough experience, intuition and dedication to take any aspect of modern software development and see it through to production. Or, as Josh Wulf puts it:

In the absence of historical validation of technical skills, and in the absence of a static IT culture, Herb Kelleher's maxim: "Hire for Attitude, Train for Skills" is more relevant than ever.

This doesn’t mean you are a DBA, but it does mean that if you need to get some production data into a database, you can work out how it should be done. Likewise it doesn’t mean you are a UX expert, but when tasked with designing a UX, it means that you know where to look for guidance and you can put together an interface the embraces the best practices being developed today.

A full stack developer can get things done, even if they don’t readily have the experience or level of expertise that the task may require. They are jack of all trades, and master of one or two.