I’m sorry, but this “Full Stack” meme makes me mad/sad | Hacker News Reader

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

dev.to

42 pointsfagnerbrack45 comments

> What do you think? Has your company pushed too hard for split UI/Backend teams?

I haven’t see this personally, I’ve only seen the opposite, companies pushing for full-stack devs. And from what I’ve seen, people self-select frontend vs backend despite teams pushing and hoping for more full-stack activity from every person on the team.

Frontend and backend and ops are specialized activities, and those domains are only getting more specialized and more complicated over time. Writing an API and designing CSS almost couldn’t be more different, and they’re both full time problems.

When I started a company with a friend, we both wanted to be full-stack and we both tried multiple times, but we just automatically drifted to me on the UI and him on the bots. After a while, when I would try to write bot code I would screw it up despite good intentions, strong knowledge of the code, and unit-tests in place. I would forget important security or schema details, or not quite understand the way my partner’s code had changed structurally even when we talked about it for hours. He’d get tired of explaining it and just write the code. Same thing happened the other way when he’d dip his toes in the frontend. If two people who want to be full-stack and communicate non-stop can’t make full-stack happen, I’d guess it’s a hard problem.

At my company, the product team leads want full stack for the flexibility of having any dev pick up any story. But the devs gravitate to their preferred side. Personally, I tend to avoid the front end because I'm weary of learning yet another js paradigm there every year or two and because I'm just more passionate about the back end than the UI anyway.

This is also what I have seen. The push for "full stack" devs and teams came from product because they don't like to have to coordinate multiple people or teams in order to get a project done.

There's Pair Programming

"Full Stack", in my experience (which is anecdotal and just my own), means "We want Front-End but can't find enough people so we're going to hire you as 'Full Stack' and then give you all Front-End work, but you wouldn't accept the job if we told you that's what it was". In other words, "Full-stack" means "Bait-and-switch", when coming from an employer.

Not saying that you shouldn't want Front-End work; if you enjoy that, great, and I am happy to support you with that API in a timely fashion. Happy to work closely with the designer and/or Front-End dev to make sure you get what you need so that things look good on the front end. But, I prefer Back-end development, for the most part. When I take a job that's described as "back end" it usually will involve every once in a while doing a bit of js, html, or css, but not much, and it's understood that it is not what I am going to be doing most of the time.

Again, this may not be other people's experience, but it's mine.

This was my experience with the job I'm at now. I was hired as a "full stack" developer and when I got here I learned I was the only one on my team comfortable working on the back-end. The team is small and very much the opposite of the ideal scenario he talks about in the article (people have their specialties and are only willing to pick up work within those specialties). This has actually given me an opportunity to create a niche for myself where I am able to jump into just about any project at any point in the stack.

>When I take a job that's described as "back end" it usually will involve every once in a while doing a bit of js, html, or css, but not much, and it's understood that it is not what I am going to be doing most of the time.

Do you feel that 'reporting' (of the SSRS variety)falls under the backend umbrella?

Tough question. It's kind of like, does "data science" count as back-end, or a separate category? I tend to think both reporting and data science (which are at different parts of a spectrum of data-oriented roles) are different enough from other back-end jobs to deserve a separate designation.

In practice, I've also seen a similar "bait-and-switch" where people get told they'll do data science, and then get pressed into back-end development instead.

I think full-stack simply means the company wants the flexibility to hire someone that may work on either frontend or backend as need arises. With every specific company over the course of a few (<5) years that need will likely be just in one area (frontend or backend) as the systemic problem that creates the need is unlikely to be solved in such a short time span. In theory if you worked for them for 30 years I think there's a good chance you could be working on both backend and frontend but in practice 30 years is a long enough time that so many other things may be different to invalidate that (starting with your own skills and preferences).

> I think full-stack simply means the company wants the flexibility to hire someone that may work on either frontend or backend as need arises.

Or both. Up to 2x the work at 1x the salary. Win. Same for "devops".

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

That comment on the post sums it up perfectly, in my opinion.

