Perhaps related, but after ~10 years or so of experience working as a software developer I tend to value the following:
- I care much more about modularity and clear boundaries between systems than about code quality within individual systems
I know modularity and code quality may be related, but most of the time we can clearly distinguish them. I don't care much about variable naming, abstract classes vs interfaces, functional programming patterns, SOLID, DDD... as long as we are talking about a system (or module) that is contained and has well defined boundaries to the outside world (or to other systems/modules). Yeah, I know, DDD should touch on the topic about clear boundaries and the like, but in my experience people use DDD as an excuse to introduce CQRS, event buses, a huge myriad of directory layers...
The typical example is the monolith that is developed early on in a startup: it has no boundaries, no clear scope, but every engineer cares deeply about "hey, you should not use inheritance there! Let's use interfaces instead", "uh, that variable name doesn't look right", "oh, that's not restful enough", etc., ... but everybody ignores the elephant in the room that is going to cost the company a fortune (if they survive long enough): no modularity at all.
Give me any day of the week N modular systems with clear interfaces (but written poorly inside) over 1 monolith that has no clear boundaries but follows whatever is newest in Fowler's blog.
I feel like Fowler typically communicates the "it depends on context, and you need to think on your own" part well.
If you haven't read it: I think you'd like the book A Philosophy of Software Design by Ousterhout. It has a very strong notion of what you said and discusses this in a down to earth kind of manner. Very few terms were invented in that book, but it showcases a collection of sensible heuristics and actionable advice.
- I care much more about modularity and clear boundaries between systems than about code quality within individual systems
I know modularity and code quality may be related, but most of the time we can clearly distinguish them. I don't care much about variable naming, abstract classes vs interfaces, functional programming patterns, SOLID, DDD... as long as we are talking about a system (or module) that is contained and has well defined boundaries to the outside world (or to other systems/modules). Yeah, I know, DDD should touch on the topic about clear boundaries and the like, but in my experience people use DDD as an excuse to introduce CQRS, event buses, a huge myriad of directory layers...
The typical example is the monolith that is developed early on in a startup: it has no boundaries, no clear scope, but every engineer cares deeply about "hey, you should not use inheritance there! Let's use interfaces instead", "uh, that variable name doesn't look right", "oh, that's not restful enough", etc., ... but everybody ignores the elephant in the room that is going to cost the company a fortune (if they survive long enough): no modularity at all.
Give me any day of the week N modular systems with clear interfaces (but written poorly inside) over 1 monolith that has no clear boundaries but follows whatever is newest in Fowler's blog.