| Good architecture is not about the patterns you pick. It’s about having a team dev cohesively on any pattern(s) - programmatically enforce your style with in-house linters and scaffolders. Be highly opinionated - if you # ignore anything, leave a comment explaining why - use bdd so your cases are human readable and must update with the code (unlike a stale comment) - follow the same pattern in all your services (I love hexagonal design for backend). If you break from the design have a good reason for it - COMPOSE your code. It’s almost always the case that two endpoints or jobs or whatever happen to have a few things in common, but differ wildly. Don’t get DRY, just import those things in each spot and don’t entangle them with each other, it’s too confusing - scope your interfaces tightly. No optional params unless the domain is actually optional. Make separate jobs or endpoints for different configs. I can’t figure out wtf all your configs were from 4 years ago and neither can you - code is default testable with DI/DIP - always run tests running real infra like testcontainers
- cement ci/cd as your guardian. Employ every linter you can. - hammer workarounds with comments in the code - break all systems into small problems and nothing is challenging technically (though the domain might be!) - work with less people on your code. It’s easier to stay aligned and follow the same patterns - don’t expect anyone to figure it out. You need to champion your changes. Do code reviews, hold their hand, show them the way - clear out mundane items like installfests, local auth, server reloads. Slow dev pisses people off - finally, and most important, employ an org policy for review. Don’t let shit fall through the cracks unknowingly. It compounds. You have skills now as a quick and dirty to eval and enforce. Use them! |
I wonder sometimes if the role of architect in a business might be about having a group/team wide senior person who
- Knows how to architect systems very well and can share that knowledge with the larger group and more junior devs - Is a kind of high level business analyst who can speak "business, stuff that makes money" and "dev, how it's done" to each of those groups effectively
Does Google/Atlassian miss out on things by not having system architects? ... Or can they achieve what's needed by having sensible team rules (so architecture gets followed) and relatively standard reusable architectures (so it's not too hard to adapt to a given business solution).
I'd be genuinely interested to know. My aspiration was to become an architect, but I now wonder if this is the right way to go.