DEV Community

Cubicle Buddha
Cubicle Buddha

Posted on • Updated on • Originally published at cubiclebuddha.com

I’m sorry, but this “Full Stack” meme makes me really mad/sad

image of a horse’s ass that says full stack developer

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)

Collapse
 
scotthannen profile image
Scott Hannen

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.

Collapse
 
thejoezack profile image
Joe Zack

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?

Collapse
 
ssimontis profile image
Scott Simontis

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.

Thread Thread
 
cubiclebuddha profile image
Cubicle Buddha

And I bet your team loves that you pitch in! :) That’s awesome. :)

Thread Thread
 
thejoezack profile image
Joe Zack

Love it, I'd much rather work with somebody that says "How can I help?" than "Not much job!".

Collapse
 
scotthannen profile image
Scott Hannen

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.

Collapse
 
embiem profile image
Martin Beierling-Mutz

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.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

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.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

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.

Collapse
 
chriscoyier profile image
Chris Coyier

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:

well-drawn dragon on left, badly drawn dragon on right

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

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. :)

Collapse
 
therealparmesh profile image
Parmesh

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.

Collapse
 
hkly profile image
hkly

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.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

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! :)

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

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.

Collapse
 
shadrack1701 profile image
Matt Trachsel

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.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha • Edited

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. :)

Collapse
 
thejoezack profile image
Joe Zack

What do you call each of these developers...

  • One with 5 years of exclusively back-end experience?
  • One with 5 years of exclusively front-end experience?
  • One with 5 years of exclusively front-end and 5 years of exclusively back-end?
  • One with 10 years working exclusively with front-end JS and SQL?

Sure, the term "full stack" is not accurate but what name is? Is "Software Engineer" or "Software Developer" any less ambiguous?

Collapse
 
shadrack1701 profile image
Matt Trachsel

Those titles translate to:

  • Developer
  • Programmer
  • Engineer
  • Code Monkey

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)

Thread Thread
 
pringels profile image
Peter Ringelmann • Edited

"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?

Thread Thread
 
shadrack1701 profile image
Matt Trachsel

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.

Thread Thread
 
pringels profile image
Peter Ringelmann

Ok :) thanks for clarifying

 
cubiclebuddha profile image
Cubicle Buddha

Yes, humility and a willingness to fail is what I’m always writing about. A+ response. :)

Collapse
 
steelwolf180 profile image
Max Ong Zong Bao

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.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

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.

Collapse
 
steelwolf180 profile image
Max Ong Zong Bao • Edited

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.

Collapse
 
jcmarquet profile image
Jean-Christophe MARQUET

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.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

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?

Collapse
 
pbeekums profile image
Beekey Cheung

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.

Collapse
 
thejoezack profile image
Joe Zack

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?

Collapse
 
pbeekums profile image
Beekey Cheung

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.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

Yea, I think it’s about finding that “middle path.”

Collapse
 
gypsydave5 profile image
David Wickes

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.

Collapse
 
thejoezack profile image
Joe Zack • Edited

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.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

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:

  • we are all equals, and we’re all in this together
  • mindful communication is important

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. :)

Collapse
 
oenonono profile image
Junk

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.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

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.”

Collapse
 
oenonono profile image
Junk

I don't recall, sadly!

Collapse
 
revskill10 profile image
Truong Hoang Dung

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.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

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?

Collapse
 
pringels profile image
Peter Ringelmann

"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.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

Yes, I really like what you wrote. I think you clarified my (current) conclusion perfectly:

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.

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. :)

Collapse
 
chpmrc profile image
Marco Chiappetta • Edited

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. :)

Collapse
 
thejoezack profile image
Joe Zack

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?

Collapse
 
chpmrc profile image
Marco Chiappetta

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.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

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...

Collapse
 
washingtonsteven profile image
Steven Washington • Edited

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.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

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.

Collapse
 
matpk profile image
Matheus Adorni Dardenne

Jokes aside the meme seems accurate, though. I think people mistake "fullstack developer" with "perfect developer". For me, and I realize this definition might not be accurate at large, the concept of being fullstack means I can deliver a whole application on my own if needed be; can design it and it's database, develop it back and front, then deploy it. It must be working, not perfect, you don't need to be a master in any of those, but you must at least "talk the language" of each, that way you can be part of any team or even go solo, that's how I interpret the "full" in fullstack.

For me, whilst I know my way around Vue, Bootstrap and whatnot, I definitely am not a "web designer"; my apps are always functional and have a solid backend with optimized queries and indexed tables, but they always have that crude "bootstrapy" feel, and almost no images. No one has to be perfect at anything, less yet at everything.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

Thank you for your response Matheus. I love your quote about self-acceptance:

No one has to be perfect at anything, less yet at everything.

This is exactly the message I wanted to make when I started blogging. I have a couple of articles in the queue about this very important point. Thank you for highlighting it. :)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.