41–50 of 174 posts
I'll add another one, don't openly confront the CTO. Basic things what you should learn at your first job somehow get lost upon experienced software engineers.
Even when they have indefensible positions? When the idea doesn't hold up to ~2 hours of research?
21 years at Microsoft led me to have great disdain for "Software Architects". 5 years at Amazon led me to fall in love with the concept of a community of Principal Engineers. The Amazon Principle Engineering tenets are amazeballs. Exemplary Practitioner - Principal Engineers are hands-on and lead by example. We deliver artifacts that set the standard for engineering excellence, from designs to algorithms to implement…
I share your disdain for "Software Architects." I'm curious on your reasoning though. Can you expand on why you hold disdain for "Software Architects"?
Earlier quoted context omitted.
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 archi…
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, sim…
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.
Earlier quoted context omitted.
The console is a UX/UI issue, not a "architectural" one. Most "architects" nowadays are just mere users of what was built by the engineers and principal engineers of amazon.
Hard disagree. Thinking you can separate form from function is the evergreen mistake of our industry.
Usually there are "costs" to doing this and much engineering work is done to reduce this cost as much as possible. Either way, what you say is categorically wrong. Separating form and function is not a "mistake" given that it is so fundamental to the entire industry.
I'll add another one, don't openly confront the CTO. Basic things what you should learn at your first job somehow get lost upon experienced software engineers.
>I'll add another one, don't openly confront the CTO. Looks like we found the CTO :)
Maybe the problem with software architects is that they only exist in bureaucratically hellish companies, and exist as a scapegoat for bad management decisions?
Or maybe I'm just jaded.
Earlier quoted context omitted.
These seem like totally different roles. And the hours I've spent staring at the AWS console trying to figure whether I need "Elastic Beanball3" says to me that Amazon could use maybe just a little architecture. But I'm sure the Beanball Principal Engineer is quite proud of their resounding impact.
The console is a UX/UI issue, not a "architectural" one. Most "architects" nowadays are just mere users of what was built by the engineers and principal engineers of amazon.
I'll add another one, don't openly confront the CTO. Basic things what you should learn at your first job somehow get lost upon experienced software engineers.
Even when they have indefensible positions? When the idea doesn't hold up to ~2 hours of research?
You only need one maxim for software architecture work: “Implementation ruins architecture!” :P