Agreed. The JavaScript world is evolving at a crazy fast pace. Front end development has become inextricably linked to it. No-one writes Vanilla JS + CSS anymore.

It's unrealistic to think someone can be an expert an the front end stuff (changing by the month) and be an expert at the back-end stuff with its own completely separate set of skills and knowledge.

It's like asking for a back-end dev who's also a DevOps expert and can handle all 100+ AWS services. Hell, good DevOps folks can't handle that _without_ trying to become good back-end developers too.

True, however you may as well try to!

I remember seeing a snarky tweet saying something along the lines of "Try asking your full-stack developers which direction the stack grows on x86"

This was the kind of joke I was expecting, based on the title.

The idea of naming developers based on the tools they are currently using is akin to name an mechanical engineer a wrench guy or a carpenter a hammer guy.

Of course not everyone is a computer scientist but even then everyone who is worth their salary should be able to get up to speed with a new language or deployment scenario.

That being said, how many job postings do you know that explicitly mention "we work with XXX - do you think you want to, too?"

I would rather compare it to car mechanics. Even though every car has the same parts (engine, wheel). Every brand has their own specific way of putting things together. The general principle is the same, but one mechanic just perfectly knows the ins and outs of a specific brands diagnostics tools or the failure symptoms and solutions. Where for another brand he would have to consult a manual.

>name an mechanical engineer a wrench guy or a carpenter a hammer guy //

Isn't it more like "we need a Snap-on 12mm operator", or "a Picard hammer user".

We need candidates who have 3+ years of Picard hammers with WireWright nail systems (especially looking for WireWright 6d and 10d experience).

Please no open-source hammer-and-nails people.

What? Why? I just lovingly forged this hammer shaped thing and some crude nails for you! Surely they are as good as any off the shelf hammer and nails! In fact, 70% of this whole village was built with these little puppies!

The recruiter can't answer these questions; they were told by HR. The recruiter does not know that when HR asked the manager what tools the team had, the manager picked up the nearest hammer - it was a Picard - and then picked up two boxes of nails and said "these are the ones we use the most". HR helpfully copied over the information from the side of the box and then specified 3 years because the manager said that they wanted people who could be trusted with a hammer and nails already.

When all you have is an open source hammer every nail can be configured to be hit.

I actually think that this metaphor proves the opposite point you are trying to make. Mechanical engineers are definitely segregated based on the types of systems they work on, in much the same way that we would describe the "back-end" "front-end" split.

You don't hire a "mechanical engineer", unless they are truly a new grad. You hiring an HVAC Engineer (have friend with Mech. Eng. degrees who do this), or a drilling engineer (again have Mech. Eng. friends who do this), or an engineer to work on mechanical control systems for chemical plants, etc, etc and you won't find these engineers boldly saying "Yeah I spent 15 years working on HVAC systems but how hard can these avionic systems be?"

So yeah, we don't name mechanical engineers "wrench guys" or "hammer guys", but those fields definitely don't presume that there isn't an incredible depth of acquired knowledge and lore that one needs to be effective in them, and that can only be acquired through experience, and which is generally not transferable to other fields.

I think devs who think they can do everything are lying to themselves. Sure, I can do Java and understand the environment. Sure I can do React and there is nothing special about it. But I am better at C#/.NET/Angular, because I have been working with edge cases for the past x years.

To say I can lead a team in a Java environment would be a lie, because of all the minor details.

Just because you can do something in a language doesn't mean devs are truly universal and "it's all the same."

Can I write some function integration in C/Go/Powershell, etc? Sure, but when I do, I am not nearly as efficient as when I am using my daily languages/frameworks.

> I think devs who think they can do everything are lying to themselves.

I don't think I agree with this, but there's an underlying truth here.

Personally, I have at least dabbled in pretty much everything that I've come across. I do this intentionally for two reasons -- first, it makes me aware of what tools exist, so I can make better tooling decisions, and second, it gives me a little head start if it becomes desirable to actually achieve competency in one of them.

I'm minimally competent in a very large variety of things. I can accomplish pretty much anything with a tech if I'm minimally competent with it. It will just take me longer to do so.

