What Does Full Stack Mean?

Table of Contents

• The Basics
• Programming Languages in the "Stack"
• How to choose your specialty.

One of the first questions we hear when someone starts researching coding bootcamps is “which programming language should I learn?” You hear these terms floating around like full stack vs front end vs back end – but what should you make of them? Today we’re diving into everything that goes into the application “stack” – from how each piece works together to the skills and tools you need to learn to the jobs you can get in each part of the stack. Our guest, Jeff Casimir is the founder of Turing School in Denver and teaches both a Back End Engineering and Front End Engineering course, so Jeff is the perfect person to help navigate through this question: “What is an Application Stack?”

The Basics

What does it mean when we talk about an “application stack”?

The terminology evolves from the way we talked about computer hardware and how traditional desktop programs run. If you are going to diagram the traditional execution model of software, you'd have a hardware layer down at the bottom, an operating system which controls the access to those hardware resources, and then running on top of your operating system you'd have different programs that are running and essentially competing for access to the hardware.

When you move to web applications, we just focus on what’s running on top of the OS and hardware.  No one pays attention to the hardware and the OS anymore; it's generally assumed that you have some commodity server hardware in a Linux OS.

What are the 5 pieces that make up the application stack?

Here’s the way I look at the pipeline: business requirements get turned into a functional prototype, which gets turned into a scalable application here, and then data is dealt with at large scale. To execute code, you start with business requirements – some product you want to build to serve a customer.

User Interface and User Experience Design takes business requirements and produces comps, Photoshop diagrams, or Sketch diagrams for the front end team. They create a non-executable markup of how that application should work. This part of the stack involves how a customer wants to interact, what kind of data they’ll have, how it’s formatted, and how they’ll work within the application.

Then Front End takes that markup and produce a working prototype in HTML and CSS, with some JavaScript. However, this is not quite a production-ready application.

The Back End team takes that functional prototype from the front end team and builds it into a system that can survive hundreds or thousands of requests per minute. They're diving a little bit deeper into the architecture of the real software, whereas the front end team really built the architecture of how the user experiences the application.

Working behind the back end is Ops and Data. The back end team produces a scalable application, but then you need the Ops team to actually get the application to run on the server, maintain the code, and to reboot if the code crashes. If you have any users besides your mom, then you start amassing a lot of data. This is where Data Science starts to work with the data that's stored from the back end.

How has the concept of the application “stack” evolved over the last 10 years?

I don't really believe in the term “Full-Stack” anymore. Over time, each of these parts of the application stack have grown into full-fledged disciplines of their own. You can be good at one specialization and fumble through a second, but there’s almost no developer who is good at, say, UI/UX and Ops. To me, a Full Stack Engineer would be able to do all of these things.

Modern web applications are so complicated. For example, 10 years ago, front end was so small. It was just HTML, and there was even a time before CSS! As CSS has grown and gotten incredibly complex and JavaScript is used for more than making sparkles on your mouse cursor, front end has become a full-fledged discipline. To me, the reason that we don't really have Full-Stack Developers anymore is because front end has grown from this teeny little slice that could almost be overlooked to now being a really important and complicated discipline.

At the same time, a Back End Engineer might be expected to knock out a decent UI and user experience, but our tastes and preferences in UX/UI have grown so significantly. It reminds me of watching a movie from ten years ago, and you see the special effects look terrible now because a less specialized person was probably doing that job. Now, you want a specialized developer.

Programming Languages in the "Stack"

How does this diagram compare to the way that applications are actually developed at a company?

It can vary pretty significantly. Some companies have a dedicated team for each of these parts of the application stack and hand off code from team to team. From my observations, the most successful teams have a mix of functions – a Designer, a Front End Developer, and one or two Back End Developers. Often Data and Ops are run as their own, separate teams.

Which tools or programming languages align with each part of the stack?

UX Designers use Photoshop, Sketch and whiteboards/paper. On the front end, you’ll use HTML, CSS, and JavaScript. And within JavaScript, we now have a growing family of technologies: jQuery, Angular, React, Backbone. Some of these libraries are advanced enough that they have their own syntax and can feel like you’re using a fourth language. If you’re a Front End Developer, you’ll always need to work in at least 3 languages, and that’s difficult. If you imagine speaking human languages, of course it's possible to be fluent in multiple languages, but you're not typically writing one paragraph in English, then one paragraph in Spanish, one paragraph in French and going back and forth. To me, that context switching is what’s challenging about front end.

Pro-tip from Jeff: One thing people don't understand when they're new to the industry is that most apps you're going to work on are old. I’m including Backbone in this list of JavaScript technologies, which people may think is an “old” technology, but the reality is there are apps that were built with Backbone that have been successful with Backbone; so if you're entering the industry, there's a decent chance that you get to work on the old code that no one else wants to touch.

