Hacker News Reader

Comment by mettamage | Hacker News Reader

Solution: people become full-stack developers.

The story is interesting and gave a lot of value but the end result is underwhelming.

Any dev worth their salt can learn enough of a different discipline in the dev field. Or maybe I am biased because I was “raised language agnostic at uni”.

Wait, it’s not the result that’s underwhelming. It’s that it almost reads as an insult that people have the expectation that learning different dev disciplines might be impossible. I just can’t see what is impossible about a different discipline when you are already an experienced software engineer with a CS education.

If one came from a coding bootcamp, yea then I get it (I taught at one).

View on HN

A possible solution, perhaps, but i personally wouldn't consider it a good one.

I can full stack dev, i choose not to because i don't like the current state of the front end ecosystem but that's a preference not a limitation.

I can also do devops, standard sysops, data engineering/analytics to a degree and some other misc stuff.

I would absolutely not expect that to be a *requirement* to be a member of a functional team.

> Any dev worth their salt can learn enough of a different discipline in the dev field. Or maybe I am biased because I was “raised language agnostic at uni”.

Setting aside the true scottsman of that statement, the technical ability needed to learn other disciplines isn't always the limiting factor.

Not everyone has (or chooses to allocate) the time to keep on top of the multiple sets of ecosystems needed to keep up with all the disciplines, being language agnostic is one the least important parts of being effective in multiple dev disciplines.

but you are fullstack, it doesn't mean you work in all steps of the software lifecycle but you potentially could. That's the point.

That's a possibility for me, sure, but your original reply was basically:

"a solution is, everybody should be able to do everything, that way we don't have to do any actual skill based resource management because everyone is interchangeable"

with some vague allusion to "if they can't do everything then they probably aren't good at their job"

My reply was that i don't think that everyone being able to do everything is a good solution to what i think should be a skill resource management problem.

There are people who have the time, ability and resources to pick up (and more crucially , stay up to date with) all the disciplines, i don't think that should be a *requirement* and i don't think making it one is a good way of doing things in most circumstances.

It’s a flawed solution because it only works for this specific technology. It only works with full stack web developers because the breadth of the subject matter isn’t too wide.

Sometimes a team has to consist of people who have very different specialities that simply do not intersect and are too burdensome for all team members to gain proficiency in. There is often no budget to split the team or the team is already very small. This article doesn’t offer a solution to that problem.

Example: you’ve got an operations team of four people plus a manager. Most of the company runs on a containerized application using modern open source technologies, but then there’s an important legacy cash cow application that involves an Oracle stack running on Windows VMs. Are you really going to make your Kubernetes/Linux team members learn to operate the Oracle database and Windows servers that your specialists on the team manage? Will they even want to do that work without quitting and working somewhere else?

Oh I can do backend work, but I'll easily introduce performance issues, log too much or too little, get lost as soon as I open one of our observability dashboards, or design an inefficient database migration.

Likewise, I've seen more backend-focused people introduce horrible accessibility issues, completely misunderstand the client-side lifecycle, or produce a giant mess of intertwined global state.

It's useful to be able to wield all the tools to some extent, but I've found true full-stack to be a mess. (Where "true" already means "works on web APIs and in-browser code", i.e. still ignores large parts of the stack.)

There are plenty of projects where frontend/backend is a logical way to separate things, in which case it can be much more cost-effective to hire frontend specialists. Not only are they more familiar with all the specialized tools, but they can also do it with only bootcamp education.

I've been in teams with generalists only, and yeah we can all deal with UI, but it takes longer. No matter how good someone is, they can't have every detail fresh in their head all the time.

Or what about a full stack that's backend-backend, in a large corp with multiple internal services talking to each other? Only the higher-tier engineers have a good understanding of all the teams' moving pieces, even then not so deep.

By the time you acquire enough experience to do it in 25+ years of lunches the job market starts showing less interest in you. But that's the only promising strategy in the LLM-dominated world I guess.

Reply on news.ycombinator.com