[treis]

My experience is the opposite. The more architects there are and the farther they are from the nitty gritty coding the worse everything is. Setting common rules is useless unless they're being enforced. And to be enforced you need to actually be hands on in the code base.

>Senior Engineer at interview during a Systems Design

I also pretty strongly disagree with this. The right answer to systems design in 95%+ of cases is a single application modularized using language tools talking to a single DB. Most of us don't deal with the scale that requires a constellation of systems.

[trhoad]

> And to be enforced you need to actually be hands on in the code base.

I think this might be a difference in opinion on whether we're referring to the architecture of a codebase or architecture of a system. They're different things.

> The right answer to systems design in 95%+ of cases is a single application modularized using language tools talking to a single DB.

There are still a ton of systems design considerations to take into account with a monolithic approach. Good architecture doesn't necessarily always imply a microservices architecture, I agree, but it doesn't mean all architecture concerns can be ignored - you just have a different set of things to optimise for.

[treis]

>I think this might be a difference in opinion on whether we're referring to the architecture of a codebase or architecture of a system. They're different things.

Either way you have to be hands on. I'm not sure how you can be hands on with a system without being in the code but I suppose anything is possible.

>There are still a ton of systems design considerations to take into account with a monolithic approach. Good architecture doesn't necessarily always imply a microservices architecture, I agree, but it doesn't mean all architecture concerns can be ignored - you just have a different set of things to optimise for.

Not really. You need to pick a language/framework & decide on your module boundaries. After that it's mostly building out functionality in the right module following the path your language/framework lays out.

[eternalban]

> Not really. You need to pick a language/framework & decide on your module boundaries. After that it's mostly building out functionality in the right module following the path your language/framework lays out.

You are in fact describing a specific architectural approach, which is not optimal for all situations. OP is considering a general approach to architecture and roles.