I Don’t Believe in Full-Stack Engineering

Full-stack cannot truly exist because of the clash of cultures. Front-end values that which is shiny and new, the latest framework in the latest browser, code 6 months old is already obsolete, code 2 years old has to be rewritten entirely because all of its dependencies are broken now. Experience is not valued because no-one has any in the current trendy tool, it's too new. Whereas back-end values that which is mature and stable, code that is 10 or 20 years old is considered to be proven and reliable, experience is highly prized because it shows its value in day-to-day work. When the cultures crossover you get horrific things like node.js or MongoDB.

That doesn't mean there aren't front-end people who can write a bit of SQL or back-end people who can throw together a simple website. That's fine, those are basic commodity skills now. But everyone has to choose the culture they are comfortable with and that will dictate where they fall on the technology spectrum too.

The initial assumption is wrong: Full-Stack engineers are not expected to traverse the whole stack with senior level skills and ease.

Also if you become really good at something you'll realize that actually it is not all about more skills. There's a point where strategic decision making overcomes coding skills.

E.g. 1: I spent years to really learn vim and git indepth. I can write my own git clone and did that before as well. However I have seen so many different editors and IDEs that I'm at a point where I can take whatever is there. I use nano with ease if the situation requries it. This makes me quicker than installing my favorite editor, my configs and then start working.

E.g. 2: The more experience one gains the more one sees that the biggest drag on progress is usually misunderstanding, lack of info, lack of responsibility. So nowadays I do more for my team by creating meeting requests with the right people. For that I need to be able to read all of the source code and docs to figure out where the actual problem is and who really has the expertise to solve issues there. But I don't need to be as good as the topic expert.

> I'm saying that 99.9% of Oracle customers would have been significantly better off from a cost, flexibility, and support perspective going with an alternative like Postgres when they started.

Although I agree that some huge proportion [1] of businesses today would do very well to seriously consider Postgres as the first option before even looking at Oracle, I don't recall this being true 17 [2] or even 10 years ago.

Remember, we're likely talking about non-tech businesses here, ones where they're sustaining operations with a single developer. You mention "ill-informed technology leaders" but it's hard to imagine there are any technology leaders actually involved on the buyer's side.

I don't think it's helpful to look back at such a decision through the lens of today's technologies and the kind of talent/expertise that is, today, available to a business whose core competency is tech.

I'm no fan of "enterprise" anything, so don't mistake my critique as cheerleading Oracle. I just feel the context of technology decisions is paramount. It also seems especially germane to the overall thread topic, which is whether a generalist can possibly have enough depth in key areas to be considered competent enough in them.

[1] your repeatedly asserted claim of 99.9% is extraordinary, requiring extraordinary evidence.

[2] Oracle 9i was released in 2001. EnterpriseDB wasn't founded until 2004.

I apologise, it was 1am and I miscommunicated, I listed a subset with a very front-end heavy bias. I transitioned from back-end roles to front-end in the second half of my career. I also do (have done):

* Recommendation engines (less relevant now a lot of it is easily achievable with tools like Spark)

* Data processing pipelines

* Search indexing, optimisation, and relevancy tuning for millions of products

* Actual database model definition and business logic (possibly where the confusion was, i kinda meant to say everything between database and request/response layer, when all I really said was data modelling).

* Weird stuff like integrate Django’s model layer seamlessly with RPC frameworks. Essentially you could define “foreign keys” that worked across service boundaries and they’d work transparently and decently optimised.

* Systems architecture. Defining service and communication boundaries, message queues, pub/sub etc.

There’s probably a bit more I’ve forgotten about. Does this address the imbalance a bit?

My point is that if you define full-stack as merely having the skillset to do these things at an intermediate/senior level, then there are plenty of people who fit the bill. The issue is time management, I don’t think it should be someone’s job to do all these things, quality will suffer regardless of ability.

Also sorry did anyone see the bio of this guy? he is not even related to engineering unless he lies in his bio:

"I’m Robin, a web designer, writer and typographer living in San Francisco."