I'm competent in a variety of things, and I'm expert in a handful of things.

An expert dev should be able to at least muddle through with pretty much any tech, where "muddle through" means that you can produce using that tech, but it will take you longer than with someone who is at least competent. But you can still do it, and recognizing that isn't lying to yourself.

I don't think we are in disagreement on "should be able to." The argument is that it's not an efficient use of time.

Yes, that was why my assertion was qualified. The part I disagree with is "I think devs who think they can do everything are lying to themselves."

I agree that devs can't do everything efficiently.

I think there might be some devs who can do everything, but given that nobody has ever been tested on everything how do they know - at best you know that you have never yet been unable to meet a challenge and considering some challenges you have had you can estimate how long it should take to complete similar ones.

Well, if we limit our discussions to Von Neumann machines anyway, the number of different kinds of problems are not actually unmanageably large. Once you've touched on each of them a few times, I think you can be confident that you can figure out pretty much any situation. The only question is work efficiency.

Different languages don't really matter, because once you've learned the major types of approaches languages take then everything else is (mostly) just a difference in syntax.

If we look at mathematical and algorithmic issues, all of those can be learned if needed. They don't affect the ability of a dev to do them, only how long it would take.

When I say a dev can do everything, I don't mean that everything is easy or fast for them. Just possible.

> Can I write some function integration in C/Go/Powershell, etc? Sure, but when I do, I am not nearly as efficient as when I am using my daily languages/frameworks.

Should you be so efficient though? At the end of the day the only thing that matters for most employers is that you get the job done and the product out of the door. If your general programming knowledge with other languages frameworks allows you to quickly asses a problem and write a fix you create value, even if it not the most idiomatic solution. Of course everyone should write the best code in the most efficient and idiomatic way possible. But we don't live in an ideal world. As long as you take responsibility and apply your general knowledge together with common sense and best practices. Just don't go cowboying around a codebase just because you think every language is the same.

> To say I can lead a team in a Java environment would be a lie, because of all the minor details.

Minor details shouldn't stop you from leading a team. If putting you in a slightly different context means you can't lead anymore, you probably weren't actually leading in your preferred context.

I wouldn't say it's a slightly different context. There is also a difference between being a "white glove" architect and a practical technical lead, who is expected to be able to help with the details.

I have me a bunch of "architects" who can "do everything", until you ask them to solve a practical problem.

It's absolutely a "slightly different context". You said yourself that it's "minor details". If you can successfully lead a C# project, you can successfully lead a Java project. Would there be ramp-up? Of course. But if your leadership consists primarily of esoteric .Net knowledge, you're not actually leading.

I don't think it's esoteric at all. A co-worker is leading a .NET project, his background is Java/Ruby. He comes to me for things like: What to use for dependency injection in .NET core, Unity or native? The answer used to be Unity, now it's native. What to use for unit testing NUnit, XUnit, why? Test project separate from main proj or not (ok, this one is an obvious "separate"). Then there are questions like whether to use Entity Framework, etc.

Can you read about these best practices? Sure, but knowing right off the bat (and why) is part of what makes you a lead dev imo.

Regurgitating things you can learn from Stack Overflow in 15 minutes does not constitute leadership. You could write all of that stuff in a Wiki and share it with your team and suddenly your “leadership” is a commodity. Now, sure, knowing this stuff is valuable, but it’s not leadership. At best it demonstrates tenure in the particular area.

Leadership is when your team members come to you to solve difficult technical tradeoffs. It’s when you are giving valuable unsolicited feedback because you see problems and want to help the team. Leadership is driving difficult changes that may not be popular but are necessary, and finding a way to sell those changes to the team. It’s taking on work that matters and postponing your own features because the success of the team matters more than the success of your particular project or area.

Leadership is about leading. Not about being able to answer basic questions that anyone with a few years of experience should be able to answer. If your “leadership” is only applicable to one narrow technology, you don’t have leadership. You just have familiarity.

Those are all fair points.

