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 dr...
For further actions, you may consider blocking this person and/or reporting abuse
You didn't explain why you take it personally. I was looking for the part where you say that you or one of your friends is a full stack developer, but didn't see it. In other words, if there is an offense, who is the offended party?
What I instantly saw is that someone knows how to draw an entire horse, but they're much better at drawing one part of it than at drawing the other.
I see it more as making fun of what happens when the industry invents a useless, meaningless label and then pressures developers to identify with it.
The most fun I had was on a team where I would develop everything from the backend database and services to the front-end rendering and JavaScript. Then, right at the point where it came time to apply CSS I'd hand it off to people who were really good at it. We'd collaborate a lot on the front end, tweaking the HTML and behavior.
Pushing more on the front end improved my skills. I didn't become a JavaScript rock star but I wrote good, maintainable code. But if I did the whole thing myself it would look like the front of that horse.
I don't think that "full stack" is much more ambiguous than "front" or "back".
Does anybody expect a "back end" developer to be a master of all things back end? Dos, Bash, distributed systems, SQL, C#, Java, C, Rust, Encryption, Networking, Cloud, REST, SOAP, performance, Graph databases, Timeseries databases, multi threaded concurrency, Hadoop,MEF,sharing memory, etc?
And what about solo developers? Stardew Valley (game) was written by one person, were they a front end or back end developer? Seems to me like they did a great job at both, so why refuse to call them by one of the best terms we have for them just because that term is flawed.
Can't we just agree that naming is hard, and let people call themselves whatever thing they think works the best for them?
For me, I define full stack as being able to throw sysadmin and DevOps skills into the mix. I can built components in React but you should not ask me to style them, I can write and integrate with APIs all day long, but I've always been the one who volunteers / is volunteered to maintain the build pipelines and handle deployments and I've picked up a lot more than I ever wanted to learn about DBA stuff from an incompetent coworker. I define a full stack dev as someone who can contribute to any area of the project, maybe not the most effective or fast work, but still contribute nonetheless.
And I bet your team loves that you pitch in! :) That’s awesome. :)
Love it, I'd much rather work with somebody that says "How can I help?" than "Not much job!".
That's so true and funny. If "front end" and "back end" actually meant anything specific then "full stack" wouldn't be ambiguous at all. It would just be front + back.
That's exactly the way that I understand this meme as well. I love working on frontend and backend myself, but the term "Full Stack Developer" is too often an excuse for a company to invest too little in people and then expect too much of those few "Full Stack Developers".
It's also about the reduced value of of "just" being a Frontend or "just" Backend developer. Yes most of us know both sides, but there's always one side that you're currently much more focused on.
Yup, you have a pretty great example of a high functioning team that shares and understands each team member’s strengths and weaknesses. I did mention it in the article, but I have worked on products where the front-end team was in a completely different team than the backend team. That’s the organizational disfunction that I’m trying to help eliminate.
One approach @charlie is to ask your job interviewers how they handle a sprint (or a release) where one of the specialists is out. If they answer with, “oh that’s not a problem, we all pinch in where we can” then you know that you’ve found a reasonably healthy team. If they struggle with the question, or if they say “well we just move the deadline” you might have to dig deeper.
Hey I'm the guy in that photo!
I imagine the full talk will be posted soon on Smashing Conferences YouTube channel, where anyone could watch for more context here.
Here's my follow up slide, which is more of a self-portrait really:
Thank you so much Chris for making me aware of where the slide was from. I gave you a follow, you can follow me back and DM me the link when it posts. I’ll update the article then with your link and the credit. :)
I think it's just a cheeky joke. The point it underlies is rooted in truth - that it's really difficult to master both frontend and backend development in real life.
Yea, I find it hilarious, but I try not to take it too seriously/literally. It especially amuses me because I'm currently in a "full stack" position, but am a much stronger front-end dev.
Haha yea. It’s best to take things lightly. I must admit that part of me couldn’t from all the times of being split into two teams. And as a generalist I’m always like, “okay... uh which team should I go on? Backend or Frontend?”
P.s. more power to you that you’re a strong UI dev. CSS is hard! :)
Yea, I did laugh pretty hard. But then my stomach turned a little bit, because I know that the belief is used to drive teams to be awkwardly structured.
I think the meme is perfect. In interviews anytime someone says they are a full stack developer I ask where their strengths are. If the tell me they are equally good at everything I assume that they aren't very good at any of it or at least dishonest. The tech stack is getting too big and complicated to be an expert at everything. Having the ability to learn is much more important than what you say you know.
Yea I totally agree with your points. I think I might steal that interview question of yours. Humility and self-awareness are really important in a career like ours that requires constantly reassessing what you think you know. In fact, many of my articles in the queue are all about accepting your weaknesses so you can learn. Thanks for the great thoughts. :)
What do you call each of these developers...
Sure, the term "full stack" is not accurate but what name is? Is "Software Engineer" or "Software Developer" any less ambiguous?
Those titles translate to:
I think titles are fairly worthless. I've gone from analyst to lead to programmer to engineer to consultant etc etc. What I do never really changes, I just try to learn stuff and use the best tools I can within the constraints I am given. You like to call yourself a full stack developer, if I asked you that question: "Where are your strengths"? Would you say you are equally good at everything? Or could you specify and say, "I am competent full stack dev with this specific tech stack". That is a completely honest and accurate statement. The only point I was making is that no one knows everything, whether just front or back. Everyone has their own slice of the technical pie, and that is OK. If you are a competent developer then you can effectively learn anything if you need to, that's what matters. Not what you know but what you can learn, which is why I feel being humble about what you do know is so critical. Most devs I have ever interacted with that sell themselves as full stack, are more just full of themselves. (to be clear that isn't an accusation)
"Those titles translate to:
Developer
Programmer
Engineer
Code Monkey"
I don't understand your reasoning here. What makes a back-end dev a "developer" vs a front-end dev a "programmer"? Were you being facetious?
That was satire, the next sentence was "I think titles are fairly worthless". I was trying to make a point titles are arbitrary and have less to do with what you do and more with who you do it for.
Ok :) thanks for clarifying
Yes, humility and a willingness to fail is what I’m always writing about. A+ response. :)
I really think there's isn't anything wrong being a generalist or a specialist throwing insults at some people's choice on the type of work they do is just pure lack of self-confidence.
I really wish that they could look at how special ops team are trained like the navy seals.
They each have their own specialised work but is cross-trained to the point that they are taking on the buck. When one of their's specialist is out of commission.
I went through similar military training as a military scout. That's why I'm totally fine with either being a generalist or specialist.
Since your aim is to deliver great software on time and within a budget that the user or people who pay it and continue to buy from the company or you.
I really love this response and your metaphor for military teams. Maybe the solution is to prioritize the needs of the user first and then to have a good conversation with all of the developers about which team structure supports those needs but that allows the team to be it’s happiest.
Yes totally :) It's the strength of a team that gels and blends well together to become an unstoppable force to achieve the objective be it to deliver software or make a difference in their contributions combined.
Hum... That's a tricky subject. While I aknowledge your points I guess it really depends on what your company is producing.
I completely agree if your company has tightly coupled backends and frontends (a web service per web site). In that case having a "full stack team" implementing the cultural points you gave makes complete sense.
That being said, I think that this tends to be less and less common. You can be in a situation where you have to develop/maintain a web service accessible by the end user throught both a website and a mobile app. In this situation I don't see how you could get an efficient "full stack team". The frontends technologies vary too much. I would probably go for three independant teams and some people acting as bridges to synchronize all the efforts.
As you might have guessed I have mostly been in this second situation. That's probably why, without any context, I don't understand this meme as criticism for the developers and rather see it as a criticism of companies/recruters who are only interested in "full stack developers" even when this requirement doesn't match their needs. Thus they end up with apps that are perfectly illustrated by this meme because the developers they hired, as "full stack" as they are, do not master the specific frontend technology they had to use. I'm probably wrong with this interpretation but that's definitely how this meme resonates with me.
Thank you for the thoughtful, measured response. I think the second case (the separate UI and API teams) works best in the case of a product that is heavily API focused, like traffic data, weather data, analytics etc. and those companies tend to monitize their APIs. But if your company is selling a tool as opposed an API, then I tend to favor the “full stack team” so the whole team can focus on getting value to the user instead of having conference calls about the value of “separation of concerns.” I see that all the time at the companies I’ve worked at and it’s a big sign that the team division is hurting not helping. When those teams have reorganized, the work is completed faster. And I don’t think the separation of concerns or the architecture suffers too much.
But I hadn’t thought about native mobile UIs like you mentioned. It is a real problem to source talent in Swift, Java, and JS/TS. So yea you’ve got me thinking now.
Maybe it works sometimes but not all the time?
I agree with you that it is critically important for a dev to understand the full stack. Separate front end and back end teams result in all sorts of communication issues and possibly an us vs them attitude.
That being said, the meme does have a point in that both front end and back end development are so complex that you really can't master both. Learning more about both can help, but the wide breadth of technologies involved make it so that there's barely enough time to really master one side. It also is just coincidental that most full stack devs I meet are better backend devs than front end devs.
Has anybody ever mastered either back or front programming though?
If so, then I would really love to meet the front-end coder who has mastered all of the things that the front-end entails - like UX, design, Data Visualizations and programming. Heck, I have yet to meet anybody who has mastered any of these skills.
If nobody is capable of mastering the front or back, then why care about whether or not someone calls themselves full stack?
I like the term "full stack", because it helps select for developers that either enjoy working in the middle, or have strong skills in areas on both sides. The wide world of programmers has tons of devs working independently or in small shops that have to operate on both sides, and I've known plenty of devs that can sling SQL just as well as JS.
If all terms are bad, why not just let devs call themselves whatever term they think fits best?
Depends on your definition of "mastered". Mine isn't where someone literally knows all there is to know. It's when they are confronted with a problem that they have not encountered before, but have a clear idea of how they want to solve it. I've done enough backend work to be able to make this claim for the vast majority of backend problems. I can't make the same claim for frontend work despite having done my fair share of it. Sure I can search for solutions, but it just takes me an order of magnitude longer than it would when I research solutions for backend problems.
All terms are bad in many ways, but there is a case for standardization. Standards are about making communication easier. Just like we have code standards to make it easier to read each other's code, we also have language standards. While I agree the term "backend developer" can mean all sorts of different things to different people, it would be nice to have terms we can use to summarize what we are capable of rather than listing them all out (e.g. knowing SQL syntax vs creating data models at scale). Then again, the range of technology is so diverse that maybe that just isn't possible.
Yea, I think it’s about finding that “middle path.”
It offends me too, mainly because I feel I have to fight silos wherever I go and I feel that the FE/BE split is another horrible silo.
No, I'm not the best FE dev or the best BE dev but, dammit, I'd rather every dev on my team pitched in with whatever needed doing that day rather than remain willfully ignorant of the rest of 'the stack'.
There's going to be days when I want my CSS expert be nailing their CSS thing. But there might also be days where I need to do that instead, or where the CSS ninja has to redeploy the application. Or read a Java stack trace to find out what's gone wrong...
Specialization is important, but at the end of the day the customer doesn't see FE/BE/DB/CSS/UX/UI/W/E...
They see a website that either works or it doesn't. And that's everyone's responsibility.
Cheers! I'm with you, the world is a big place and it takes all types of people to get along.
I'll keep calling myself a "full stack" or "software engineer" until I find a better name for me, and I'm not going to let anybody tell me that I've been a "myth", a "lie", a "scam", or "stuck" for the last 18-ish years.
Yes yes yes. I can’t agree more about your point about “fighting silos.” I think this all breaks down to two points (that I’ve learned through researching some upcomming “mindfulness at work” articles) where Buddhism teaches:
So if you put those together, you will try to structure the team in a way that highlights good communication and you’ll foster practices that encourages the team to collaborate. As you said, it’s all for the end goal of helping the user. Thank you so much for your comment. Please keep trying to fight silos. It’s tough work, but the customer thanks you. :)
It's a little tongue in cheek, but not insulting. Either way you get the whole horse, just one part is a little less detail oriented. It's the same idea as having "T shaped" knowledge. Wide and shallower, but also deeper in a part. That's a good shape to be.
Yup, it really is a funny meme. And thank you for reminding me of the “T shape” concept. Do you know who coined that? I’d love to cite that author in a future article I’m writing called “10 tips on creating empathy in your team.”
I don't recall, sadly!
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. :)
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. :)
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.
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...
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.
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.
Thank you for your response Matheus. I love your quote about self-acceptance:
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. :)
Full stack devs are still a myth! No, you cannot be proefficent on all fields and up-to-date at the same time. If you're knowledge is outdated you're not an expert of that field anymore, it doesn't matter if you were doing it for 10+ years. I don't take this meme that far (like splitting the horse to FE/BE).
Who cares if you’re an expert in the whole stack? As someone who has been the interviewer many times, I don’t look for expertise. I look for:
These are all great points to identify a great developer/person. None of them describes "Full Stack" developer.
Neither are those points a definition of a backend developer. The point I was trying to make is that the rationale behind creating a development team should involve more than simply separating people by their preferences. To me, this is like trying to compose a Dairy Queen blizzard by separating out the like parts. All you end up with is a cup on candy pieces and some vanilla ice cream when what I really wanted (as the end user) was a tasty combination.
To put this another way: When devs are separated into two teams (UI and backend), how have you seen it work out? Where do most of the bugs occur? Where do you see most of the work occur? Do you feel that it was an efficient use of everyone’s time?
The company where I work has been working like that for the last 15 years. Well, almost. There are teams having both backend and fe devs separately, but it's still one team. We have around 500 developers in multiple countries. We even have separate teams only dedicated for DB operations. BE devs usually not writing any SQL queries for example, they are using stored procedures.
Urgh the I'm offended culture is now invading developers too 😓
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.
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
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.
What has this got to do with being offended over a meme about backend devs who are shit at front end ?
That’s for you to figure out.
Oh no what a shame.
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 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.
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.
Sorry, but no. This is a hot-button topic for me. I've been in this industry full-time for a quarter CENTURY now, and yanno what? The more I learn, the more I realize how much I'm NOT a full-stack developer. Not for lack of knowledge, or inability... I know more about Photoshop and Sketch than many of the designers I know, more about Bash/Shell scripting than MANY of the DevOps guys I shoot pool with, and a whole helluvalot more about web development - front AND back - than the majority of the script kiddies I interview. Fact is? I'm STILL not "full-stack".
It's called "division of labor" and "separation of interests" for a REASON, folks. Rare indeed is the individual who gets off on database optimization AND color palette selection, or cryptography AND animation design.
The term "full-stack" was originally coined back in '99, around 3 years after I started developing. But upon hearing it, I tried. Gods how I tried. I've owned THREE different boutique dev shops. I've coded 80-hour weeks for longer than many of my current employees have been out of grade school. For FUN. I've written my own CMS, and SOLO'D my own CRM! Back in the 90's? Maybe. MAYBE there were a select few that were deep enough in when ASP and PHP (before JSP was even a glimmer in Sun's eye) first CAME OUT alongside the W3C's CSS1, Netscape's new-fangled "JavaScript", and that amazing Flashy stuff Macromedia had just bought from those "FutureWave" guys to punch up the new HTML3 spec microsoft was rolling for MSN 2.0, always assuming, of course you could afford a copy of that shiny new Photoshop 4 (not CC4. Not CS4. FOUR. 4.0) that was just then rolling out.
It's possible - not probable, but POSSIBLE - there were some folk that were good enough at all to have claimed "full-stack" (notwithstanding the SQL Server, Oracle, and IIS knowledge that would really have been needed then too), because the WEB WAS BUILT ON LIKE 8 TECHNOLOGIES! But now? HA!
I say this as someone who's been ACTIVELY working in JavaScript since the YEAR IT CAME OUT: I've been using this language for 8+ hours a day 6+ days a week for a QUARTER-CENTURY, and I'm STILL finding stuff I didn't know, very nearly weekly. And I'm not even TOUCHING on all the frameworks, libraries, coding styles, pre-compilers, post-compilers, de-compilers, browser-specific implementations (and I actually was one of the poor SOB's that HAD to dev for WebTV and WAP phones). And that's ONE LANGUAGE!
You show me one - ONE - legitimate "full-stack" developer, and I'll show you a reasonably-proficient bullshit-artist. When I interview people to hire nowadays? One of the first sentences I tell them is if I hear that term during the interview, or see it on their resume, better luck next time; I have no desire to hire someone who either knows jack-all about "every" layer of the dev cycle and release train or who knows a bit that's useful about several and then LIES about knowing the rest.
Specialize, folks. Find your niche and FILL that shit. Be the blogger that people turn to for integrating Couchbase and GraphQL, or the expert in using SVG animations in browser-based side-scrollers. I don't need a "universal" expert. Why? Because they don't EXIST. They're liars or suckers, or both, or worse, think I am.
I'd rather hire a dream team of 5 badasses who each rule their little kingdoms in their totality with an iron (but immanently EFFECTIVE) fist, than 5 code-bootcamp noobs who who delude themselves into believing that, because they can copy+paste from StackOverflow or npm install a 800k library with 98 dependencies (none of which they've bothered to read or understand) to solve some problem they only partially grasp (which ALREADY HAD a method NATIVE to the language available) that they are somehow "full stack."
Psssh.
"Really? You're a doctor? What kind?"
"ALL of them! I'm a FULL STACK physician"
Yeah. Have fun with that, while I'm over here with my proctologist, getting the burns from all the smoke you just tried to blow looked at.
"A lawyer!? Thank god! I'm in the middle of an IRS audit, stemming from my getting divorced from my wife without a prenup because I hit her just-yesterday-disbarred uncle-in-law's uninsured car while we'd both been drinking in the 49cc untitled Chinese scooter I'm borrowing from an out-of-town gun-collector, so he engaged in insider trading tactics to steal my company out from underneath me, then traded its pending patents to a North Korean firm for a kilogram of plutonium and a 55-gallon drum of methamphetamines, which, though they rendered him senile and demented now, it was NOT before he buried them in my back yard, where the neighbor's illegal immigrant gardener found them... by blowing himself (along with the cable company's box that straddles the sidewalk and my property line) up!
What do I do!?"
"S'cool. I GOT this."
Very interesting perspective. And I can see how coming from a world where there were so many technologies would lead you to that place. But now that there are stacks where you can just write JavaScript from the DB to the UI, it’s a little easier to make the claim that you are a generalist who specializes in JavaScript.
I would hope and encourage you to not immediately remove a candidate who says they’re “full stack” if what they really mean is that they like helping out where-ever they can.
I recognize that language is important and that I could have clarified that better in my article, however I think it’s important every team has at least one member of the team who is willing to help out where is needed. And it sounds like you have that “can do” attitude too.
In no way would I unfairly disqualify a candidate; indeed, as stated: I warn them right up front. Nor am I stating I have a problem with a can-do attitude. To whit: fully half my interview questions are logic and problem-solving puzzles in which I don't care if you get the "right" answer or not. The questions - many of which I've written or designed myself - are intended to see HOW a person thinks, not WHAT they do.
What will a candidate do when they don't know the answer, they're under pressure, and they weren't at all prepared for the issue? You tell me you need time, or need your tools to look something up? No problem. You tell me you don't know, or you "give up" or "pass"? Bye. I'll end the interview right there.
It's our JOB to PROBLEM-SOLVE. By whatever mechanism/means necessary.
I've personally been called in on Christmas Eve because someone on our QA team in Bangladesh (thank god) had noticed we abruptly were getting 5,000 uninstalls PER MINUTE (that's ~83 per SECOND) from our primary revenue generator. Took us 32 minutes to catch it, get to the office, diagnose, triage, and repair the problem, which in real-world terms, means we lost close to 160,000 users of our 9M (about 1.7%) that day.
I expect EVERYONE that works with and for me to have a "can-do" attitude. Quite aside from the fact that you'd not have survived my interview with a "can't do" attitude, it's a basic expectation. It's like a restaurant touting their food is "fresh" (Subway, I'm looking at you). If I'm at a restaurant, the very LEAST I should be able to expect is "fresh." It had BETTER be! If that's the only positive you can voice about your establishment (Subway), then you need to rethink your policy on rewarding mediocrity (still looking at you, Subway).
But this isn't about positivism or optimism. It's about spheres of influence and responsibility.
Look, I think it's a nice plus if a candidate has worked within our ecosystem (though for real: find me two companies with the same standards, best practices, deployment procedures, etc., etc.). But I'm not hiring you so you can be a graphic artist today and a Python developer tomorrow. That signifies I'M not doing MY job right (or, more probably, that I've delivered a set of reqs to someone in HR who doesn't know Java from Javascript, who in turn vocalized those to a recruiting firm, who then disseminated a memo to their headhunters, who are now trying to parrot back that we're looking for someone who drinks coffee and has pretty penmanship).
But in truth? I don't give a damn if you've used whatever bit of library esoterica du jour that one of my guys happened to have managed to successfully lobby for when this project started. I let candidates whiteboard code in their language of choice (including pseudo-code and flowcharts!). I had one guy respond in Brainfuck once (took me two weeks to figure out what the hell his answer was; I put interviews on hold until I had. I hired him, after threatening what would happen if he ever pulled a stunt like that again, rofl).
Fact is: there are back-end guys, and front-end guys. Artists and Algorithmists ("Algorithmechanics?" "Algorithmancers?" "Al Gore?"). It's not "old thinking". It's not "outdated principals". It's human nature. I too fancy myself to be one of those unicorns that straddles the divide, but if I'm honest with myself I have PREFERENCES. Build UI's or optimize Joins for a migration? Screw that; hire a database guy. I encourage my guys to expand and diversify, sure. In fact, we require it: 4 hours a week on Fridays (barring crises) you're required to code something non-work-related, then present it to the group for feedback and review. In whatever platform you want. Some of my favorite VSC and Chrome extensions came about thusly.
But when I'm losing 300,000 users an hour? I'm not calling in my jack-of-all-trades, master-of-none, so I can sit and wait for him to browse NPM or ask Reddit. I'm calling in my damn ninja, who I HIRED FOR HIS EXPERTISE. Yes, there are stacks. Yes, some even run end-to-end. But just because you can code a really slick proxy server in Node does NOT make you qualified to make an equally-slick library of GUI components that'll play nice with Opera and Edge! And it DOESN'T NEED TO.
If my Startup's budget is such that I can afford to hire ONE dev, such that I need to spend the next 18 months combing LinkedIn, Monster, and StackOverflow to FIND this $200k mythical demigod, then I'M doing it wrong. And AS a candidate, that should SCARE YOU. Because during those 18 months, I could have hired 2 $100k guys that are roaring badasses in either end of my stack and started generating enough revenue to patch the holes.
Figure out which portions of the field you LOVE. The ones you'd VOLUNTEER to work in. The ones you do for FUN. Market yourself as one of those guys and run circles around me in your interview. You'll be happier, I'll keep you 'til one of us dies, and we'll both enjoy the pride and money of putting out REAL software WE made, instead of another flashlight app.
This isn't theory. This isn't my opinion. This is real-world, practical advice from someone who's been in the trenches doing it their entire adult life, since Clinton was still in his first term. Cuz I PROMISE you: I'm way the hell more "full stack" than 99% of the guys out there. I just recognize the hubris of the idea and wouldn't be caught dead asserting it outside a discussion like this.
There's just too much to know. For ANYONE to.
To quote Kyle Simpson (author of the best-selling You Don't Know Javascript books) in his outstanding keynote at JSNation: "I don’t think anyone ever really knows JS, not completely anyway. I say this in all honesty and not to boast: I’ve forgotten more JS than most people ever learn ... I’m not a JS expert, and I definitely don’t think I deserve to be called a 'classic.'" John Resig has said much the same thing. So has Brendan Eich, for gods' sake, and he WROTE the (first version) of the damn language! Albeit, though: Douglas Crockford, when approached for comment, merely muttered, "more'n you, pussy!" then set his dogs on me.
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.
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.
Hey man, as a guy who laughed out loud about that slide in Chris' talk and also retweeted it, I am truly sorry that you took offense in this.
BUT: my experience is quite contrary to yours and I strongly disagree with your points being made.
"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."
Nope. From my experience all too often companies try to hire on-guy-does-it-all solution for most of their problems. The so-called Full-Stack-Dev. And this is a more serious problem than it might seem because it changes the whole industries' notion of what matters.
That's why we have tech-bros claiming that you should "only learn JS" because the other stuff "doesn't matter" and "CSS sucks anyway" totally invalidating Front-Enders that write performant and scalable Project-Architecture with dozens of years of experience hence to not knowing enough Javascript. Or React. Or Vue. Or Typescript (Who still writes JS anymoe duh?)...
That's why many companies hire backenders (or JS-ninjas) only, because they think that HTML/CSS are easy and everyone can do it. That's why Front-End jobs get paid less. This why Semantic structures in HTML tend to be ignored more and more making the web less accessible to many users that would need it. That's why co-workers of me are being made fun of for using PHP.
And this in the end is not what "building bridges" looks like - this is gatekeeping.
Also: "team morale through empathizing, domain knowledge transfer, better estimates since everyone has passing familiarity with each layer of the stack, people helping out..." isn't a matter of everyone doing the same stuff (to some degree) but a matter of respecting each others capabilities and different skillsets and eager communication don't you think?
We have worked at different companies. All of the companies I have worked for have been hiring exclusively backend or front-end. Before I get into sharing my responses to your response, I think it’s important to state that we come from different experiences and therefore it’s totally possible that both our opinions are valid. To put it another way, the truth is probably somewhere between your opinion and mine.
I like lots of different languages, and I always encourage a team to pick what works for them. So I can say that even though I am by-design a full stack developer, I’ve never purposely tried to invalidate another developer. In fact, every couple of years I purposely ask to join a different team in a different language so I can step in someone else’s shoes for a while. I’ve already told my manager that the next team I’d like to work on is the Kotlin/Swift team at my company that builds our mobile app.
You lost me there a little bit because most JS devs have familiarity with HTML and CSS right? And most people that have tried it know how challenging it is. So I always try to evangelize at my company how important and difficult the UI work actually is. But maybe I just have a lot of empathy for UI development because I’ve done it for so long. I think that was my major point: don’t try to speak on behalf of another group of people until you’ve tried their job. I spent half a decade being a backend developer, another half decade as a front-end developer, and now I do whatever the user needs. And along the way I do my best to fight for my peers.
Yea, I have no idea why that is. Maybe managers don’t have enough experience in UI development to be able to empathize with the craft of UI development. I don’t know, but it’s silly for me to guess why the salary difference exists. I personally hope it becomes equal to backend work (or that it works like it does at my current company where it’s just “Software Engineer” with no distinction so that developers can change as their interests change).
I hear you. I ran a 2 year long a11y seminar at my last company that was designed to show any and all developer who was interested in attending about the value of markup for accessibility.
I’m sorry that they’ve made fun of you. You shouldn’t have to deal with that.
I’m not familiar with the term gatekeeping, but I will refer you to the many other comments in this thread of other people who identify as “full stack” who are desperately seeking to be seen. My article was designed to shine a light on those who like being a generalist. Ultimately, I want people of all skills and interests to be welcome to bring their skills to the table to help the user. I’m sad that this wasn’t clear in the article. Do you have any advice on how I could have made that more apparent? I’ll make sure to improve it in future articles.
Yes. I absolutely 100% agree.
So I read the word empathy being thrown somewhere on the comments, so maybe I can share a bit of an "out of the stack reason why this meme actually makes a point that is not necessarily offensive".
I'm a "Fullstack Designer" or "Product Designer" (I do UI/UX and CSS/JS daily) and at my current company anyone who can open an IDE is titled Software Engineer (their reasoning for this is expressed in this discussion). So what consequences arise from this one size fits all approach for a design team? Instead of spending time designing, I had to spend hours/days talking with dozens of people to figure out who the people that actually care about the GUI were (I still have to nag all newcomers to see if they will be doing any frontend work).
Now I work with 5 different products in my company and I actually run our Design System complete with a CSS/JS framework (it's almost as big as Bootstrap). Not only I had to waste time hunting down my allies but I also keep getting stuck explaining basic HMTL/CSS all the time (which I love but one person alone cannot do everything).
Half of our full-stacker have expressed they would rather not touch frontend with a ten foot pole, yet they still count on recruitment as people that should be doing frontend, which has made it impossible for me to recruit a real developer to work with me.
Titles are really important if you have cross team collaboration but they are just that titles, you are not forbiddden from doing database work just because you are title frontend developer, neither the opposite. And making separate back front teams would only ever make sense from a org point of view, they should still collaborate as if they were a single team if that setup exists.
To end, I do not fool myself with empirical data but I have been working for a couple years now and I have only met 1/2 actual full stack developers, the usual is that they are good at backend and wrongly think frontend is easy.
Thank you for your response. :)
Yes that’s true, but sometimes companies put arbitrary gates between the different areas. I’ve seen pull requests denied (or delayed) simply because the PR was from someone on a different team.
I wish that was the case, but if you’re two different Scrum teams, then you have two different sprint goals and therefore the UI and the backend teams are disincentivized from helping the other team... because that would take time away from the individuals goals. Sounds terrible, but I’ve seen it happen on at least 4 teams. But when you combine the teams into one team with a common backlog, then they are insensitive to help each other get items into the “Done” column. Those are just my observations though. I would not be surprised if there are some teams that have been able to successfully bridge the two teams. But so far, it’s been 4 out of 4 occasions that the two teams were essentially completely independent. I believe this is Conway’s law (but don’t trust me on that).
I hint that the real issue at hand here is that companies and devs seem to have a misguided sense that their goal is to move stories across columns in a board, versus doing a product that humans will use.
Well first I thought horse is abstraction that you can't be good at both things so "full-stack" means you're going to show some real disadvantages of yours in one or both fields when projects get tough, which does not even have to be true. You could be great at both design and programming but I think there's really small number of people who actually do it good.
A quick intro in my current status and why I may be relevant. Worked with too much technologies and some jobs were back only some were full-stack. This is the first company where I think I might be best at backend because other folks don't care about architecture nor patterns nor anything and I don't think it's always necessary to do so but... When I talk to some old colleagues they know so much about backend development that I always feel like I'm dumb. Now I got into backend because we worked as a team of 4 on project and we split at the beaning on front and back teams. Main thing was that front, were guys did amazing job, left clients amazed so other colleague and I had to do whatever just to make the thing work fast and comply with front. Reason of success was that we collaborated all the time. Reason for me being on backend was that I suck at CSS and know too little about Angular. Next project frontend guys asked to stay split in terms of having front and back tasks separated because we got USED TO and warmed up with tools we used and thus it was faster and easier. And we COMMUNICATE A LOT to keep things going. I admire what these people do at front as it's too hard for me.
Now having experience from before, you make everyone full-stack, some mess up the back because they're not good at it and some even don't care about it but it's in their job description, and some mess up frontend because they hate it or think it's writing scripts, or it's works like backend.
Then I guess it's either my experience were full-stack means full-mess because people cannot organise well in those situations or it's only fit for certain projects were front is simple or back is just simple CRUD and team excels at one. Or maybe people have luck working in teams where there's actually great developers who know both ends reeeeeeeally good.
Just for the reference on how stuck I am and think devs should focuse on one thing here's a list of technologies that I can remember working with in _6 years in __11 companies so far: Java,Spring,Seam,Hibernate,Oracle 11g, C#,.NET Framework,.NET Core,EF,EF Core,SQL Server, ColdFusion, PHP,CodeIgniter,Laravel,Wordpress,MySQL,MariaDB NodeJS,express, MongoDB, Scala, AngularJs,Angular5/6/7,React and at least 20 testing frameworks and tools.
Believe me you should keep at one thing at least for 2 years before the switch to be good at something and to keep your mental health stable :D
Thank you for the interesting and detailed perspective. Yes, it’s much harder to be a full stack team when the technology is painfully diverse. Maybe I’m spoiled from doing NodeJS where it’s all javascript everywhere (well TypeScript actually because I work at a large enterprise (and also I think TypeScript is great)).
So yes, it clearly depends on the situation, the team makeup, and the willingness of each member. I’m happy that you’re focusing on conversation. :)
Of course NodeJS you can be there full stack. It's JS and TS but still it's only JS with addons :D. Toyota some time ago replaced robots with humans. Why? Because PEOPLE learn not robots(took this from Jim Coplien) and key to success is HUMAN resource. And to work on something we need to COMMUNICATE.
Please watch this to understand what's happening to people and why they step on others: youtube.com/watch?v=jobYTQTgeUE . It's about too much ego guys working around you and it's frustrating if you focuse on that. Or you could go well they have issues with themselfs God help them.
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.
Stacks are a career smell, I feel, and one of the leading problems in today's developer ecosystem.
We place too much emphasis on segregation between layers and the technology used to create them and ignore the person behind the work.
I don't feel full stack exists, for that reason. I feel developers exist and have roles to their strengths - nothing more.
I agree with the meme in that regard. People who call themselves "full stack" are missing the point - but people who believe these stacks even exist are far worse.
A "full stack" developer is one who is competent in many roles. We, as a culture, seem to have this notion though that technology skill sets are like a Final Fantasy job system with balances and point limits to what we can learn or do.
There's no balance in learning. There's not an arbitrary number of skill points you have to spend in each technology before you cannot learn more.
Thanks for sharing about your career. Besides sharing mindfulness tip, the other main reason I started CubickeBuddha.com was to learn more about other people’s careers. So that was fascinating. And it sounds like you’ve made it to a place in your career that you’re very comfortable regardless of the title. Congrats. And it’s great to meet another “full stack dev” even if that title is sort of misleading. P.s. I’m about to start with React too! :)
I consciously moved to specialise in an area but found it frustrating. No idea what the other guys were up to. There became an unnecessary hierarchy. It wasn't fun. Perhaps a cultural thing, but no one was open to changing the dynamic.
I moved back to full-stack at a different company and we were in it together. We all worked on different projects but could help each other out. We taught and learned from each other.
I then moved back to a specialised role, but one that requires very good knowledge of the whole stack and each part of it technically has a stack of it's own. It's been a good compromise for me.
I want to believe this so hard. I am technically “full stack” in this very sense, choosing to explore the backend as a means of greater appreciation and understanding, and to improve my own skillset.
However, developers (or rather, people) with that attitude have been sadly rare in my experience, both working with many, and also interviewing (hundreds) of “Full Stack” developers. There are diamonds, yes, but I have to sift through a LOT of cruft to find them.
I find more often than not the title comes with “ignorant arrogance”, not the humility and curiosity I hope for, and the meme feels painfully accurate to me. To clarify, most Full Stack developers I’ve interacted with were usually .NET Developers who know how to npm install Angular with Bootstrap and call themselves “Full Stack”. So the less detailed part of the horse is in essence a Backend developer choosing some automagical frontend framework just to get a project done.
And that’s not a bad thing — for prototypes, small projects and startups, maybe. But personally, I’m a UX advocate, so ignoring something like accessibility is lazy and unacceptable in a production application IMHO.
But when I have deeper conversations about the frontend, it often exposes how very little they understand and respect the responsibilities of a frontend developer, because they assume the role is simply HTML markup and “making it look nice” with CSS (funny how most FS devs I know despise or avoid CSS altogether, despite being one of the most important parts of FE Development).
Many conversations had an uncomfortable tone that suggest “That’s so easy — I can totally do your job”, yet they struggle when tasked with improving accessibility, or optimizing performance beyond minification, or explaining how a browser actually works.
Personally I’d like to do away with the term altogether, because the “stack” is becoming more and more ambiguous these days when you consider DevOps, Serverless, etc.
Thank you for sharing that perspective. I think you perfectly explained why empathy is important (regardless of the title).
Having done backend and UI about equally, I think they both have unique challenges. And like you said, if you don’t recognize or understand that CSS is hard or that state management in UI development is hard... then you probably won’t be a very compassionate coworker. So yes, I can imagine that it’s hard to scan for candidates that express that understanding or at least that desire to understand.
But hey, I think that the fact that you’re interviewing for those qualities will only help to build more empathetic teams. So thank you! :)
One additional anecdote I would like to share about the Full Stack title in general: I do worry that the title is not viable and potentially harmful to one’s career in the long run. I observed first-hand a Fortune 50 company attempt to make all their developers “full stack” with little to no success, but a TON of employee burnout, unrealistic expectations from stakeholders and managers, and a shameful amount of turnover. It’s too nebulous a term that many people have their own expectations of what it means, and then suddenly, your job description and responsibilities grow, without a clear foothold to negotiate appropriate compensation because “well, everyone is full-stack here.”
Better to specialize in one area, have a clearer career path for advancement, and a more sane work-life balance IMO! What’s the advancement path look like for a “Full Stack” developer? They risk being stuck at mid-level more so than those that specialize in an area.
Correction: It’s likely more lucrative and viable a career path for contractors who can negotiate their own rates more easily than a full-time employee could.
It’s a good counterpoint. Like it’s definitely something to consider. But this article isn’t about convincing a company about how it should run it’s business. It’s about giving developers freedom to become a generalist if that’s what they like (I know I do). Like seriously, if a company asks me to be only front-end or back-end, I refuse the position because I know that it won’t make me happy enough to stay motivated. But I understand that some developers have the opposite career goals. It takes all kinds of people, and a good company should understand that necessity to have diverse skill sets (specialist, generalist, etc). I’ve had to argue my value as a generalist many times, but once people observe what I add to a team, they start to get it: I’m someone who has enough range of knowledge that I can help bring a team together and ensure that a feature is delivered cohesively. Meanwhile, a generalist can also help remind the specialists on the team that each person’s job is hard and deserves appreciation (if they’ve forgotten).
Side note: full stack is much more possible when the whole stack is JS (ie NodeJS) backend. It’s a little unrealistic if it’s Ruby or Python on the backend and JS in the front end since they look so different. The context switching gets really tiresome (and I’ve experienced that first hand). That’s why I really admire the JS stack.
I agree with Scott's and Martin's thoughts. My first thought at seeing the graphic was "jack of all trades, master of none"; my second thought was of recruiters with outrageous requirements paired with lowball compensation.
That said, fewer walls, not less.
I agree totally with you. I'm a full stack, doing anything that is necessary to reach company goals. It really doesnt matter if I'm an specialist in x or y, if we can't have z done. It's better to have x,y and z done, and perhaps distribute tasks and learn as the need comes than define myself as an X developer and limit my growth in a tech that may become obsolete, or may not be used cause Y is not being developed fast enought because there' not enough people in there.
Being a Jack of All Trades gives my team more results than being an Ace of Spades. Of course there is space for Ace's, but frankly, there are many ways to achieve the same goals, and usually you can do more if you are open minded.
Yes, I think I’m a lot closer to you as a developer. I like that this thread about “the value of generalists” has opened my eyes to the red for all types on a team. But I think if the industry was more honest, they would say that generalists have long been considered an anti-pattern. I for one am happy to meet another fellow “jack of all trades.” :)
I've yet to see the company that can make a swap from full stack to front and back end teams successfully, through choice or necessity. I've seen it as a paradigm shift based on a companies perception that you can create a better production line for software, although changed no processes to support it creating a chicken or egg scenario. I've also seen it pushed by developers that did only want to work on a part of a system after being hired as full stack. In all instances I've seen either a lack of communication or communications breakdown.
For me the frustration is that a single full stack developer can create a fully functioning feature with very little to no assistance. Splitting the teams implies you need a minimum of 2 people to deliver a feature and you gain all the complexity of the communication and the shared understanding that is required.
I agree with what you say and with the meme. You say :
And for me the key to having a full stack team is to hire people with different strengths. I've seen many occurrences of teams failing because management would only hire the same profile for every single developer, and then act all surprised because their team of SQL engineers can't make a PWA, or their Angular gurus are crashing the database.
So yeah, I think the meme is a good way to describe most developers (whether they call themselves "full stack" or not), and an ideal team would have several of those developers with different parts of the horse fully drawn, so that when you superimpose them you have a beautiful horse.
Yup, absolutely. I can see that you’ve has similar experiences on teams that I have. Creating a team is clearly not a “one size fits all” type of situation. And I’m glad that there are people out there such as yourself who are able to see the grey areas. I think that’s the main reason I chose to speak up: I’m tired of managers saying, “let’s ask the backend developers” (and other silly distinctions like that). No, they should ask the whole team. The best solution to a user’s problems might be the one that stretches across the distributed system.
Actually, having started as full stack (including hardware, telephone and networking solutions), in hindsight I accept that while there are full stack developers, you could also call them "developers without specialization".
That doesn't mean they are not as good (some may be even better for their more diverse perspective), merely less specialized in their field than front or back end developers.
Thus, it depends on what the task is. In some cases, the specialization will be a real benefit, in others it could be helpful to develop the whole with both sides in one mind.
Especially smaller projects benefit from going full stack, whereas larger teams profit more from specialization.
There still remains the myth of the "full stack" developer, I agree with the more interdisciplinary teams because that has more upsides rather than a team with just one "rockstar" "know-it-all" dev. But seriously, someone is either very good in one field or the other, there's not both.
Yes, all of this is more gray than it is black/white.
What do you call a developer who is excellent at CSS HTML JavaScript Java C C++?”
Unicorn?
I think the main thing he is trying to point out is that the structured languages like Java and C# scale nicer and bigger than JavaScript. I'm not saying those languages are better, just that they scale bigger.
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.
It's a pretty silly meme easily countered by its own silly memes. "Backend dev: highly detailed drawn donkey rump" "Front-end dev: highly detailed horse head" Join the two together with some duct tape.
I'm a full stack developer and do not feel offended at all by the meme. I think it's rather accurate, specially for full stack developers with a stronger backend background. Personally, I'm a full stack with more frontend knowledge and I feel like the opposite of that drawing. I know I lack many backend skills that a full time backend engineer with the same amount of experience has. It's only natural. It'll take me another 8 years or so to truly be full stack on a specific stack.
Yes, only natural. I appreciate that acceptance/self-care aspects of your response. I’ll take any and all developers as long as they are willing to work well together. And sometimes collaboration requires each member accepting what they can contribute (and also mindful communicating their career aspirations). So it’s great that you have that understanding of yourself. Now we just need to spread that up the management chain! ;)
In the past most known webmaster.
Can you explain why you should not be bothered by this? Does this not touch you in any way?
For sure there are 100s of full stack developers positions on fullstackjob.com
I wasnt aware there was a full stack dev "meme" going on.
I would take 3 full stack devs over front-end, middleware and backend devs every day of the week and twice on Sunday.
Haha nice! Me too! :) Yea, some teams like generalists and some haven’t worked with one yet. ;)
I think it is generally hard for anyone to be good at everything. That is why have a team of people specialize in different areas makes for a stronger team.
Absolutely, but I think it’s important to recognize that some people want to be generalists. Myself included. :)
there is also an issue of business need/project needs also.
I think small projects, full stack developers is great.
For large projects, where it is just not possible for a single person to know every piece of code, (even if you are good at both backend and frontend), it is just more efficient each team member to have an area of focus.
Often times, with large teams, the teams is even further segmented by different micro services.
Yes, segmenting by domain context is a really wonderful choice and is (as you mention) the basis of microservice architecture. But separating the structure to be UI and Backend causes more harm than good in my opinion. It seems to be he opposite of domain driven design (DDD).
Ambiguous but fun. The benefit of full stack dev from my perception is developer can build their own app/product from a to z without need other help.
Yup, absolutely. Now that’s much easier in a stack like JS front and NodeJS Backend (which I love to use), but I think it could still work if you had similar but different languages. Like TypeScript front end, and C# backend. Or Kotlin in the UI and backend.
An important part of fully autonomous teams are that they start together. It sounds like you should bring that up during a team retrospective so you can transparently state that you want to incorporate CSS best practices at the beginning of the design phase.
Of course if that’s not working and you’ve ready had enough it’s time to ask some important questions:
4 signs your job is beyond repair
Cubicle Buddha ・ Jul 10 '19 ・ 5 min read
This site used to have interesting stuff. Now it's full of people complaining about every little thing.
Juan, if you don’t care how your team is structured, that’s cool. But programming is a team sport. If you don’t have a good mix of skills or if you don’t have healthy people on the team... then you’re not gonna produce any value for the customer. Personally, I find team organization to be pretty interesting since it can make life hell or it can make work an absolute joy.
But yes, I wish I hadn’t made such a “Buzzfeed-y” title. Live and learn, right? :)
Low code is turning everyone I to "developers" it's a good and bad thing.
Yea, I think it’s important to focus on the fact that everyone has different strengths and weakness. I think as long as the company has a blame-free culture, or if your team has good retrospective sessions (which I’ll be posting about soon), then each teammate can be honest about how much development they should be doing.
In my case, I need to do the entire horse with exquisite mastery.. I feel more like a full stack and dev ops.. (yeah I'm the only person doing something for our outdated softwares)
Wow that can be tough. I’ve definitely been there before where you’re keeping it all afloat. But maybe help is coming soon? If not, time to speak up? Side note: I have a few articles in the queue about speaking up to management about the needs of the team. Also there’s an article coming up on dealing with perfectionism. I’m not saying that you have either of those issues, but I know that the last time I was trapped in the “one-man wrecking crew” situation you describe, those were some of the problems I was working through. Either way, thanks for sharing and best of luck with riding the whole horse!
I thought this was so elegant, as you move from left to right you see a fully developed and clearly defined "horses arse". As well as the other comments made below....