Enjoyed this post. A lot of it resonated with me, here's some of my thoughts: Too many small methods, classes or modules Realized I was guilty of this this ye

Enjoyed this post. A lot of it resonated with me, here's some of my thoughts: Too many small methods, classes or modules Realized I was guilty of this this year: on a whim I deleted a couple of "helper" structs in a side project, and the end result was the code was much shorter and my "longest" method was about... 12 lines. I think, like a lot of people, I did this as an overreaction to those 20 times indented, multiple page long functions we've all come across and despised. No port/adapter terms to learn This came under the criticism of "layered architecture", and I don't think this is fair. The whole point of the ports/adaptors (or hexagon) architecture was that you had one big business logic thing in the middle that communicated with the outside world via little adapters. It's the exact opposite of horizontal layering. People say "We write code in DDD", which is a bit strange, because DDD is about problem space, not about solution space. 1. I really should re-read the book now I'm a bit more seasoned. 2. I have noticed this is a really common pattern. Something that's more of a process, or design pattern, or even mathematical construct gets turned into code and now people can't look past the code (see also: CRDTs, reactive programming, single page applications...). Involve junior developers in architecture reviews. They will help you to identify the mentally demanding areas. Years later I remembered how impress that a boss of mine leveraged my disgust at a legacy codebase, and my failure to understand it as a junior (partly my fault, partly the code bases fault..), by chanelling my desire to refactor into something that had direct operational benefits, and not the shot gun scatter refactoring I kept eagerly doing.