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 (131)

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
 
forsh3y profile image
Charlie

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

Off-topic, but this sounds like an awesome team arrangement. How was your team formatted? Any tips on finding a place with teams built like that?

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.

Thread Thread
 
forsh3y profile image
Charlie

Good to know, thanks for the response!

Collapse
 
scotthannen profile image
Scott Hannen

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.

Thread Thread
 
forsh3y profile image
Charlie

Thanks so much for the detailed reply! I appreciate the advice greatly. I'm hoping to eventually move into consulting, speaking, and freelancing, so that's fine by me. I'd love to be the front-end half of the sandwich in a team like that.

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 on

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 on

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

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 on

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
 
washingtonsteven profile image
Steven Washington • Edited on

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
 
chpmrc profile image
Marco Chiappetta • Edited on

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
 
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
 
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
 
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
 
forsh3y profile image
Charlie

one part is a little less detail oriented.

Unfortunately, that almost always means the front end takes the fall. And with a 97% rate of failure for WCAG implementation, that's not a "little less detail".

Collapse
 
oenonono profile image
Junk • Edited on

Indeed, that matches my experience as an actual front end developer.

And most full stack developers I know are actually backend with a smattering of experience working with specific front end frameworks or UI libraries. Nowadays, of course, this type of developer often prefers tools like React, which lets them fool themselves that they're doing front end development in a more pure and highbrow way, like True Engineers.

It's not a bad tool: nothing is all bad or all good. The extent to which it's overrated, because it is, is driven by several factors including a naive reaction against pillars of the web platform, such as low barriers to entry for users, designers, and developers. Accessibility for all. Graceful degradation.

Historically, of course, client side development of web UIs WASN'T much like traditional software engineering. That was a strength as much as, admittedly, a weakness. I fear that we've gone too far in the other direction now, though.

Over the last several years, I've seen too much completely unnecessary complexity and smug exclusionary behavior. Too much sabotage of reach and user experience. Too much completely unwarranted abuse of potential mentors and peers. I suspect it won't be corrected anywhere near Silicon Valley.

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
 
stojakovic99 profile image
Nikola Stojaković • Edited on

I have pretty good knowledge of back-end development and somewhat lower knowledge of front-end development and I do both on my job because front-end dev colleague doesn't have experience with React. But as soon as there is design work, I pull back and let him to do the job because I suck at CSS (I only know some basics) and I have no idea about UI / UX. I called myself full-stack developer before, but seeing how far front-end development progressed I don't dare to do it anymore. Back-end development is what I'm most comfortable with and that's what I put primarily in my resume.

Collapse
 
imdesigntank profile image
Chris A. Raymond

Imagine you needed your home's electrical system rewired. Do you want to hire a handyman aka "full-stack tool user" or an electrician? The handyman can replace a light socket. The electrician can make sure your house doesn't set on fire because of bad wiring.

Similarly, look at what sports teams are: a collection of people who have complementary skills and specialties. Point guards and power forwards wouldn't swap positions. Catchers and pitchers wouldn't swap positions. Teams succeed when they are composed of people with complementary specialities. Sure, a pitcher can catch a throw to home. A point guard can rebound. Designers can understand code. Developers can (and should!) understand design principles.

I've been on interviews where the company uses Agile. When I've asked how the person you're hiring for would complement the skills of the current staff, and I'm met with blank stares, it tells me it's a company that hires using a laundry list of "skills" for every job, not one that thinks of building an effective team.

Collapse
 
designalchemy profile image
Luke

Urgh the I'm offended culture is now invading developers too 😓

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

There’s a difference between being offended and doing nothing versus getting out there and getting things done. The sole reason I started CubicleBuddha.com was to try to heal some major issues of teams that corporate America has forced onto developers. Am I offended at the meme? Absolutely not. It’s super funny. But I am offended at how the meme is used. I am offended at how misperceptions are proliferated by managers and architects that are sticking to the easiest architectural pattern from like 20 years ago: client server. And the sad fact is that the people who are continuing this pattern might not be doing it maliciously— they just might not know that there are alternative patterns. It’s our job to share with them alternative and potentially better ways.

Collapse
 
designalchemy profile image
Luke

Why are you offended ? If your a good dev you have nothing to feel insecure about, if your not, keep practicing, you have yet to earn your right to be offended

Thread Thread
 
cubiclebuddha profile image
Cubicle Buddha

Luke, my concern is for the teams that are unhealthy due to decisions that were out of their control. I am not personally offended, I am offended on behalf of those developers out there who are unhappy and that could be happy. Do me a favor and look up “self organizing teams.” You’ll find that what I am saying is a best practice that’s been recommended for many years.

Thread Thread
 
designalchemy profile image
Luke

What has this got to do with being offended over a meme about backend devs who are shit at front end ?

Thread Thread
 
cubiclebuddha profile image
Cubicle Buddha

That’s for you to figure out.

Collapse
 
weswedding profile image
Weston Wedding

Oh no what a shame.

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

19 Valuable Github Repositories for Beginners

19 Valuable GitHub Repositories for beginner devs looking to take the first step into the web development career.