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
Oldest comments (127)
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 think the meme is spot on. You can get the level of Full Stack Experience by having tons of years on your back having worked exclusively in the backend and the front end for example.
Anything less that that and you get half-baked solutions.
You raise an interesting point. Maybe the difference between a well architected solution and a half-baked solution isn’t necessarily team structure... it’s experience. As they say, experience is valuable and hard earned!
Yes, because you will have made all the mistakes that you can do but by that time you will learn the inner depths of each style. Unless of course you only learn one thing and apply it everywhere
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.
Yea, I think it’s about finding that “middle path.”
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.
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 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.
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! :)
I've seen this paired with a similar image of a dragon, but where the head and front legs are detailed, but the back legs are scraggly and sketchy.
I took this as more of a reminder that devs with "Full Stack" in their title may sway one way or another. The Job Listing says "Full Stack", and the applicant will do what they can to show they are competent on both ends (note that the front of the horse is horse-like, and not a chicken or something), but may prefer/is stronger in one or the other.
Why I take away from that is that that is okay! But to be knowledgeable of that when you build your team, know your team's preferences and do what you can to make sure they complement each other to make that beautiful horse-dragon chimera.
I love this message of empathy that you’re demonstrating. I’m not sure I could have said it better myself. Yes, it’s all about listening your team and concentrating on self-care.
Every time this is brought up, I share this blog I have read somewhere. If you have time, it's worth checking out.
This is how I feel as well so I decided to specialize on JavaScript.
m.habr.com/en/post/436596/
Great article. Interestingly enough, this didn’t hold true for me:
But that be because I do focus on NodeJs and TypeScript.
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.
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.
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.
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?
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.
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!".
It all stems from the ambiguity of the term(s) "Full stack". A full stack developer doesn't know the whole stack, knows enough to work on both sides with, sometimes very evident, limitations. It's perfect for small companies who need to build a relatively simple product, fast. There's a market for them the same way there's a market for specialized backend, frontend, DevOps, hardware engineers etc. Another problem is that often companies hire a full stack dev thinking they got a 2x1 bargain, leading to overwork, crazy deadlines and burnout (and to the myth of the 10x dev). It then becomes evident why some professionals might not be particularly fond of the term. :)
That’s really interesting insight about the 2 for 1 deal. I hadn’t thought of that type of scenario yet. See? This is why dev.to is such an amazing community— I get a chance to listen to people with different perspectives. Because now that you mention it, I have been asked many times to “own everything,” and that can get tiring. Which might explain why I have to work so hard to maintain work life balance: dev.to/cubiclebuddha/go-home-4-tec...
How do you feel about the term "Software Engineer"?
Does everybody need a specific title? "Front", "Back", "Embedded", "Game", etc..and if so, what do you call yourself if you've worked as a Game Developer for 5 years and in DevOps for 5 years?
Titles are for the 3 Rs: Recruiters, Raises and Relationships and are always only attributed to a position, not to an individual. It's silly to label someone, regardless of the context. It makes sense, instead, to label its current or past positions. To answer your question someone who did game dev for 5 years and devops for 5 years is "someone who did gamedev for 5 years and devops for 5 years". Easy :) The generic label of "software engineer" (which I personally use) is useful in the sense that it's not tied to a specific context but makes it clear that I'm not just a code monkey.
In general, the meme told a sad truth: the more breadth knowledge you know, the less specialized you get.
What does that mean ?
If you're specialized on frontend tech, just focus more on it. It's nearly impossible for a frontend specialist to become a SQL specialist. It's hard, super hard.
So, in my case, my team has "specialists", instead of Full stack devs.
The one who knows well SQL doesn't know anything about Frontend tech, or Backend tech.
The one who knows Frontend tech doesn't know anything about Backend tech.
The one who knows Backend tech doesn't know anything about Frontend tech.
I love that meme, it delivers the meaning in a visual, clean way.
Some teams really like working that way. But I’m curious, what does your team do when you have a big deadline and the frontend specialist is out sick. Does the backend specialist jump in? Or do you just miss the deadline?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.