On the back end, you've got a lot of choices. You could do Java, JavaScript with Node, Ruby and Rails, Python and Django, .NET. Whichever of those you use, you'll almost always use a SQL or NoSQL database. Within SQL, I’m seeing PostgreSQL as the dominant SQL database, but you may also see MySQL. If you were working in a .NET context, you would see Microsoft’s SQL Server or perhaps Oracle.

Although the list of languages is longer on the back end, a developer is typically working in one (maybe two). Back end is complicated and deals with structures and optimizations, so I wouldn’t say that it’s “easier” than front end, but you have to do less context switching.  

In Ops, you're living in Linux for 99% of the time. If you're in a .NET world, you'll deal with Microsoft products on the server and Azure, but most web applications will be Linux based. Some technologies that I like in the Ops space are Chef and Puppet.

On the data side, you will almost surely be working in SQL, but there’s also a quickly growing field of these large-scale databases.

How do you predict that this idea of the "stack" will evolve in the future?

I think that the expansion within each specialization is slowing down. What I think we're seeing now and will continue to see is more of a vertical change here. Ten years ago, a Back End Developer used one back end language, and in the future, you’ll need to learn multiple. GO and Elixir are really neat back end languages that are starting to push their way in to replace some of the bigger players. Most Elixir devs had a mastery of Java or Ruby and then got into Elixir. I think that will be the expectation moving forward.

In a world where most apps are dealing with some microservices, you're going to have a primary app in one language and a secondary app in another language. The expectation is that you're going to be able to hop between these and understand what's similar between them, what's different, and ramp up relatively quickly. It won’t be too tall an order to start in front end, get into back end, learn JavaScript, and then pick up Elixr in a couple of weeks.

As a coding bootcamp, is it your responsibility to expose students to all of these parts of the stack or to guide students down a specific path?

The approach that Turing takes is to teach some degree of overlap. Our goal is to teach both content and mastery, so the way we structure our back end program, is to teach 10-15% front end, and 10-15% Ops, so that as a back end dev you can still work with front end engineers and understand what they're talking about. In the same way, you should learn a little bit about Ops and Servers as a Back End Developer.

A responsible, effective Front End engineer needs to know 20% UI/UX and 20% Back End. A Front End engineer should be comfortable doing a bit of design, because if you get a comp from UI/UX, you need to be able to make decisions about a button animation or an interstitial page without going back to design.

At the same time, a Front End Developer should be able to stretch into Node as a JavaScript developer, or understand just enough SQL to responsibly set up the front end.

How to choose your specialty.

How do I know that a specific part of the stack will be the right fit for me?

Data science is the easiest. From my anecdotal conversations, people who are most successful in data science programs probably already have master’s and doctorate degrees in data, statistics, mathematics and so forth. If you already put in the years in academia, then go for data science. I don't see any strong indicators that someone should go into Ops.

Between back end and front end, you should ask yourself a few questions. If you feel more connected to users, the user experience, and how business processes run, then you should lean towards the front end. If you walk into a Chipotle and you admire the efficiencies with which everything is lined up, and you are the person who orders ingredients in the order that it’s displayed at the counter – you think a lot about processes and there's a home for you in front end. If you think about it in terms of the user and what the user experiences, then come over to the UI/UX or the front end side of things. If you walk into Chipotle and think, "I wonder how they know when to serve up another bucket of corn salsa just in time so that they're not dumping a quarter bucket out and so forth,” that's really the back end of the house.

What kinds of job titles match up with each part of an application stack?  

Front end is a pretty jumbled mess. You'll see titles like Junior Developer, but at one company, “Junior Developer” means HTML, CSS, and JavaScript; at another company, it means building APIs and Ruby. Even if the title is vague, the job listing should say exactly which languages the company is looking for: eg. HTML, CSS, JavaScript and Angular 2.0.

One common term is Front End Developer. Often Front End Developers are expected to do 50% UI/UX and 50% HTML/CSS with a relatively low expectation of JavaScript. But over time, as JavaScript is becoming more and more important, Front End Developers are sliding towards JavaScript. At Turing, we use the term “Front End engineer,” which means you anticipate spending the vast majority of your time (over 80%) in JavaScript.

In the back end, jobs are typically labeled Back End Engineer or Web Application Developer. That back end job would expect you to dip your toes into front end – to be comfortable following some tutorials or making slight edits to the front end.  

Again, the easiest to match is data scientist. It's pretty much the only term that's used if you work in data.

In Ops, you can be an Operations Engineer or Dev Ops Engineer. The line between those two titles is really blurry. Typically, operations engineers do a little bit more manual work and dev Ops engineers do Ops automation i.e. how do we automatically scale up thousands of servers? There's always a bit of tension between back end in Ops because back end wants to use some new library, but Devs Ops Engineers have to come to the rescue when everything burns to the ground. A lot of Ops expertise is built through trial and error, through doing the work, and I think that's part of why we've been slow as an industry to figure out how to train people because it's such a high-risk position. Taking on a Junior Ops engineer and having them run the servers for a day is a good way to lose $1 million in revenue.

