[dominotw]

This is a bit too buzzwordy for me.

> Resounding Impact

> game-changing technology choices.

> aligning teams toward coherent architectural strategies.

> lead by example

> pioneer new spaces

> inspire others as to what’s possible.

> pragmatic problem solvers

> bring clarity to complexity

> illuminate pitfalls

> probe assumptions and foster shared understanding.

This perfectly illustrates why ppl dismiss software architects that they hide behind silly buzzwords without delivering anything tangible.

[digitalsushi]

It's corporate mythos. Something that worked for someone long long ago was so successful that it became the corporate form of a folk song.

When we down near the bottom hear "lead by example", it's facile to find the nearly useless obvious veneer to it, but if we could attach the original odyssey that led that engineer to tell their story ... we might agree with the lesson. But retellings upon retellings compress, simplify and gloss the original story into a cliche.

Each thing in this list sounds obvious, but if one can picture the opposite of the advice to be false, that reflection might actually lead an individual to growth.

[AnHonestComment]

That’s something Amazon does well:

Principal engineers are expected to give talks about their experience, which are heavily attended in person and widely shared.

It’s not perfect, but it’s less abstract when one or two concepts at a time, they explain why those truism through their personal experience.

“Earn Trust” is a truism — but being able to search for talks by the keyword “earn trust” where a high level engineer discusses different situations from their career and how they handled them is useful.

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

[nick_kline]

There was one key entry there, actually coding. Non-coding architects are rife with the possibility (but not certainty) of being too disconnected from the reality of the systems they are working on.

[shagie]

This reminds me of the discussions back on wiki.c2.com of https://wiki.c2.com/?ArchitectsDontCode and https://wiki.c2.com/?ArchitectsPlayGolf

There's also https://wiki.c2.com/?NonCodingArchitectsSuck for a rant.

[tomc1985]

I guess Principal Engineers are also really good at corporate bullshit speak