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?
"Each person will always have their strengths and weaknesses, but together the team should be fully autonomous and productive"
Yeah totally :) agree 100%
One problem I extrapolate from the full-stack meme is when companies think they can hire an entire team of generalists and expect a quality product. "I did a course in Angular" does not mean that you're able to deliver a high quality user interface. There's enough nuance to both front-end and back-end to justify specialised career paths.
So yes a well balanced team where individual members understand each other's domains is always good. Assuming that everyone can and should be able to do everything is not.
Yes, I really like what you wrote. I think you clarified my (current) conclusion perfectly:
It’s really important that I remember to clarify that specialists are always important. You need at least one person on the team who can solve the really difficult problems, right? (Like fancy SQL queries, CORS, immutable data flow) But in my ideal world, those specialists aren’t hoarding the knowledge and are sharing with others so they can at least be familiar.
I guess the real deal is: Does your team have high communication? Sweet. You’re done. :)
That was a very rare case (in my experience) of effective self-organization. It was like that because we made it that way.
I asked, "Hey, instead of me formatting this whole thing with CSS and doing it wrong, and then you having to undo everything, what if I just output raw, unstyled HTML, and you added the CSS?"
Then I'd take a stab at adding class names to the HTML elements which he or she would use to add styles. Sometimes they would ask me to rearrange the elements a little or add different classes.
On the last project I worked on we even had more than the usual input into what the intent of the feature was and how it should behave. The result is that we rapidly developed one of the most useful features I'd worked on in years.
The rest of the time, both before and after, I was asking the same question. Where do we find these teams who do "real" agile and write unit tests and refactor stuff?
My best answer is that it's difficult. Look for companies whose primary purpose is to deliver software, as they're way better at it than companies who do other stuff and, by the way, they need some IT people to make stuff.
Also, try companies that provide consulting. It's not perfectly glamorous. You can still end up doing staff augmentation with the exact same aforementioned non-software companies. But they still know the difference, and they often organize their own teams. You're also more likely to move between clients, so something is less-than-ideal you're not there as long.
If you ever read Erik Dietrich's blog he'll recommend that everyone should become a self-employed consultant so that you have more control to choose the teams you work with, and if they're paying you to consult (vs. just write code) then you can actually influence them to work more effectively.
But my short answer is just that it's hard.
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.
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.
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. :)
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.
I just realized that full stack is not a myth. It's just with time you learn a lot of technologies. But full stack junior is probably is the picture above.
Yea, I think that makes a lot of sense.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.