Where does product management fall on the spectrum?

We actually just had our first student take a product management job. Really the product manager is closer to the business requirements and helping accomplish what customers want or what the business wants. Many developers will tell you that their favorite product managers or project managers are folks who have done one of these technical roles. If you understand what it's like to build software and you don't use phrases like "just move this thing over there,"or "just put a button on it," then it's easy to become a developer's favorite product manager.

If you think you want to become a product manager, I wouldn't do it right away. I would go into a front end or back end job and work in that for 2-3 years and get to really understand how those teams work, how products iterate over time, and then hop over to product management. You can get SCRUM master certifications, etc, but I’m pretty skeptical on those. Nothing will be nearly as valuable as the lessons learned in the trenches.

What if I make the wrong choice and end up in a part of the application stack that I don’t like? Can I move?

I want to make a joke and say "save up your tuition and go back to school," but that's not true at all. When you're doing a training program, we emphasize the process more than the specific technologies. The process that goes into back end work is pretty much the same process that goes into front end work even into UI/UX. This is not a commitment for life at all.

You will see people migrate across the application stack. I have friends that started in design and are now back end engineers; or back end engineers who become Front End engineers. Each is complex enough that when you move away from one, those skills start to atrophy relatively quickly and obviously the libraries and technologies change.

We tend to see developers migrate more from back end to front end than vice-a-versa. I have to say that I think front end is a little bit more fun. You get to see your results more clearly. There was a stereotype for a long time that front end wasn't real programming, but that probably was never true and it's definitely not true now. Front end has grown to be complex, interesting, and deep on its own. At Turing, some of our students will graduate from the back end program and take a front end job.

It's a reasonable goal to have a fluency across the stack, so that you can speak to each specialist. But you’re probably not going to be the key developer in multiple parts of the stack.

So a student should specialize in a part of the application stack instead of aiming to be a “Full Stack Developer?”

When people say “full stack” what they mean is a Back End Developer who can do a little bit of front end. It's actually surprising, I think most developers are pulling back from Ops over the last couple years. For example, five years ago you were expected to be able to deploy your own code and now that's not an expectation for most devs.

Back end seems to have the most choice in languages – where do you see the most demand for jobs in back end languages?

If you go today on Indeed and search for jobs, you'll find 30,000 listings for Java jobs. Some people will use that as evidence to say, "See, Ruby is dead. Python is stupid. Nobody uses Node.” In reality, 10 years ago there were also 30,000 Java jobs. There will be Java jobs from here until the end of time. If your goal is to pick a technology in which there will assuredly be a job for you in 20 years, then your choices are either Java or JavaScript. We will be writing JavaScript 50 years from now, and I can't say that about most of the other back end technologies. I think JavaScript is a really a safe bet. I'm not a big fan of the Java ecosystem because having Oracle as the captain of that ship is questionable to me. I have a hope that one day another company like Red Hat will buy Java away from Oracle and be better community stewards. But Java has good potential.

Despite my early hating on Node, I think it's growing into a healthy ecosystem and some neat things are happening there. Ruby and Rails is obviously huge in the bootcamp space. It's not as cute as it was a couple of years ago and it doesn't catch people's eye, but it is very established now. When we talk to enterprise companies that are hiring large numbers of developers, Ruby on Rails is still a fringe technology that they're excited to start using.

It’s too early in GO and Elixir to focus an entire training program on those languages.

The outlier to me here is .NET. I'm not a huge fan of closed source ecosystems. .NET may be technically open source, but it's very closely steered by Microsoft and that's always made me uncomfortable. I'll say that Microsoft is becoming a lot better and a lot more progressive over the past couple of years, supporting open source and doing interesting hiring practices. So that might change.

It's pretty hard to hit a dead end if you learn Ruby on Rails, Node, Python, etc. If you're good at any one of these, then there will be jobs for you for a long time.

How do I choose a programming language to be employable?

To be successful in a first job, and successfully promoted, somebody has to practice their process more than practicing their content mastery. One of the ways I see folks do it wrong is that they hop across all of these technologies; they do JavaScript for two months and then check out Ruby for six months and then a bit of Java for a month. That's neat if you're trying to sample a buffet and see if anything speaks to you; but if you're trying to be employable, that's not the way to do it.

Pick one language and stick with it because the content itself doesn't matter. If you study .NET and you get good at building .NET apps, then you can easily get a Python job as long as you can show the process you’ve mastered. If you have a strong process of building software, you're employable across this whole pipeline.

Read Turing School reviews on Course Report. Check out the Turing School website!