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

131–140 of 174 posts

Re: Behaviours to avoid in a software architecture role

#131

Post by rswail »

I'm an old fart that is a programmer that now has a fancy "architect" title.

I think I can distill that 30 years into the following:

1. Nouns are more important then Verbs. (that's what DDD is about)

2. Everything is events (if your Nouns aren't doing anything, there's nothing to be done. When they do something, that's an event).

3. A Noun's state is the sum of all the events that occurred and the way the Noun responded to them.

All the rest, microservices, network partitions, RDBMS vs NoSQL, containers, etc etc is irrelevant to the business. If you don't get those 3 points right, then you don't deliver the business value and you've failed.

Architects are about translating the business into those Nouns and Verbs and explaining them back to the business and to the developers that are building the automated bit of that business.

Re: Behaviours to avoid in a software architecture role

#132

Post by btilly »

tguvot wrote: post #118
btilly wrote: post #103

Earlier quoted context omitted.

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

Your self-assessment matches the self-assessment of other systems architects that I've seen. Suffice to say that my assessment was so different that I never again want to work at a company who have people who think that is their job. And I've seen a wide variety of programmers from a wide variety of companies agree. As a random example look up the thread for someone who had decades of bad experience with architects at Microsoft who is massively happier at Amazon (which actively avoids the architect title and mindset).

Of course I've never met you, and you may be better than the bad examples that I'm aware of directly and indirectly. But a priori I have no reason to expect your self-assessment to be more reliable than past experience.

Re: Behaviours to avoid in a software architecture role

#133

Post by redis_mlc »

lmm wrote: post #124
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…

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

> Frankly I've found the vast majority of "experienced engineers" aren't actually any better at their jobs than fresh grads.

Then you don't know what you're looking at.

It's true that there's title inflation in software these days, but if you talk to any software engineer with 20+ years of experience, you will notice the difference.

The hallmark of a junior engineer is deploying Java applications to production in 4 GB VMs. Seen this all over SV. Or not knowing what EXPLAIN is. I could go on with examples of inexperienced engineers who crippled their company's ability to service their paying clients.

Re: Behaviours to avoid in a software architecture role

#134

Post by sokoloff »

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.

Exactly. Maybe there are companies facing problems so unimaginably vast that architects who can’t write any code are critically needed. (Not who don’t which would be okay for a lot of companies, but who can’t.)

To me, this seems more like an executive chef who doesn’t know (or has forgotten) how a knife works rather than an Elon Musk or Henry Ford who doesn’t know how to weld a body panel.

Re: Behaviours to avoid in a software architecture role

#135

Post by sokoloff »

tguvot wrote: post #122
Too wrote: post #120

Earlier quoted context omitted.

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…

For the record, with that interview, even saying “in python, I’d use the standard library avg(list), because it would be ridiculous to re-implement provided and tested ecosystem functionality” would have served him well in terms of indicating he wasn’t an utter fraud. That alone wouldn’t land the job, but it would be a strong positive.

Re: Behaviours to avoid in a software architecture role

#136

Post by ClumsyPilot »

btilly wrote: post #94
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…

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

"Companies do tend to promote good programmers to architect, and you don't want to miss out on those programmers."

Everything in your responce sounds to me like in your view, architect is 'extra senior' developer, whereas I understand it to be a different job. Isn't what you are describing a principal engineer?

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

To eliminate that possibility, you can ask questions about the code, how it was designed, etc. Presumably if they stole the code, they are not going to know it inside-out, like the author would.

Re: Behaviours to avoid in a software architecture role

#137

Post by tguvot »

btilly wrote: post #132
tguvot wrote: post #118

Earlier quoted context omitted.

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

Your self-assessment matches the self-assessment of other systems architects that I've seen. Suffice to say that my assessment was so different that I never again want to work at a company who have people who think that is their job. And I've seen a wide variety of programmers from a wide variety of companies agree. As a random example look up the thread for someone who had decades of bad experience with architects a…

Totally understand you At my last job I was "granted" a team of architects. One of them got self-terminated after a few weeks as he was completely useless and he knew it (he got even more senior job in different company), one was okay and one required constant supervision because he was astronaut architect (he left after half an year).

Architects that know what they are doing are hard to find (my last positions were open for 6-9 months before i arrived. me hiring extra architects is similarly long process). From the other side, hiring manager/interview loop needs to have proper skill set to evaluate person and to make sure that this is what they look for (last time i got interviewed by principal architect, vp r&d, and a bunch of hands on dev leads from different departments across the company).

Re: Behaviours to avoid in a software architecture role

#138

Post by dasil003 »

Person5478 wrote: post #64
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…

My experience is that people rationalize what they want. If they want microservices then you're going to get microservices. It's not all nefarious, I think if many of them truly _UNDERSTOOD_ the difficulties of microservices it would give them pause (there's a difference between knowing and understanding), but they want what they want, they're optimistic, and they tend to back into the reasoning afterwards.

That’s a junior mentality. There’s nothing more dangerous to a resource constrained startup than a highly talented engineer who thinks this way.

Re: Behaviours to avoid in a software architecture role

#139

Post by tguvot »

sokoloff wrote: post #135
tguvot wrote: post #122

Earlier quoted context omitted.

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…

For the record, with that interview, even saying “in python, I’d use the standard library avg(list), because it would be ridiculous to re-implement provided and tested ecosystem functionality” would have served him well in terms of indicating he wasn’t an utter fraud. That alone wouldn’t land the job, but it would be a strong positive.

depends on the company. i once (15 years ago) was interviewing with a company and they essentially asked me to whiteboard some regex like pattern matching flow. i did it, and after completing it to their satisfaction i said that in real world i wouldn't do it, as it's waste of time and will use lib* whatever. I didn't get this job :) a few years later, i discovered that few guys on one of the teams were from this very company. what was standing out about them, it's that they always had to reinvent any standard functionality/library with peak of it been their own xml-rpc protocol that they came up with, because xml-rpc wasn't good enough. I guess ethos of this company and all people that they hired, was to reinvent wheels, bicycles, etc and I didn't fit that ethos well .

this was also the only whiteboard coding interview in my life

Re: Behaviours to avoid in a software architecture role

#140

Post by bluefirebrand »

imafish wrote: post #125
pc86 wrote: post #111

Earlier quoted context omitted.

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.

And don't forget "Hasn't actually worked hands on with anything you're doing for a decade"
Post reply on HN