Hacker News Reader

Comment by Xenoamorphous | Hacker News Reader

I think the “full stack” trend is harmful.

Yes it sounds nice in theory but there’s so many things to learn both in front and back end parts that I’m yet to meet a true “full stack web dev” even if they all claim to be.

Yes a guy who’s done backend all his career can write some basic HTML and CSS and some JS. And some frontend guy can write a simple server side code that writes and reads from a datastore. But they’re not “full stack” in my eyes, there had to be some balance in terms of knowledge in both areas; 60-40 would be ok, but 90-10 is not.

When I joined the company I work for over a decade ago there were backend guys doing frontend; yes they delivered something but frontend quality was poor. Now it’s the opposite, frontend guys doing backend (and of course they don’t want to deal with SQL so NOSQL it is); same thing.

Nothing beats a frontend and a backend dev (or multiple) working in tandem, IMO.

View on HN

It's not remotely a "trend" though. Full-stack is how it has always been for many web developers since 1994. I almost have never been anything other than a full-stack developer, one way or another.

I did work at a dot com (well a dot co dot uk) back in the 90s where I had varying jobs, and arguably the most successful two I was the front end guy for (but these were successful because of who they were for, not the development; the back-end was a nightmare in one of these). We had to invent things.

Apart from that, I've always just done everything. And I'm good at it all. Slightly conservative or risk-averse after almost three decades, maybe. But still good, and still up to date and learning.

And I'm burned out and want to quit, or get away from the Web, or at least teach (which I've also done).

I don't think newer web developers necessarily understand the luxury of specialising in one part or another. A lot of us didn't get offered the choice.

(But then again, I'm shocked by how many newer developers lack basic competence that I think only comes from deeper understanding of the full stack. There are non-idempotent GET requests on this very website where I am typing.)

ETA: I think in a lot of small shops, developers still end up getting dragged across this divide through circumstance. The web does not really have a front-end/back-end divide, no matter how much recruitment managers, engineering team leads and tech bloggers would like it to have.

Like another commenter here, I've been full stack since my first working day, and to this day, 1.5 decades in the industry. I've always touched on infrastructure, on the database, on the server side and on the client side. Vertical implementations of features.

I can't begin to imagine life as just a ... database guy, or a backend guy or just a frontend guy. Perhaps it needs to be aligned in everyone's eyes that we cannot be as good at databases as one that spends most of his time doing databases. But there are pros and cons to our kind of knowledge.

I can argue pro and con SQL vs. NOSQL, to the limits of my ability, or argue for this frontend framework or that, or consider various languages or architectures for the backend, or discuss about how we'll deploy the production version of whatever it is that we're building, or how we'll do development side CI/CD and so on and so forth. What am I? I'm open to the idea that I'm a fraud, but I like to consider myself a full stack.

I was this person for the first ~17 years of my career. With the caveat that I was developing features on the bottom of the stack in C but would frequently implement features all the way up to a web interface running on an embedded device.

I'm in games now and I have a specific focus and I really, really enjoy it. Maybe it's my old brain, maybe it's because I have young kids now, I don't know, but I really like that I don't have to context switch so often now.

this is fine when you're a junior learning but it's asking to get shit dumped on you later on. I think it's a good idea to pick a lane later on in your career and settle into it.

I have been saying this for years. The opinion has become even firmer since moving into DB specialization – the horror show of schemata and queries that even dedicated backend teams dream up is unreal. I don’t even really blame them; relational databases are hard. Yes, anyone can install Postgres (or spin up a managed service) and get decent results for quite some time, but at scale you absolutely have to know what you’re doing. There is a reason that DBAs were a thing, and the SaaS industry is slowly realizing that they shouldn’t have abandoned that role.

> at scale you absolutely have to know what you’re doing

There's a lot of runway you hit that magic scale: https://news.ycombinator.com/item?id=39276069

Yes, but the runway is a good deal shorter if you’re doing things as most dev teams without RDBMS knowledge do. The biggest three issues unfortunately build on each other:

Using JSON when you really should be properly normalizing your schema (or using a DB better suited for JSON).

Using UUIDs – especially UUIDv4 – for any indexed columns, especially as PKs.

Using Postgres for no actual reason other than it’s popular.

MySQL / InnoDB is a clustering index RDBMS, which can have massive performance improvements over others IFF you build your schema around it. If you use anything non-k-sortable (e.g. UUIDv4) as your PK, it suffers massive performance degradation instead. So you use Postgres instead, and think you’re immune. Wrong – its MVCC implementation means you’ll have approximately 7x read amplification for Visibility Map lookups under the same circumstances, and huge amounts of WAL bloat, which can also lead to increased network latency.

JSON[B] in Postgres is frequently TOASTed due to its size. The overhead from TOAST/DETOAST isn’t small, and you also have to deal with difficulties indexing the column, and you can’t as of yet do a partial update to a JSON column. MySQL can do partial updates, doesn’t have TOAST, and has better (still annoying) strategies for extracting scalars from them to be indexed as a quasi-sidecar lookup, but it lacks GIN/GiST index types.

I’ve personally ran a single MySQL instance with over 100K QPS, and it had the plenty of runway, and a ton of vertical scaling left. This was with very careful tuning, and a suboptimal schema. I’m sure it could go far higher if everything was done correctly from the start.

Fullstack is not much of a trend. The word has been around for awhile but when you go look at the job market you can see that the industry doesn't buy these terms very much, and that they also price that way too. A fullstack salary might only eventually catch up to frontend or backend.

Also, backend is a far more ambiguous term than frontend. With frontend I'd almost want to ask if the next thing you're going to say is React. On the backend? No idea. Do you deal with distributed synchronization as your only specialty? Do you do billion-per-second event logging, warehousing, and querying? Do you write Kafka glue all day?

So when people say fullstack they really mean app making, and however much frontend, backend, or even janitorial work is required to make an app exist.

The frontend is just an eventually consistent node in a distributed system. Fullstack means you have a basic understanding of how the entire system works which is invaluable.

At the risk of sticking my head above the parapet, I've made a career doing both to a pretty high standard. Not just that also server admin, DBA, desktop app development and a pile more skills I've picked up from a quarter century doing this stuff. When you're not working for big companies, you have to fill the gaps.

Sorry you feel the people you've worked with are so inadequate, but these are muscles you need to exercise. If they have no opportunities to learn at work, of course they're not punching at the same weight. But there are plenty of us that do.

I don't often announce myself as a full stack dev though. Maybe that's the difference between me and your experience.

> Sorry you feel the people you've worked with are so inadequate, but these are muscles you need to exercise.

I'm as surprised by this as you are.

Perhaps we actually are unusual.

I disagree completely, the best are teams who are good at both. Separate teams of front and back are significantly slower and always seem to be at odds with each other. Teams should be empowered to build out a working feature without needing to coordinate with a second team's roadmap.

> I think the “full stack” trend is harmful.

Please tell us why you think it's harmful. I don't see the harm in "too much to learn." That just sounds like software work to me.

When people specialize, the different specialties need to show their value, so they find greater complexity in their niche. The different specialties eventually independently "discover" many of the same concepts but explain them differently and their languages even diverge. I think losing the ability to share is a kind of harm.

Reply on news.ycombinator.com