Hacker News new | ask | show | jobs
by trhoad 1410 days ago
The utopia described isn't real in the enterprise, and my experience of 15 years working as a Software Engineer is that 90% of engineers are really good at coding, but pretty terrible at systems architecture - often taking the path of least resistance for their small domain.

It may be unpopular to prefer a top-down approach, but in my experience architecture set by an architecture team who understand how the building blocks fit together, who have a roadmap and a set of common rules and tools (not loose principles or "guidelines") have been the most successful, sane, and enjoyable projects to work on. YMMV - and there are certainly some terrible "architects" out there whatever approach you take.

Related: I am convinced that you will learn more about a Senior Engineer at interview during a Systems Design task than any coding task. This is what sets apart great engineers from good engineers.

2 comments

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.

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

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

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

What's the distinction between rules and principles here, given that you've explicitly called out not principles?
Principles are never to be broken and sometimes their cause forgotten, rules have flexibility or exceptions and a good reason most can agree to. ;)
I was actually going for the opposite - but that's my fault. What I meant was wishy-washy "guidelines" are often ignored or considered optional. Put in place tooling (rulesets) and processes that make it very difficult to architect a poor system.
Processes I understand, could you give some examples of tooling/rulesets that one could use?