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?”
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.
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.
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.
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?
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.
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.
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?
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?
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?
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.
Watch this Python vs R video tutorial from Galvanize instructor Sean!
Watch this Python vs R video tutorial from Galvanize instructor Sean!
Learn why (and how) you should search for an internship with Rachel Bussert of Epicodus