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

91–100 of 174 posts

Re: Behaviours to avoid in a software architecture role

#91

Post by ClumsyPilot »

btilly wrote: post #81
zippergz wrote: post #71

Earlier quoted context omitted.

After many years at big tech companies, I am now working at my first that has "Architect" as a separate role. While many of my colleagues in that role are great people and very smart, after a few years of living with it, I strongly believe that it's an "org smell" and I will seek out companies without it in the future. It creates completely the wrong dynamic to have the hands-on engineers, no matter their seniority,…

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 postition they might tell you to take a hike.

The idea that a contrived 30 minute coding session tells you more about a candidate that studying code they've previously written or debugging together doesn't make awnce and is not supported by evidence

We don't ask surgeons: "since you can do heart surgery in 8 hours, surely you can reattach a toenail in 10 minutes during an interview"

Re: Behaviours to avoid in a software architecture role

#92

Post by [deleted] »

nitrogen wrote: post #85
dominotw wrote: post #39

Earlier quoted context omitted.

> 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? I…

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…

[deleted]

Re: Behaviours to avoid in a software architecture role

#93

Post by majormajor »

dominotw wrote: post #39
nitrogen wrote: post #37

Earlier quoted context omitted.

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…

> 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? I…

> Everyone understands that there are tradeoffs and "pitfalls" associated with any decision.

I haven't seen this to be true. Especially as companies get larger.

Sometimes it's because they really believe option A is better in every dimension than option B. (But often are mistaken.)

Sometimes it's because option A means their team has more work and can hire more people.

Sometimes it's because they understand their own ideas really well but aren't understanding other people's arguments.

Sometimes it's because they just don't respect the other people in the room.

But assuming that everyone is going to rationally jump initially to the thing that's best for the long-term health of the organization isn't something I've been able to count on.

Re: Behaviours to avoid in a software architecture role

#94

Post by btilly »

ClumsyPilot wrote: post #91
btilly wrote: post #81

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…

"make them write code in the interview... Because now they can't program" This comes across disrespectful and presumptious.

It is the interviewer's job to check the possible reasons to not hire someone and validate that the they aren't going to be problems. One of the possible reasons to not hire someone whose last job was "architect" is that they have lost contact with coding. If they have, then from experience I can tell you that they won't want to go back to coding, and their architectures are losing contact with reality. They are a liability.

This observation is not original to me. The first time that I saw it made explicit was when I took interviewing training while I was at Google. Google's experience is that a certain fraction of architects avoid coding. That fraction makes really bad hires. So they explicitly told people to look for that in the interview so that don't wind up accidentally hiring them.

But if someone's title is "architect" and they can code, then that isn't a concern. Companies do tend to promote good programmers to architect, and you don't want to miss out on those programmers.

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?

This is a straw man argument. I said nothing about "latest fad framework". The exercise is to write some code, not write code in any particular framework or language. Go ahead and be offended at something that I didn't say, but please remember that I didn't say it.

Secondly, the whole phrasing just conveys disrespect for cadidate, where the only responce to 'jump' is 'how high'.

If an interviewee objects to writing code in the interview, how are they going to respond when they're asked to write code on the job? Seriously, if they get offended in the way that you just did, that's a good reason not to hire.

If someone is interviewing for non-code postition they might tell you to take a hike.

I do not want to work in an organization where "architect" is a non-coding position. Seen that, left in horror. So if I'm interviewing you, you are almost certainly being hired for a coding position.

The idea that a contrived 30 minute coding session tells you more about a candidate that studying code they've previously written or debugging together is idiotic.

It doesn't tell you more, but it tells you something different. In particular it tells the difference between someone who shows their own code versus shows someone else's code and lies about the source. (Yes, I have seen that.)

Re: Behaviours to avoid in a software architecture role

#95

Post by xorcist »

btilly wrote: post #81
zippergz wrote: post #71

Earlier quoted context omitted.

After many years at big tech companies, I am now working at my first that has "Architect" as a separate role. While many of my colleagues in that role are great people and very smart, after a few years of living with it, I strongly believe that it's an "org smell" and I will seek out companies without it in the future. It creates completely the wrong dynamic to have the hands-on engineers, no matter their seniority,…

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…

> The transition from "programmer" to "architect"

Transition? If only it was at least that.

I've worked with architects whose job was the result of taking courses in software architectry at college and then they took a job as one. Apparently there are organizations looking for these people.

Re: Behaviours to avoid in a software architecture role

#96

Post by blub »

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…

Now I can't get the picture of Amazon employees in dark robes repeatedly reciting the tenets out of my head...

That being said, where's the proof that having PEs is better than having architects? If we look at results, I don't see any evidence that Amazon's creating better software than Microsoft on any quality axis.

Re: Behaviours to avoid in a software architecture role

#98

Post by abiogenesis »

hellohello1 wrote: post #50
bjornsing wrote: post #3

You only need one maxim for software architecture work: “Implementation ruins architecture!” :P

Hey that's my portfolio! 100 products written by 100 people in 100 different ways. 100 people left and I'm the one left trying to unfuck 100 products.

I don't think there was an architecture to speak of in the first place in your case.

Re: Behaviours to avoid in a software architecture role

#99

Post by ahupp »

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…

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?

Re: Behaviours to avoid in a software architecture role

#100

Post by neilv »

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…

That Amazon characterization of a Principal Engineer is great, and approximately how I've viewed the ideal role of the title.

Sometimes the title means being very highly skilled and experienced IC, or having deep historical knowledge of a particular system or organization, or being a niche technical expert. I like what Amazon's description adds to it expressly (which many have sometimes done unofficially), such as leading by example, engaging, and seeing humility as a quality of the role.

Post reply on HN