101–110 of 174 posts
Earlier quoted context omitted.
Even when they have indefensible positions? When the idea doesn't hold up to ~2 hours of research?
Especially then, because if that's the case then you know there's more to this story than just what you're experiencing in that moment.
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…
It's typical of engineering organisations to come up with this kind of list, the main reason being that as an industry we're uncomfortable with experience, seniority and progression. We're collectively suspicious of it. We want to codify and clarify it, endlessly. We demand the right to define it but when given the chance we always set the bar unrealistically high. To recognise someone as a Principal Engineer, they s…
In practice, no company requires their equivalent of principal engineer to hit 100.00% of the defined marks, but rather a comfortable majority of them with no glaring weaknesses.
Principal engineer roles should be filled on ability and impact not seniority/experience.
Earlier quoted context omitted.
It gets worse. The transition from "programmer" to "architect" results after a few years with the architect losing track of where the rubber meets the road. This results in worse architecture decisions that are made by a similarly experienced programmer. This effect is so strong that if you're interviewing someone who became an architect, make them write code in the interview. If they don't do it really well, you don…
I don’t buy this analysis. The principles of architecting code and system design are timeless. There are definitely people out there who don’t “code really well on command”, but can ask the right questions to design a solid system.
That I emphatically agree with. Some of my favorite programming books are decades old.
There are definitely people out there who don’t “code really well on command”, but can ask the right questions to design a solid system.
There are?
I can't say that I've ever met one.
The problem is that people don't know what they don't know. A non-programmer can know exactly the business problem to solve and exactly how they want to solve it. But they can't tell the difference between what is easy for a programmer and what is hard.
They don't have to learn a ton of programming to fill that bit in. But if they never fill it in, that limitation will keep them from being able to be a good software architect.
I think most of the advice in the article is actually reflecting this sentiment and in my organisation I am deliberately not creating roles that bear "architect" in the title. The software industry should move on from this term, I think.
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.
> trying to figure whether I need "Elastic Beanball3" Just wait until you have to try to figure out how much that's going to cost you...
Earlier quoted context omitted.
The disparity within AWS is the result of common inevitability that arises with managing technology built on over a decade of scaffolding. For sure there is a central planner within the company trying his best to put everything together into a cohesive whole. Technical debt is the most common name for this issue. An "Architect" can't solve this problem anymore than an "Engineer" can fix the problem of technical debt…
Technical debt isn't the root or even the most common cause of software components not playing nice with each other. In fact, this problem is probably more prevalent in greenfield over-engineered solutions than old legacy-ridden ones. (And really much of what we call "technical debt" is just the scaffolding we put together over the years to make stuff be compatible.)
Yup. In that context, it is usually called Second System Syndrome (when discussing the person that is laboring under it's influence while in the act of designing) or Second System Effect (when discussing the resulting system):
Earlier quoted context omitted.
It gets worse. The transition from "programmer" to "architect" results after a few years with the architect losing track of where the rubber meets the road. This results in worse architecture decisions that are made by a similarly experienced programmer. This effect is so strong that if you're interviewing someone who became an architect, make them write code in the interview. If they don't do it really well, you don…
"make them write code in the interview... Because now they can't program" This comes across disrespectful and presumptious. Firstly, do you believe that if you have not coded for 4-5 years you become useless just becauss you don't know the latest %fad% framework? Secondly, the whole phrasing just conveys disrespect for cadidate, where the only responce to 'jump' is 'how high'. If someone is interviewing for non-code…
Wasn’t that they got hung up on the details of whether the average of ints should be an int, float, or double, or how to handle overflow, but just couldn’t get started at all.
After that, I stopped shying away from wanting to see code from even senior technical candidates.
(It was not a standard question for senior roles; I got a strong whiff of “this guy might be entirely full of it; let’s have a look-see”.)
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 :)
> Looks like we found the CTO :),
Ooh, is this a game like "Spot the Fed" at DefCon?
Earlier quoted context omitted.
>My opening statement is short, so I'm assuming some charity in reading it. My complaint is the idea that you can make a hard distinction between function and pass that to another layer is a huge mistake in our industry. As noted by us conversing in a web browser. :) Ok, so you are basically implying that your opening statement is wrong and what you meant to say is that abstractions do not have zero costs and that th…
With my statement following the claim that UI/UX is not an architectural issue, I'm not sure how you are getting this reading. I maintain that separating the ui/ux from the architecture is a fools' errand. Any other reading of my statements, while almost certainly my fault, don't make sense here.
This statement is patently false, especially for UI/UX. Even at the lowest level there are platform agnostic API's (opengl) that are divorced from CPU/computer architecture. At even higher levels, javascript/css/html is a graphics API that is divorced from even the operating system. Separation of form and function is the foundation of software. It cannot be a "fools errand" when all of UI/UX is designed with the separation of form and function in mind.
It is therefore fundamentally impossible for you to stand by a notion that is completely false. More than likely your statement is just a mistake and you didn't think it through. Such is one of the downfalls of "Architects"... they are so concerned with high level truthisms that they fail to even build the correct high level picture of the computing world.
For software systems, the devil is, unfortunately, in the details.
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…
LEAD WITH EMPATHY
Principal Engineers shape an inclusive engineering culture where others are heard, feel respected, and are empowered. We are conscious of how our words and demeanor impact others, especially those with less influence; we take responsibility for that impact, intentional or otherwise. Our work builds productive relationships across teams and disciplines, and across a wide range of life experiences.