Note: This is Part 1 of a multi-part blog series which outlines the core principles of Project Shift's 12 Week Software Engineering curriculum.
In June of 2017, when we began building Project Shift’s curriculum, Sean and I started off by setting a few specific and ambitious goals according to what we wanted to accomplish through our curriculum. We knew it would be difficult to fit what we were trying to build into a “12 Week Code School” (the model that most people are used to), but we’ve mitigated that problem by having high admissions standards (students must be able to code when they enter) and small cohorts (max 10 students) - thus, we can give very individualized mentorship to help our students go faster and we can start from “20”, instead of “0” on day 1 of our program.
Part of what we discovered in the process of creating these “ambitious goals” is that as co-founders, though we’re both professional software engineers, we come from two very different professional backgrounds and could, therefore, leverage these two extremes of technical perspective to really re-create software education as we know it.
Sean’s experience before this was as a Chief Software Architect with over a decade of experience hiring engineers from all backgrounds and experience levels. Additionally, Sean comes to the table with a deep academic background carrying Bachelors and Masters degrees in Computer Science as well as teaching experience from previous code schools and collegiate level instruction.
I, on the other hand, approach this from a completely different background, having worked with or for a number of code schools (and having no academic coding background). I was one of the first students to go through Hack Reactor (just acquired by Galvanize, then called MakerSquare), then I went on to work as a software engineer and later created the first code school in Israel. It wasn't until I was working as a Software Engineering Mentor at Bloc did I realize how incredibly unique my experience was - to have seen, built or worked with the curriculum for 3 different code schools.
With both our own experiences on that table, we began to think through what it would mean to build a curriculum that could stand alone as a replacement for Computer Science degrees (at least for software engineers), much less a replacement for “coding bootcamps”. So we started by thinking about what the ideal software engineer would know and be able to do in order for them to be a great value-add to any engineering team from day 1, and most importantly, for years to come. In the end, we landed on a list of several things that would make for the ideal software education curriculum. With this blog, we'll give you the first “thing” and in the coming weeks we’ll post our subsequent curriculum goals.
Graduates Must Know “Full Stack” Development
It's true, if our students were starting from scratch, 12 weeks would not be enough time to learn the entire "stack" (both front-end and back-end). So many assume that as instructors we have to choose to either go deep and teach “front-end” OR “back-end”, or we can choose to teach “full-stack” but if we do, we must stay on the surface. We decided that we’d have to choose a third option, which is to teach “full stack” in depth. Of course, this is only possible for us because our students are not necessarily new to programming (they’re just not yet able to get jobs as software engineers) so we can start from a much more advanced perspective.
But regardless of whether our students go on to get jobs as front-end developers, back-end developers or full-stack developers, we believe that it’s vital to know both sides in order to be a great developer. To explain this to our students, we created this diagram that we call “The Loop”:
“The Loop” is broken into 4 quadrants and represents every interaction on the web (posting a post on Facebook, for example). The front-end deals with 2 of them, and the back-end deals with the other 2. Even if it isn’t your job to handle all 4, you must be able to do all of 4. What does it say about you as a developer if you can only handle half of an application?
With that, here are 3 reasons why we think learning full-stack development is vital to becoming a great engineer.
1. All developers should understand the full picture
In our fast-paced, learn-anything-through-youtube culture, it can be very difficult to remind ourselves of what "mastery" is. Coding is a craft that takes a lifetime of constant learning and adapting. Committing to know the "full picture" of how software is built is a key component of well rounded, hungry, curious, thoughtful and detail-oriented programmers. Want to learn front-end development? Learn it in the context of the full-stack. Want to learn back-end development? Learn it in the context of the full-stack.
2. Knowing full-stack enables you to be a team player
There is no one way that a software team looks. In other words, there isn't always a "back-end" team and a "front-end" team, and even if there is, they don't always have the luxury of being able to stay on "one side". The reality is, software is not created in a vacuum, it's created in the real world and in the context of a business. At times, this means that you need to be able to help your team deliver a product on time regardless of whether you're "front-end" developer or a "back-end" developer.
3. It's too soon to "choose" front-end or back-end
All of this to say, most developers do lean one way or another and for some, it's possible to tell what this leaning is from very early on, but we think that it's best to delay this "choice" as long as possible. The reality is, with little experience, it's just too soon to say what you're going to be. Be a software engineer first and learn how the whole thing works before deciding if you care more about the user or more about the data.
So what about you? Are you looking to transition careers into coding this year? What's your plan? Do have a mindset that's going to be committed to learning the hard way and to learning everything you need to learn to not just get a job but to play a significant role in tech? We'd love to help, even if that means we help you discover that Project Shift isn't for you.