Behaviours to avoid in a software architecture role • Hacker News Board

Re: Behaviours to avoid in a software architecture role

#121

Post by zingar » Wed, Feb 03, 2021, 6:02 AM UTC

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…

The engineers you work with have to write code that does the equivalent of averaging a list of numbers, many times per day. If you can't (in any language) handle this then I question your ability to understand whether your choices make it easy or hard for the engineers to do their jobs.

Re: Behaviours to avoid in a software architecture role

#122

Post by tguvot » Wed, Feb 03, 2021, 6:05 AM UTC

Too wrote: post #120

tguvot wrote: post #117

Earlier quoted context omitted.

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.

in pseudo i can. or in python. avg(list) :)

anything more complex, not sure. i touched last time linked lists in 2001. never learned algorithms and in fact didn't even graduated from school. and guess what - everybody is okay with all of it. because this is not the value that I am expected to deliver to the company.

edit: when people are interviewed for system architect positions, algo/coding interviews are not part of the process. because it's not skill set that company is looking for.

Re: Behaviours to avoid in a software architecture role

#123

Post by tguvot » Wed, Feb 03, 2021, 6:11 AM UTC

zingar wrote: post #121

tguvot wrote: post #117

Earlier quoted context omitted.

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…

The engineers you work with have to write code that does the equivalent of averaging a list of numbers, many times per day. If you can't (in any language) handle this then I question your ability to understand whether your choices make it easy or hard for the engineers to do their jobs.

in some languages i will write the code. more complex algos not, because i don't know them. and never cared to know them. in reality engineers that i work with, write code that does whatever_library.avg(list_of_numbers). if i will see engineer that many times a day implements code that averages list of numbers I'll have a serious conversation with him about more efficient development practices

and maybe you are questioning my ability, but engineering teams that I work with - not. They come to me so i'll help them with problems that they have.

Re: Behaviours to avoid in a software architecture role

#124

Post by lmm » Wed, Feb 03, 2021, 7:30 AM UTC

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…

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

Are we wrong to? We've all had the experience of being held back by poor decisions from a senior person who simply didn't have the skill. I watched a 200-person company full of smart people single-handedly destroyed by a "software architect" who just made a lot of, frankly, stupid choices that all of the freshly-graduated engineers could see were stupid.

Frankly I've found the vast majority of "experienced engineers" aren't actually any better at their jobs than fresh grads. There should be very high, objective standards before we allow one person to overrule the rest of the organisation.

Re: Behaviours to avoid in a software architecture role

#125

Post by imafish » Wed, Feb 03, 2021, 7:52 AM UTC

pc86 wrote: post #111

bluefirebrand wrote: post #36

Earlier quoted context omitted.

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

3) The other party has a lot of stuff on his/her plate and does not get the luxury to spend hours of research/thought on architectural details.

Re: Behaviours to avoid in a software architecture role

#126

Post by mnsc » Wed, Feb 03, 2021, 7:58 AM UTC

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 sound like a symptom of having too many smart people with too many diverging architectural ideas at the same place. How do the mgmt get them to march in the same direction? Easy, find the top 1% and create a mythological narrative around them. Then when a smart engineer in a team have a solid architectural idea he/she can defer to the Unicorn Principal that will "advocate" another "approach" that "balances tradeoffs" with "competing interests".

Sort of like the much hated ivory tower software architect.

Re: Behaviours to avoid in a software architecture role

#127

Post by GoblinSlayer » Wed, Feb 03, 2021, 8:13 AM UTC

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…

Right, you just throw together angular, babel, webpack, bootstrap, typescript, spinners, redis, zeromq, recaptcha and nosql - and that's your blog's "architecture".

Re: Behaviours to avoid in a software architecture role

#128

Post by GoblinSlayer » Wed, Feb 03, 2021, 8:23 AM UTC

Geminidog wrote: post #21

sjburt wrote: post #13

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.

UI can only show stuff in different place, with different colors and fonts, but it won't solve the problem. Explaining architectural purpose of a tool is an architectural job, neither UI designer nor salesman can do it, especially salesman.

Re: Behaviours to avoid in a software architecture role

#129

Post by GoblinSlayer » Wed, Feb 03, 2021, 8:36 AM UTC

Geminidog wrote: post #69

perlgeek wrote: post #66

Earlier quoted context omitted.

I would argue that naming very high-level things (like your top-level services) is very much an architectural decision.

Agreed. Only Software Architects have the special ability of naming things. Engineers and managers don't have this special knowledge. When I went to Standford to get my PhD is Software Architecture I was required to take at least 2 semesters of classes on the theory of naming things in software. The biggest point the class made was proving mathematically how one should never name anything after a plant, Greek/Roman g…

Mathematics does calculations, not decisions.

Re: Behaviours to avoid in a software architecture role

#130

Post by [deleted] » Wed, Feb 03, 2021, 9:12 AM UTC

bob1029 wrote: post #84

arethuza wrote: post #4

Earlier quoted context omitted.

I once spent a long time trying to work through all of the complexities just for what "Customer" meant in one fairly large organisation. Pretty much all followed from one chap asking "if a customer consolidates it finance team from being at each of their 40 sites in one country to 1 shared service centre, do we lose 39 customers"?

Identifying bounded contexts is a critical part of organizing extremely complex systems. You might have a Customer model that supports all contexts of usage, but in a certain bounded context you could know that only certain things from that type are applicable. There are a lot of ways to model this explicitly, but sometimes just having a clear document that expresses what these contexts are and what is involved in ea…

[deleted]