This is not just a meme. This is a mentality.

At my last job at a big company we had HipChat rooms for all kinds of user groups. The one for frontend devs had constant discussion about their job (in)security, and every couple of weeks someone posted an article complaining about the existence of "fullstack" engineers.

I wouldn't care if this ended at chats and picture, but it's these people who deliberately push for ever increasing fronted complexity to make sure they're not easily replaceable.

The sad reality is that IT industry is currently in a bubble. It is choke-full of overspecialized tool junkies with no transferable skills. Certain complexities you "have to know" to perform basic operations are often 100% artificial and shouldn't be there in the first place.

I never understood this concept at all. Is this a metaphor somehow, or do you literally think everyone is secretly conspiring to make life more complicated for themselves and their team because of job security? What about the fact that everyone changes jobs every 1 to 3 years anyway? The market for engineers is pretty hot these days, I don’t think most devs even want all that much job security, much less are willing to go to such extreme lengths for it.

Have you considered that problems you’re not working on may actually have more inherent complexity than you realize?

From my own experience, and also just based on Ockham’s razor, it seems much more likely that people are mostly giving an honest effort and trying to solve real problems. Sometimes they succeed and sometimes they fail to solve the problem, or fail to recognize the right problem to work on, but overall real things are certainly getting done in the software world — new products launch and companies provide real value and gain real customers.

Every "full stack" team I've ever been on almost immediately partitioned itself into "the frontend people" and "the backend people", with people only crossing sides if there was some kind of emergency fix needed and the "right person" wasn't available. From what I gather in talking to others, this is pretty typical. Full-stack development is mostly a myth that we all pretend to believe in.

Isn't that ability to cross to wherever you are needed actually what full-stack means?

I was hired as front-end and did angular and css but earned respect of my back-end devs by pestering them successfully about creating correct indexes on the tables involved in queries that were mysteriously slow to them.

The other front-end guy just switched to Java were team were short of back-end capacity.

I'm a Full-Stack developer at Google, which is fairly uncommon given the complexity of systems here.

The chief trait of a Full Stack developer, in my opinion, is often just growing into the needs of the team/moment. I've been weighted in different directions because that's where the product needed me; I'm currently the Front-End domain expert on my team.

Self-adulating thought leaders who throw shade at Full-Stack are themselves just really bad at using more than one language, let alone thinking about different parts of a large system.

(I'd also expect a Full-Stack developer to understand systems and resource provisioning/monitoring. Not just JS vs. Java.)

I'll admit - I'm that horse drawer.

The converse problem is a brilliant but un-coordinated team of front end and back end developers that make things that the other team has trouble interfacing with: the severed front half of a narwhal and the back end of of a dragon with thousands of JSON/XML ants going between the two distant mounds of meat.

A lot of comments here bemoan "Full Stack Engineers" as being Jacks of All Trades but Masters of None. But that misses the point. Don't forget that the full quote is:

“A jack of all trades is a master of none, but oftentimes better than a master of one.”

In a startup or smaller organisation an Engineer with a deep understanding of a single area (frontend, backend, devops etc) is far less valuable to the business than an Engineer with "T-shaped" skills (https://en.wikipedia.org/wiki/T-shaped_skills), a solid understanding of fundamental best practices and the ability to quickly understand new things as required.

This article nails it:

https://angel.co/blog/what-skeptics-get-wrong-about-full-sta...

> What do you think? Has your company pushed too hard for split UI/Backend teams?

One relevant (anti-)pattern I've seen too often: nominally full-stack teams who fail to value and take ownership of their UI component. In my examples, this happens when they "require" full-stack devs, but will give full rating to the "meme horse" developer (weak UI, strong backend) and completely de-rate the opposite developer: strong UI, weak backend.

That said, I agree with the author's preference for "full-stack team" where the entire team puts real value in the whole range of competencies rather than just pushing the full-stack need down onto every individual developer.

I think Mitch Hedberg described it best:

https://www.azquotes.com/picture-quotes/quote-when-you-re-in...

Reply on news.ycombinator.com