I don't read cockiness or narcissism in his posts. Having just started reading Clean Architecture by Robert C. Martin two days ago (and hoping to complete it tonight, then planning on re-reading it again), it seems to me that hmeh has learned and PRACTICED what is discussed in that book. I wish I were in their shoes!
Clean Code (What I assume you are referring to with 'CC') is 10 years older than Clean Architecture. I haven't read Clean Code, I just picked up Clean Architecture, but I venture to guess some of his thoughts have changed since then. I also assume that Clean Architecture deals with higher level issues than Clean Code. I may have to pickup Clean Code to see what he said in that.
Thank you. I saw your other post, but it’s gone now. If you want to find me, I’m in the Eventide project Slack and on GitHub (you can find links to some of my posts here in this thread).
Let's just say that that sphere of the software dev community isn't exactly universally seen as competent work, more like the orthodoxy of ~15 years ago that's now increasingly, and in my opinion rightfully, being put into question for its bad complexity and performance trade-offs when applied beyond textbooks and conference talks. And this is being diplomatic compared to others.
I'm certainly not saying there isn't something to learn from them though, I've read a bunch of them, but after seeing countless wasted debugging hours and projects devolve into a complete mess of patterns where you have to ping-pong between files, functions, and patterns providing little to no value is astounding. The option to do non-clever code is seemingly insulting to the self-professed architect, but it is in my own experience at least, vastly more maintainable and productive, not because it results in "clean" code - it's usually pretty dirty and nothing to write home about, but because reading even a page-long flat procedural function that's just doing its thing, is much more straight-forward than ping-ponging between some clever architect's conglomeration of decaying design patterns.
Having the "meat" of the code available with a minimal amount of abstractions/layers also makes it much easier to adapt according to performance requirements without having to propagate changes throughout half the application due to it being entangled in pattern abstractions. (on that note, it sounds like hmeh is trying to work around this problem with abstractions by doing a significant amount artificial partitioning. But that would be solving a mess you've created yourself in the first place). Finally it will still be dumb & dirty code a couple years from now, no need to have all those design patterns internalized.
People promoting these things will of course then just blame it on the dev and call them average, or lacking in experience, because they can't identify and combine the various clever patterns correctly, they "are doing it wrong", and that's where I believe the above narcissistic tendencies I called out comes from.
I see a difference between "Clean Code" and code design patterns and "Clean Architecture". It seems to me that most think I'm speaking of Uncles Clean Code book/ideas when I'm thinking about his Clean Architecture book/ideas.
> The option to do non-clever code is seemingly insulting to the self-professed architect, but it is in my own experience at least, vastly more maintainable and productive, not because it results in "clean" code - it's usually pretty dirty and nothing to write home about, but because reading even a page-long flat procedural function that's just doing its thing, is much more straight-forward than ping-ponging between some clever architect's conglomeration of decaying design patterns.
With all due respect, if you think you are talking about anything that I was attempting to describe, you are not. Everything that we do is based on simplicity and building the most simple things that we can. We may have different definitions of simplicity however. For mine, check out Rich Hickey's "Simple Made Easy" talk if you haven't seen it.
We simplify things by de-complecting or, avoiding entanglement. Having separate repositories is just one way to re-enforce the simplification that we put in place with design. We call that structural design (because it's the design of the actual structure of the application).
> on that note, it sounds like hmeh is trying to work around this problem with abstractions by doing a significant amount artificial partitioning.
I can guarantee you that none of the partitioning is "artificial". I think at this point that you have projected so much of your experience into what I am saying that it's impossible for you to see anything I say in any other light. This, by the way, is what I mean by tacit knowledge. I say X, and you either hear Q, or you hear XIENRSTIENRSTIERNST, either way, you cannot possible understand what I am saying. This isn't a negative reflection on you, or a positive reflection on me. It's simply the way that tacit knowledge works, and it's why most "internet arguments" are wastes of time.
> People promoting these things will of course then just blame it on the dev and call them average, or lacking in experience, because they can't identify and combine the various clever patterns correctly, they "are doing it wrong", and that's where I believe the above narcissistic tendencies I called out comes from.
And yet, it is literally lack of experience (and ability) that prevents people from doing things they cannot yet do. That's how expertise works. Pointing that out is not narcissism. A gardener does not have the experience (or training) necessary to do brain surgery. This isn't a mark against the gardener. The difference in our industry is that it is filled with expert beginners. People who think that because they make 6-figure salaries after their limited education and experience they can now understand everything there is to understand about software design. This just isn't the case. If a person sees that as a slight to a fellow human, that says more about them than it does about the person pointing to that reality.
