> I believe you may just not know what tacit knowledge is
Not sure where you got that from, haven't said anything about it nor did I include that in my quotes.
I'm well aware of it. But if I have one comment on it would be that I see it more as something an experienced person (or someone with a natural knack for it) makes use of under-the-hood, the resulting quality of the output however can usually be recognized by everyone, not something reserved for the "blessed ones". Take the redis source code for example (quite a few years since the last time I read it though). The author clearly has this skill, but one doesn't have to possess that to recognize the code quality (and btw, iirc without any mentions of a pile of design patterns/methodologies, just "doing it", but to each their own).
So therefore I'm a bit suspicious of anyone that claims that their idiosyncratic setup is actually simple if you just have experience enough to be able to judge it. I'm not saying that everything can be obvious at first glance but the vagueness triggers my radar after being worn down by experiencing way too much over-engineering motivated by self-serving vagueness and/or word salads ("baffle them with bullshit").
That said, if a code base keeps requiring you to make the correct design decision using subtle knowledge, that's a fragile situation and something seems off. You've probably already made the code base too complicated, my prejudices (somewhat confirmed by the language used in one the articles you linked [1]) would be through a pile of design patterns inspired abstractions that now everyone needs to be able to juggle at all times.
[1] "For example, the Tell, Don’t Ask principle can’t be expressed directly in terms of Push, Don’t Pull, which has a more common name: encapsulation. And each one of these qualities reflects cohesion and coupling. And furthermore, cohesion and coupling are inter-related and affect each other. Afference and efference are kinds of coupling. Afference is inbound coupling, and efference is outbound coupling"
> Not sure where you got that from, haven't said anything about it nor did I include that in my quotes.
I got it from here:
> This was specific to the tendencies in other replies to defer to your (or your team's) brilliance/experience ...
and
> Being so cocksure and backing it up with statements that you need to be as brilliant as you to "understand" is such a laughingly large red flag...
Given that at no point did I point to our "brilliance", I assumed you refererring to my pointing to tacit knowledge:
> It's honestly a hard question to answer because the real answer requires tacit knowledge...
> ... because much of what we do requires tacit knowledge to see the benefit of ...
So if I'm mistaken, I apologize, but please do point out where I claimed brilliance. I am certainly claiming experience, and expertise, but those are earned, as they are in any profession. It's also true that no one in this conversation (including you) other than me have actually seen our code, and therefore would be ill-equipped to judge it. That is, they do not have the experience of our code base. Rushes to judge it based on pre-conceived notions only reflect a lack of dilligence, integrity, and/or awareness.
> the resulting quality of the output however can usually be recognized by everyone...
Have you seen our code? Or have you seen a few mentions of some of the things that we do and you are using that to fabricate an idea of what our code is?
> So therefore I'm a bit suspicious of anyone that claims that their idiosyncratic setup is actually simple
You are of course free to be suspicious. A significant part of the experience necessary to judge it would be to actually see it. We are, at the end of the day, dancing about architecture. You cannot see our code, you cannot see our actual set up, which typically would mean that one would have essentially nothing to say about it. If you'd like to refute particular practices I mention, that's fine. But please, keep your presumptions to yourself, or at least ask them in the form of a question (e.g., "artificial partitioning").
> ...would be through a pile of design patterns inspired abstractions that now everyone needs to be able to juggle at all times.
We have relatively junior developers on our team. There are a small handful of common patterns that are used repeatedly throughout our code base. We strive to eliminate special (unnecessary) variatation so there are always exemplars and/or documented norms. We don't have 10 varieties of "service objects". We don't have callback hell. They do not struggle with these things. They struggle with other things, as they are relatively junior, but we support them. Again, frankly, you have absolutely no idea what you are talking about and you are continuing to attempt to make up for your ignorance (of our code base and what I am saying) with hubris and presumption.
I just saw this edit from you:
> That said, if a code base keeps requiring you to make the correct design decision using subtle knowledge, that's a fragile situation and something seems off.
You and I have two different ideas of expertise and software design and they are irreconciable. Maybe in 15 years you can look back on this conversation and recognize that there was always land beyond the horizon. Or maybe not. You are the doctor that is refusing to wash his hands before surgery because you still believe in bad humors. There are things you do not know, and you are stubbornly refusing to recognize them. You have probably worked on some pretty horrific code bases, and you can probably back up every one of the things you are projecting onto me with personal experience, but you have drawn the wrong ultimate conclusion. You have drawn the conclusion that software design does not exist and does not have consequences and that anyone who claims to do it is a charlatan. That may even be true much of the time (goodness knows that's what I'm saying about many people who claim to be doing software design). Judge me as harshly as you wish for making this assessment. Thankfully, we do not work together and we will be unlikely to cross paths again in the future.
> Given that at no point did I point to our "brilliance", I assumed you refererring to my pointing to tacit knowledge
I deduced it from your general tone. But you're probably right that the tacit was part of it.
> Have you seen our code?
No, but it was a general comment, hinted by providing the redis source code as an example.
> and presumption.
Yes, it was prejudicial, as stated. I hope I'm wrong.
> You and I have two different ideas of expertise and software design and they are irreconciable.
Agree.
> Maybe in 15 years you can look back on this conversation and recognize that there was always land beyond the horizon. Or maybe not. You are the doctor that is refusing to wash his hands before surgery because you still believe in bad humors. There are things you do not know, and you are stubbornly refusing to recognize them.
And here's why I said your arrogance would make it unfruitful. Because in the end you're of course objectively right, and I'm objectively wrong and will see my errors in due time. Sigh.
> Thankfully, we do not work together and we will be unlikely to cross paths again in the future.
Not sure where you got that from, haven't said anything about it nor did I include that in my quotes.
I'm well aware of it. But if I have one comment on it would be that I see it more as something an experienced person (or someone with a natural knack for it) makes use of under-the-hood, the resulting quality of the output however can usually be recognized by everyone, not something reserved for the "blessed ones". Take the redis source code for example (quite a few years since the last time I read it though). The author clearly has this skill, but one doesn't have to possess that to recognize the code quality (and btw, iirc without any mentions of a pile of design patterns/methodologies, just "doing it", but to each their own).
So therefore I'm a bit suspicious of anyone that claims that their idiosyncratic setup is actually simple if you just have experience enough to be able to judge it. I'm not saying that everything can be obvious at first glance but the vagueness triggers my radar after being worn down by experiencing way too much over-engineering motivated by self-serving vagueness and/or word salads ("baffle them with bullshit").
That said, if a code base keeps requiring you to make the correct design decision using subtle knowledge, that's a fragile situation and something seems off. You've probably already made the code base too complicated, my prejudices (somewhat confirmed by the language used in one the articles you linked [1]) would be through a pile of design patterns inspired abstractions that now everyone needs to be able to juggle at all times.
[1] "For example, the Tell, Don’t Ask principle can’t be expressed directly in terms of Push, Don’t Pull, which has a more common name: encapsulation. And each one of these qualities reflects cohesion and coupling. And furthermore, cohesion and coupling are inter-related and affect each other. Afference and efference are kinds of coupling. Afference is inbound coupling, and efference is outbound coupling"