Training T-shaped Developers
Why we don’t teach “full-stack”
At Momentum, we ask students in our immersive software development program to choose between front-end web development or back-end web development. As Momentum’s CTO, I get asked often why we made that decision instead of having one “full-stack” experience. It’s a good question, and we’ve thought a lot about it.
Twelve weeks is not enough time to get enough depth in the entire web development stack. It is enough time to build one good skill and a solid foundation on which to learn many others. We ask students to specialize so that they have a better chance at getting their first job and have enough confidence in their skills to continue to grow. Our experience has shown that those students will go on to work with many parts of the stack and many different technologies in their career.
Our goal at Momentum isn’t to make front-end developers or back-end developers. It’s to make, to borrow some jargon, “T-shaped developers.” I first heard this term in an interview with the CEO of Ideo, Tim Brown, who said:
T-shaped people have two kinds of characteristics, hence the use of the letter “T” to describe them. The vertical stroke of the “T” is a depth of skill that allows them to contribute to the creative process. … The horizontal stroke of the “T” is the disposition for collaboration across disciplines. It is composed of two things. First, empathy. It’s important because it allows people to imagine the problem from another perspective — to stand in somebody else’s shoes. Second, they tend to get very enthusiastic about other people’s disciplines, to the point that they may actually start to practice them. T-shaped people have both depth and breadth in their skills.
In thinking about how to achieve this goal, we examined outcomes from our previous teaching experience (all of our instructional staff have taught previously) and from our own careers.
My own career has touched on many different areas of computing. I started as a network security analyst after serving in the Army. My security clearance got me a job where they would train me in networking since it was cheaper to train someone with a clearance than to get a clearance for someone already trained. This was a huge break to get. I worked third shift in a basement in a government building for about a year. One of my duties was to sift through logs and write reports whenever there was a possible security incident. I taught myself Perl because I heard it was good at parsing text, and automated those reports.
Perl got me a contract job as a system administrator at a giant corporation. My group of a dozen people got all our tickets in one shared Outlook inbox, which caused a lot of confusion. I used Perl to download the emails, put them in a MySQL database, and then wrote a PHP front-end for managing the tickets. A fun fact: this is definitely the piece of software I wrote that has had the most impact. It ended up being used by many IT departments in the corporation.
There’s a lot of history after that, but to sum it up, I’ve written desktop programs in Tcl, created web applications in Ruby, built an API for a huge government database in Clojure, made interactive dashboards with Python and D3, and now teach front-end with React at Momentum.
Where you start in programming is not where you will end up. The world of software development changes so fast that you have to shift technologies and stacks to stay current.
In a very positive article about the term full-stack, Mike Bifulco, director of technology at Aquent Gymnasium, said:
When people hear the words Full Stack Developer, they typically picture someone in a web development role who can do all the work: from implementing the front end of the website and communicating with web services to actually writing the web services and storage back-end themselves. … While you may find people who can ideally put their fingers in all of those technologies, it’s going to be rare to find someone who is a deep expert in all those areas. … The reason their understanding isn’t as deep is that it’s easier to keep more up-to-date on technology if you have fewer technologies to stay sharp on. And there are a lot of technologies!
There are a lot of technologies. There used to be a lot fewer. In the earlier days of the web, you had Apache, Linux, PHP, MySQL, HTML, CSS, and a little JavaScript. Most of those are in flux now, from the operating system between containers and serverless, to Webpack and compiling multiple languages to JavaScript. I’m not complaining — programming is more exciting than ever! But you can’t specialize in everything, not all at once.
In this week’s Hanselminutes podcast, Dr. Neil Brown, the author of a recent academic paper on how to effectively teach programming, said:
One thing we find in programming education is a lot of the teachers often have this sort of full stack view of what’s going, that they’re doing Java, but they know how the Java maps into assembly code, and they feel like their students must also gain this knowledge. But the sort of still unopen question to some extent of whether the students don’t need any of that knowledge, as long as they have a solid notional machine of their high level language, it’s fine. … I suspect that cracks show through at points in the abstraction, but I think generally it’s probably not an issue if people just have an accurate notional machine of the high level languages.
This takes a broader approach to the term full-stack, but I think it’s right. If students can build that “notional machine” in their head, they can add to that later in their career. With our specializations at Momentum, we are introducing students to the first version of that notional machine, but we make sure to expose them to the next places they will go. Our Ruby on Rails students learn HTML, CSS, and JavaScript, and can build applications with a solid front end, and our front-end students learn how to interface with back-end APIs and have to work hand-in-hand with Rails students to design APIs for projects. Some of them even build small back-end services in Node.
To tie this all back to the concept of a T-shaped developer, we want to make sure our students can “contribute to the creative process” in their first job. By focusing on one skill our students know well, we help give them the expertise they need to be a contributing developer on a team. We help give them that same break I got so many years ago and get that first job as a developer.
