[nitrogen]

Can you think of more concrete language that applies equally to all organizations? If so please do share.

Sure, there are the Dilbert PHB-esque abuses of trendy lingo through mindless cargo culting. But the bigger and broader your goals, the more abstractly you have to describe them lest you end up writing a full-on textbook.

Having said that, I have to disagree that your examples are buzzwords. Buzzwords are usually contextless, like saying "synergistic impact" without any hint of what that means.

As just one example, "Probe assumptions" is not a buzzword. It has a clear meaning within the context of software engineering. For example it is often assumed by new grads starting a company that a startup just has to use Kubernetes and microservices. But that is an assumption that is worth probing. Horizontal scaling only becomes a bottleneck long after the millions of users point. Microservices are meant to help giant engineering teams isolate the things different teams work on, but in a startup with only one team you don't have that bureaucratic overhead in your org, so you probably don't need it in your code.

[dominotw]

> Microservices are meant to help giant engineering teams isolate the things different teams work on, but in a startup with only one team you don't have that bureaucratic overhead in your org, so you probably don't need it in your code.

We had these discussions many times on our team. Everyone understands that there are tradeoffs and "pitfalls" associated with any decision. Isn't this just normal rational thinking? Is your assumption that ppl that aren't principals don't consider pitfalls. Do non-principals employees really think that there are no pitfalls to using microservices.

[majormajor]

> Everyone understands that there are tradeoffs and "pitfalls" associated with any decision.

I haven't seen this to be true. Especially as companies get larger.

Sometimes it's because they really believe option A is better in every dimension than option B. (But often are mistaken.)

Sometimes it's because option A means their team has more work and can hire more people.

Sometimes it's because they understand their own ideas really well but aren't understanding other people's arguments.

Sometimes it's because they just don't respect the other people in the room.

But assuming that everyone is going to rationally jump initially to the thing that's best for the long-term health of the organization isn't something I've been able to count on.

[perlgeek]

I've seen many engineers reach for a microservice architecture by default.

Why? Because they read HN, reddit and lots of blog posts, and thought that's how you do things now if you start from scratch, no legacy architecture to consider.

Not everyone thinks this way, but it's a frighteningly common thing.

[nitrogen]

Is your assumption that ppl that aren't principals don't consider pitfalls.

No such assumption on my part. But it might be safe to assume that the better you are at questioning assumptions, avoiding pitfalls, and thinking of the big picture (think breadth-first vs depth-first traversal of the problem space), the more likely you are to advance to higher levels of responsibility.

Another example. Suppose you are adding a new field to your payment processing system. You have considered engineering pitfalls. How will that change affect other teams? What about other departments? Will Accounts Receivable suddenly have a 10x workload of invoices to chase because that field change wasn't considered in their workflow in all cases?

There's nothing magical about what senior vs staff vs principal vs whatever engineers do, it's the same skills amplified and applied to the benefit of many people across an org, rather than limited in scope and awareness to a single project.

[Person5478]

My experience is that people rationalize what they want. If they want microservices then you're going to get microservices.

It's not all nefarious, I think if many of them truly _UNDERSTOOD_ the difficulties of microservices it would give them pause (there's a difference between knowing and understanding), but they want what they want, they're optimistic, and they tend to back into the reasoning afterwards.

[dasil003]

That’s a junior mentality. There’s nothing more dangerous to a resource constrained startup than a highly talented engineer who thinks this way.