4 ms·

This is a bit too buzzwordy for me. > Resounding Impact > game-changing technology choices. > aligning teams toward coherent architectural strategies. > le

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.

shagie 6y ago
This reminds me of the discussions back on wiki.c2.com of https://wiki.c2.com/?ArchitectsDontCode https://wiki.c2.com/?ArchitectsDontCode and https://wiki.c2.com/?ArchitectsPlayGolf https://wiki.c2.com/?ArchitectsPlayGolf There's also https://wiki.c2.com/?NonCodingArchitectsSuck https://wiki.c2.com/?NonCodingArchitectsSuck for a rant.
nitrogen 6y ago
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 6y ago
  > 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.
  - Person5478 6y ago
    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 6y ago
      That’s a junior mentality. There’s nothing more dangerous to a resource constrained startup than a highly talented engineer who thinks this way.
  - perlgeek 6y ago
    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 6y ago
    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.
digitalsushi 6y ago
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 6y ago
  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.
nick_kline 6y ago
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.
tomc1985 6y ago
I guess Principal Engineers are also really good at corporate bullshit speak

shagie 6y ago

This reminds me of the discussions back on wiki.c2.com of https://wiki.c2.com/?ArchitectsDontCode https://wiki.c2.com/?ArchitectsDontCode and https://wiki.c2.com/?ArchitectsPlayGolf https://wiki.c2.com/?ArchitectsPlayGolf There's also https://wiki.c2.com/?NonCodingArchitectsSuck https://wiki.c2.com/?NonCodingArchitectsSuck for a rant.

nitrogen 6y ago

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 6y ago
> 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.
- Person5478 6y ago
  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 6y ago
    That’s a junior mentality. There’s nothing more dangerous to a resource constrained startup than a highly talented engineer who thinks this way.
- perlgeek 6y ago
  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 6y ago
  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.

digitalsushi 6y ago

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 6y ago
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.

nick_kline 6y ago

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.

tomc1985 6y ago

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