Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Behaviours to avoid in a software architecture role

danielwatts.info

Post reply on HN
Print view View original

111–120 of 174 posts

Re: Behaviours to avoid in a software architecture role

#111

Post by pc86 »

bluefirebrand wrote: post #36
pc86 wrote: post #33

Earlier quoted context omitted.

Exactly. If you're arguing with your boss's boss's boss, who has worked at the company for five years and the industry for two decades, and you think you've unraveled their entire argument by reading a few blog posts, you're wrong approaching 100% of the time. Best case scenario is that you've missed something specific to your company, or industry, or the current technical implementation, or some obscure contract the…

Or possibly you're extremely in the right but they have an ego the size of the moon and they will punish you if you bruise it. Either way you lose.

Not to just reframe AnimalMuppet's point, but which of these two things is more likely?

1) Your couple hours of research has uncovered something blatantly obvious that was somehow missed by the other party.

2) Your couple hours of research hasn't shown you some edge case or something that is common knowledge once you've been in the field for 2+ decades.

I'm not saying #1 never happens, only that #2 is much more likely. It's a horses vs. zebras argument.

Re: Behaviours to avoid in a software architecture role

#112

Post by taeric »

Geminidog wrote: post #109
taeric wrote: post #79

Earlier quoted context omitted.

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.

The way I took it is that you said your original statement in a broader context along the lines of "in computer science form and function should never be separated." And you used that statement to apply it to UI/UX and architecture. 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 highe…

You still seem to be taking a very non charitable read. I aluded to the browser, specifically because of the hard split between content markup and stylistic markup that is of very arguable benefits.

It is alluring. And when it works, it feels magical. Yet I still prefer TeX over many of the document systems I have been subjected to use. Markdown being a strong modern contender that embraced the ascii art nature of plain text files. Throw in the modern resurgence of jsx and the hard won separation of scripting from content is not even fought anymore.

To the ui/ux point, directly, I'm not even sure what you are arguing. The APIs that you list are all notorious for being bad leaking abstractions. And is why people make products over them, introducing new forms and functions for a different set of users. Just look at how you shoe horn shaders into those low level APIs.

But again, in the context of this story, I meant that you can't separate out the ui/ux concerns of a product completely from who owns that product. So, for AWS, they own both service and console. If one is bad, it is almost certainly from lack of prioritization in the team that owns the whole product. Often behind the guise of "this is not the architecture's concerns, but the front end."

Jumping to another metaphor to try and say it differently. In a bike, you can separate the drive train from the steering, but it will be a largely perspective based separation. Such that the entire bike is ultimately part of the steering and the power distribution. Yes, this is a simplistic look at it, but no more so than thinking you can fully isolate one from the other.

(Now, I do have to confess that Tufte is finally really resonating with me. And I fully agree that much of this is as useful as so many platitudes. Ask me about front end versus back end, someday. :) )

Re: Behaviours to avoid in a software architecture role

#113

Post by lumost »

jayceedenton wrote: post #68
cek wrote: post #7

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…

Bear in mind, an Amazon Principal Engineer is intended to be a 1 in 100 engineers position. The pay is generally above 600k, with the max pay dependent on the position.

Re: Behaviours to avoid in a software architecture role

#114

Post by yjftsjthsd-h »

zmmmmm wrote: post #104

As with other commenters, I feel like Software Architecture is a bit of an anti-pattern. Software just isn't like buildings in the end. The analogues of space and physics of materials etc are not solid enough in the software world that you can have someone disconnected from the "builders" lay out the whole building and then hand over the designs to be "built". As with agile approaches etc., there is a need for a far…

> that you can have someone disconnected from the "builders" lay out the whole building and then hand over the designs to be "built"

Agreed that this isn't going to work. I wouldn't write off the whole notion of having architecture and architects, though; I've known a handful of architects who absolutely improved the systems they worked on, but they were deeply involved in the whole process and part of their job was precisely to alter the system as needed.

Re: Behaviours to avoid in a software architecture role

#115

Post by username90 »

ahupp wrote: post #99
jayceedenton wrote: post #68

Earlier quoted context omitted.

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…

I'm not familiar with Amazon, but the equivalent level at FB (according to levels.fyi) represents just 1% of engineering. So this isn't only "experience, seniority and progression", it represents something really unique. It's hard to look at a list like this and say "oh I know what to do now", but it is useful as a rubric; is this person meeting most of the criteria? Just a few?

Principal at Amazon is the first level above senior software engineer, so closer to staff than principal at Google/Facebook. It isn't a particularly uncommon level to reach at Facebook or Google.

Re: Behaviours to avoid in a software architecture role

#116

Post by [deleted] »

jayceedenton wrote: post #68
cek wrote: post #7

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…

[deleted]

Re: Behaviours to avoid in a software architecture role

#117

Post by tguvot »

sokoloff wrote: post #107
ClumsyPilot wrote: post #91

Earlier quoted context omitted.

"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…

I interviewed a very senior architect astronaut who literally couldn’t write code to compute the average of a list of numbers. 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 stan…

i am very senior architect astronaut. it will take me some effort to computer the average of a list of numbers in c/c++ as i didn't touch those languages in many years.

from the other side, while reviewing designs (not code) of various components I can spot locations where code handles sockets incorrectly or a couple of dozen of scenarios that system will fall apart under because engineers don't think that far.

value that I bring is not in averaging list of numbers. my value is 25 years of making mistakes, learning from them and knowing how to avoid them.

Re: Behaviours to avoid in a software architecture role

#118

Post by tguvot »

btilly wrote: post #103
humbleMouse wrote: post #82

Earlier quoted context omitted.

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.

The principles of architecting code and system design are timeless. 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…

It will be me. I am systems architect and last production code that I wrote was probably 10 years ago or so.

I am probably rather crappy programmer. I was crappy perl programmer, crappy php (starting with version 2), crappy in delphi, c, c++. Probably okay in Python, but mostly because Python allowed to concentrate on solving problem and not fighting the language.

Me been crappy was probably because I never really enjoyed to write code, as interesting part is figuring out solution to a problem. Rest is implementation details :) You can say if you want that I am simply too lazy to write code.

Me been crappy in writing code doesn't mean that i am bad in understanding code or understanding what is it to write code the easy way or the hard way.

In majority of cases when programmers come to me with design that will be easy for them to implement, turns out that they have a bunch of big problems that they missed, mostly due to lack of experience. Most of the time solutions that they come up with complicate things further and add even more problems.

And this is the point of time when I assist them to simplify whatever complex design they made to something much more simple and doable.

I saved many man/years of development time by showing programmers easy ways that they didn't know that they exists

Re: Behaviours to avoid in a software architecture role

#119

Post by tomc1985 »

dominotw wrote: post #26
cek wrote: post #7

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…

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…

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

Re: Behaviours to avoid in a software architecture role

#120

Post by Too »

tguvot wrote: post #117
sokoloff wrote: post #107

Earlier quoted context omitted.

I interviewed a very senior architect astronaut who literally couldn’t write code to compute the average of a list of numbers. 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 stan…

i am very senior architect astronaut. it will take me some effort to computer the average of a list of numbers in c/c++ as i didn't touch those languages in many years. from the other side, while reviewing designs (not code) of various components I can spot locations where code handles sockets incorrectly or a couple of dozen of scenarios that system will fall apart under because engineers don't think that far. value…

Algorithm interviews should always let the candidate choose language to avoid these bad excuses, or in worse case even fall back to pseudo-code. If you can't calculate the average of a list of numbers in pseudo, then you are out regardless of how many years of mistakes you are bringing to the table.
Post reply on HN