The meme above could potentially be casting shade on “full stack devs” by depicting them as a drawing of a horse but where only the backend is drawn out. If you were building a team, would you rather have that meme image above, or a developer who only knows one part of the system?
Personally, I would take that meme image in a heartbeat. I’d also take a “partial stack” dev if they are curious (described below).
I mean I get it. It’s a funny meme, but we need less walls and more bridges. All too often, managers stand behind tired ideas like “there is no full stack developer” and then force team structures that prevent good, quick conversations. Listen, our users don’t care about our architecture, they care about the code working end-to-end. I’d prefer that managers and leads invert their thinking or at least open up to the notion of a happy, autonomous team.
I think the best rationale for a “full stack dev” is that the healthiest teams are full of empathetic people who are willing to put themselves in the shoes of any member of their team (regardless of where they specialize) so they can learn about the challenges of their teammates. It’s a great way to ensure:
- team morale through empathizing
- domain knowledge transfer
- better estimates since everyone has passing familiarity with each layer of the stack
- people can help out in a pinch (if needed)
Modern web development is pushing hard for “full stack teams” not “full stack devs.” If there was an image like that of me, it would be a horse with mostly the ribs and the abdomen shaded in. I am no CSS expert, nor am I a SQL guru. Each person will always have their strengths and weaknesses, but together the team should be fully autonomous and productive. I mean it. Each member of the team is valuable.
I know that I shouldn’t be so bothered by this but I am. And if I’ve learned anything from the Buddhist scholars that I use as research for this blog... it’s that you shouldn’t cast judgement on your emotions—- you should accept them. And I’m accepting the fact that I’ve been burnt by teams before that were not truly operating like a team. I don’t want to wait 2 weeks for the backend developer to get back to me with a new API so I can finally start my UI task. Let’s just work on the API and the UI together.
What do you think? Has your company pushed too hard for split UI/Backend teams? Have they pushed too hard for full stack teams? Are there other ways to keep collaboration and empathy high?
———————————————-
If you liked this article, consider reading:
Go Home: 4 Techniques That Help You Leave Work At Work
or
How Buddhism is Agile
or
10+ Tips To Find Peace In A Loud Office
Top comments (127)
You didn't explain why you take it personally. I was looking for the part where you say that you or one of your friends is a full stack developer, but didn't see it. In other words, if there is an offense, who is the offended party?
What I instantly saw is that someone knows how to draw an entire horse, but they're much better at drawing one part of it than at drawing the other.
I see it more as making fun of what happens when the industry invents a useless, meaningless label and then pressures developers to identify with it.
The most fun I had was on a team where I would develop everything from the backend database and services to the front-end rendering and JavaScript. Then, right at the point where it came time to apply CSS I'd hand it off to people who were really good at it. We'd collaborate a lot on the front end, tweaking the HTML and behavior.
Pushing more on the front end improved my skills. I didn't become a JavaScript rock star but I wrote good, maintainable code. But if I did the whole thing myself it would look like the front of that horse.
I don't think that "full stack" is much more ambiguous than "front" or "back".
Does anybody expect a "back end" developer to be a master of all things back end? Dos, Bash, distributed systems, SQL, C#, Java, C, Rust, Encryption, Networking, Cloud, REST, SOAP, performance, Graph databases, Timeseries databases, multi threaded concurrency, Hadoop,MEF,sharing memory, etc?
And what about solo developers? Stardew Valley (game) was written by one person, were they a front end or back end developer? Seems to me like they did a great job at both, so why refuse to call them by one of the best terms we have for them just because that term is flawed.
Can't we just agree that naming is hard, and let people call themselves whatever thing they think works the best for them?
For me, I define full stack as being able to throw sysadmin and DevOps skills into the mix. I can built components in React but you should not ask me to style them, I can write and integrate with APIs all day long, but I've always been the one who volunteers / is volunteered to maintain the build pipelines and handle deployments and I've picked up a lot more than I ever wanted to learn about DBA stuff from an incompetent coworker. I define a full stack dev as someone who can contribute to any area of the project, maybe not the most effective or fast work, but still contribute nonetheless.
And I bet your team loves that you pitch in! :) That’s awesome. :)
Love it, I'd much rather work with somebody that says "How can I help?" than "Not much job!".
That's so true and funny. If "front end" and "back end" actually meant anything specific then "full stack" wouldn't be ambiguous at all. It would just be front + back.
That's exactly the way that I understand this meme as well. I love working on frontend and backend myself, but the term "Full Stack Developer" is too often an excuse for a company to invest too little in people and then expect too much of those few "Full Stack Developers".
It's also about the reduced value of of "just" being a Frontend or "just" Backend developer. Yes most of us know both sides, but there's always one side that you're currently much more focused on.
Yup, you have a pretty great example of a high functioning team that shares and understands each team member’s strengths and weaknesses. I did mention it in the article, but I have worked on products where the front-end team was in a completely different team than the backend team. That’s the organizational disfunction that I’m trying to help eliminate.
One approach @charlie is to ask your job interviewers how they handle a sprint (or a release) where one of the specialists is out. If they answer with, “oh that’s not a problem, we all pinch in where we can” then you know that you’ve found a reasonably healthy team. If they struggle with the question, or if they say “well we just move the deadline” you might have to dig deeper.
Hey I'm the guy in that photo!
I imagine the full talk will be posted soon on Smashing Conferences YouTube channel, where anyone could watch for more context here.
Here's my follow up slide, which is more of a self-portrait really:
Thank you so much Chris for making me aware of where the slide was from. I gave you a follow, you can follow me back and DM me the link when it posts. I’ll update the article then with your link and the credit. :)
I think it's just a cheeky joke. The point it underlies is rooted in truth - that it's really difficult to master both frontend and backend development in real life.
Yea, I find it hilarious, but I try not to take it too seriously/literally. It especially amuses me because I'm currently in a "full stack" position, but am a much stronger front-end dev.
Haha yea. It’s best to take things lightly. I must admit that part of me couldn’t from all the times of being split into two teams. And as a generalist I’m always like, “okay... uh which team should I go on? Backend or Frontend?”
P.s. more power to you that you’re a strong UI dev. CSS is hard! :)
Yea, I did laugh pretty hard. But then my stomach turned a little bit, because I know that the belief is used to drive teams to be awkwardly structured.
I think the meme is perfect. In interviews anytime someone says they are a full stack developer I ask where their strengths are. If the tell me they are equally good at everything I assume that they aren't very good at any of it or at least dishonest. The tech stack is getting too big and complicated to be an expert at everything. Having the ability to learn is much more important than what you say you know.
Yea I totally agree with your points. I think I might steal that interview question of yours. Humility and self-awareness are really important in a career like ours that requires constantly reassessing what you think you know. In fact, many of my articles in the queue are all about accepting your weaknesses so you can learn. Thanks for the great thoughts. :)
What do you call each of these developers...
Sure, the term "full stack" is not accurate but what name is? Is "Software Engineer" or "Software Developer" any less ambiguous?
Those titles translate to:
I think titles are fairly worthless. I've gone from analyst to lead to programmer to engineer to consultant etc etc. What I do never really changes, I just try to learn stuff and use the best tools I can within the constraints I am given. You like to call yourself a full stack developer, if I asked you that question: "Where are your strengths"? Would you say you are equally good at everything? Or could you specify and say, "I am competent full stack dev with this specific tech stack". That is a completely honest and accurate statement. The only point I was making is that no one knows everything, whether just front or back. Everyone has their own slice of the technical pie, and that is OK. If you are a competent developer then you can effectively learn anything if you need to, that's what matters. Not what you know but what you can learn, which is why I feel being humble about what you do know is so critical. Most devs I have ever interacted with that sell themselves as full stack, are more just full of themselves. (to be clear that isn't an accusation)
"Those titles translate to:
Developer
Programmer
Engineer
Code Monkey"
I don't understand your reasoning here. What makes a back-end dev a "developer" vs a front-end dev a "programmer"? Were you being facetious?
That was satire, the next sentence was "I think titles are fairly worthless". I was trying to make a point titles are arbitrary and have less to do with what you do and more with who you do it for.
Ok :) thanks for clarifying
Yes, humility and a willingness to fail is what I’m always writing about. A+ response. :)
I really think there's isn't anything wrong being a generalist or a specialist throwing insults at some people's choice on the type of work they do is just pure lack of self-confidence.
I really wish that they could look at how special ops team are trained like the navy seals.
They each have their own specialised work but is cross-trained to the point that they are taking on the buck. When one of their's specialist is out of commission.
I went through similar military training as a military scout. That's why I'm totally fine with either being a generalist or specialist.
Since your aim is to deliver great software on time and within a budget that the user or people who pay it and continue to buy from the company or you.
I really love this response and your metaphor for military teams. Maybe the solution is to prioritize the needs of the user first and then to have a good conversation with all of the developers about which team structure supports those needs but that allows the team to be it’s happiest.
Yes totally :) It's the strength of a team that gels and blends well together to become an unstoppable force to achieve the objective be it to deliver software or make a difference in their contributions combined.
Hum... That's a tricky subject. While I aknowledge your points I guess it really depends on what your company is producing.
I completely agree if your company has tightly coupled backends and frontends (a web service per web site). In that case having a "full stack team" implementing the cultural points you gave makes complete sense.
That being said, I think that this tends to be less and less common. You can be in a situation where you have to develop/maintain a web service accessible by the end user throught both a website and a mobile app. In this situation I don't see how you could get an efficient "full stack team". The frontends technologies vary too much. I would probably go for three independant teams and some people acting as bridges to synchronize all the efforts.
As you might have guessed I have mostly been in this second situation. That's probably why, without any context, I don't understand this meme as criticism for the developers and rather see it as a criticism of companies/recruters who are only interested in "full stack developers" even when this requirement doesn't match their needs. Thus they end up with apps that are perfectly illustrated by this meme because the developers they hired, as "full stack" as they are, do not master the specific frontend technology they had to use. I'm probably wrong with this interpretation but that's definitely how this meme resonates with me.
Thank you for the thoughtful, measured response. I think the second case (the separate UI and API teams) works best in the case of a product that is heavily API focused, like traffic data, weather data, analytics etc. and those companies tend to monitize their APIs. But if your company is selling a tool as opposed an API, then I tend to favor the “full stack team” so the whole team can focus on getting value to the user instead of having conference calls about the value of “separation of concerns.” I see that all the time at the companies I’ve worked at and it’s a big sign that the team division is hurting not helping. When those teams have reorganized, the work is completed faster. And I don’t think the separation of concerns or the architecture suffers too much.
But I hadn’t thought about native mobile UIs like you mentioned. It is a real problem to source talent in Swift, Java, and JS/TS. So yea you’ve got me thinking now.
Maybe it works sometimes but not all the time?
I agree with you that it is critically important for a dev to understand the full stack. Separate front end and back end teams result in all sorts of communication issues and possibly an us vs them attitude.
That being said, the meme does have a point in that both front end and back end development are so complex that you really can't master both. Learning more about both can help, but the wide breadth of technologies involved make it so that there's barely enough time to really master one side. It also is just coincidental that most full stack devs I meet are better backend devs than front end devs.
Has anybody ever mastered either back or front programming though?
If so, then I would really love to meet the front-end coder who has mastered all of the things that the front-end entails - like UX, design, Data Visualizations and programming. Heck, I have yet to meet anybody who has mastered any of these skills.
If nobody is capable of mastering the front or back, then why care about whether or not someone calls themselves full stack?
I like the term "full stack", because it helps select for developers that either enjoy working in the middle, or have strong skills in areas on both sides. The wide world of programmers has tons of devs working independently or in small shops that have to operate on both sides, and I've known plenty of devs that can sling SQL just as well as JS.
If all terms are bad, why not just let devs call themselves whatever term they think fits best?
Depends on your definition of "mastered". Mine isn't where someone literally knows all there is to know. It's when they are confronted with a problem that they have not encountered before, but have a clear idea of how they want to solve it. I've done enough backend work to be able to make this claim for the vast majority of backend problems. I can't make the same claim for frontend work despite having done my fair share of it. Sure I can search for solutions, but it just takes me an order of magnitude longer than it would when I research solutions for backend problems.
All terms are bad in many ways, but there is a case for standardization. Standards are about making communication easier. Just like we have code standards to make it easier to read each other's code, we also have language standards. While I agree the term "backend developer" can mean all sorts of different things to different people, it would be nice to have terms we can use to summarize what we are capable of rather than listing them all out (e.g. knowing SQL syntax vs creating data models at scale). Then again, the range of technology is so diverse that maybe that just isn't possible.
Yea, I think it’s about finding that “middle path.”
It offends me too, mainly because I feel I have to fight silos wherever I go and I feel that the FE/BE split is another horrible silo.
No, I'm not the best FE dev or the best BE dev but, dammit, I'd rather every dev on my team pitched in with whatever needed doing that day rather than remain willfully ignorant of the rest of 'the stack'.
There's going to be days when I want my CSS expert be nailing their CSS thing. But there might also be days where I need to do that instead, or where the CSS ninja has to redeploy the application. Or read a Java stack trace to find out what's gone wrong...
Specialization is important, but at the end of the day the customer doesn't see FE/BE/DB/CSS/UX/UI/W/E...
They see a website that either works or it doesn't. And that's everyone's responsibility.
Cheers! I'm with you, the world is a big place and it takes all types of people to get along.
I'll keep calling myself a "full stack" or "software engineer" until I find a better name for me, and I'm not going to let anybody tell me that I've been a "myth", a "lie", a "scam", or "stuck" for the last 18-ish years.
Yes yes yes. I can’t agree more about your point about “fighting silos.” I think this all breaks down to two points (that I’ve learned through researching some upcomming “mindfulness at work” articles) where Buddhism teaches:
So if you put those together, you will try to structure the team in a way that highlights good communication and you’ll foster practices that encourages the team to collaborate. As you said, it’s all for the end goal of helping the user. Thank you so much for your comment. Please keep trying to fight silos. It’s tough work, but the customer thanks you. :)
It's a little tongue in cheek, but not insulting. Either way you get the whole horse, just one part is a little less detail oriented. It's the same idea as having "T shaped" knowledge. Wide and shallower, but also deeper in a part. That's a good shape to be.
Yup, it really is a funny meme. And thank you for reminding me of the “T shape” concept. Do you know who coined that? I’d love to cite that author in a future article I’m writing called “10 tips on creating empathy in your team.”
I don't recall, sadly!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.