https://twitter.com/eranhammer/status/584011041702420480
This has become a popular topic over the last couple of years. Do you want a team of generalists who can jump on anything that is needed? Or do you need a team of specialists who go deep on a particular topic?
It isn’t shocking that the answer is almost always “both!”
Doctoring
Before we get to engineering and product development, let’s step up to tackle Eran’s question.
Chances are you have seen a full stack doctor, a.k.a. a general practitioner or family doctor. These are often an early line of defense (and thus need the skills to broadly triage) or are able to do routine check-ups. It is preferable that these people have the broad skills and are thus able to get a high level view sending you on to specialists as needed.
A nice trend these days is that of wellness where we think of this line of defense as a proactive layer vs. a reactive one. I personally use WellnessFX to proactively do this for myself. We don’t take measurements as often as we need to, to get a more dynamic view of our bodies.
When we get to the level of the specialist though, deep knowledge is very much required. We want people who know as much as possible about their specialty: both based on knowledge and experience.
ASIDE: When should I put in the age old joke of “What do you call the med student who came bottom of the class? DOCTOR!”
My guess is that this is the context of what Eran is talking about. He is a world class backend and node expert. If you want to build a system that has to scale and perform, he is up for the task (which is why I hired him back in the day!) This is not the same as grabbing someone who says they know “node” because they hacked some browser JS back in the day and just did a helloworld.js express handler.
Of course there is the in between. There is the experienced backend engineer who hasn’t done node before, but has built highly scalable backends for donkeys years. You could throw go at them, and after some quick learning they would probably be able to pull off what you need. I would much rather have someone who has experience scaling systems vs. someone who knows JavaScript for example.
The true specialists aren’t without fault though. I had the horrible fortune of having a kidney stone, an experience I wouldn’t wish on my enemies. When I met with my urologist he was so focused on the kidney stone that his advice included advising me to drink a lot of orange juice. You know, sugar. As much as I dislike kidney stones, I don’t want to poison myself and cause harm to my body in other ways purely to have an effect on the likelihood of getting another kidney stone.
Broad vs. Deep
You can either go very deep, or you can go broad. Horizontal or vertical. Wrong. This is a false choice. If you are trying to be a “full stack” developer by learning on the basics of many things then yes… you will be left as a true jack of all trades master of none.
There are other choices though. There is the path of the polymath:
“… a person whose expertise spans a significant number of different subject areas; such a person is known to draw on complex bodies of knowledge to solve specific problems.”
We (hopefully!) have time to go deep in multiple areas. I was listening to a man who turned 100 years old recently and when asked the question “Do you have any regrets?” he answered:
“I wish I had taken up the violin at age 60. I would have had 40 years to master it!”
Why do I sometimes fall into the trap of forgetting that I could pickup something new tomorrow and master it over time. It isn’t too late for us to do anything.
Then there is the notion of “drawing on complex bodies of knowledge to solve specific problems.” Cross pollination FTW! Some of the best engineers that I have ever worked with were not computer science majors, but rather music or biology majors. This is only anecdotal, and I have only worked with a small number of engineers in the scheme of things, but this has always stuck with me.
Dave Thomas, the Pragmatic Programmer, talked about how he would learn a new programming language every year. It would have the side effect of making him a better programmer in all of the other environments that he was proficient. I have seen this myself time and time again. My Java coding changed markedly after work in Ruby and serious JavaScript.
I sometimes look at teams as cells in an organism. I love diversity, with people from many backgrounds bringing something new to the whole. Some generalists who are able to jump into whatever is needed in a given sprint. Some deep experts who can go deep in various areas to tackle the gnarly problems. I love having both, and everyone learning from each other. If someone joins my team and they think they grok Android because they built an app at their startup they will be surprised at how little they really know once they work with some of our deep Android experts. The same is for the iOS, node, Clojure and Web teams.
Empathy
The full-stackers also have the advantage of understanding what life is like on the other side.
A large number of the problems I have seen with teams working with other teams is the lack of empathy, as shown in this extreme example:
Services Guys: “We need a PURE domain model and do the hard work. The client guys just need to paint by numbers to get the UI up there!”
Client Guys: “Why can’t the services guys give us a nice API that does everything we need the way we want it? It’s just a lil CRUD API… can’t you get that up in Rails in a couple of hours?”
A developer who have done real work in both areas knows the complexities of both worlds, and as they work on their side they can think about how the other side will interact with them.
This is the main reason I enjoy targetting test-driven development. It puts me in the mode of instantly thinking about how my customer will use the API so I can’t help but build it for them. The testing side is great, but more of an awesome side effect.
Speaking of “customer first”
It is no surprise that “full stack” has made its way outside of the engineering context. Chris Messina just posted about the “full-stack employee”, and maybe have talked about how more people are working across boundaries. Engineers doing design and product work for example.
It is a true super power if one person can take on multiple roles:
- They can have empathy and be great bridges between the disciplines
- There is a communications cost when you add someone to the mix, so if you can keep the team smaller you have less of that cost. Everyone has their own view of reality so you also have less (all incorrect 😉 realities to deal with
- They are often very productive jumping around.
There is some base level of knowledge that you would like your team to have. I split this up into:
- Core knowledge on important general areas (e.g. I think it is important for people to understand human psychology and the various biases that we all have, a knowledge that isn’t talked much about)
- Core knowledge of how we work: the values (from your team up the stack to the company), how we work with each other (processes etc), expectations of each other and the roles (including an understanding of what each role really does)
- Knowledge of the domain at hand (It is schocking how little of a shared context people in a team and a company actually have as the team should know what is important about their domain, their users, their KPIs, and what is being asked of them).
Once again, we want a core corpus and some people will go deeper, leading us right back to the Doctors. Don’t they do just this? They go through med school and get a base, once that isn’t surface level but fairly deep, and then they go deeper from there.
Sure, I wish that they would spend more time on nutrition (see: orange juice), but at least there is a shared based.
I am excited to work building and changing that base, and getting the right mix of deep experts, and people who have gone deep and enjoying playing in various areas.
I think this will be increasingly important as we explore new ways to work together: