Engineering is the intersection of science and economics. You build the thing as best you can with the knowledge you have and you often discover things you didn’t even know once you start building. Combine that with time and resource limitations, and you have to make reasonable short cuts to deliver things.
Also remember that even if there’s one master on a codebase, organizations often pair them with many non-masters to try to accelerate things. What that looks like then is a mish mash of things that don’t make sense because the master is struggling to maintain a coherent vision that other people are executing; it’s hard to develop consistency even when there’s just one person let alone a broader team.
But your benchmark is fine if one master can show another master a codebase and explain why the pieces are there and which pieces are shortcuts and what the vision is. Trying to develop that knowledge by yourself in the middle of the dev cycle is a fools errand; one of the first things I do when I come to a codebase is ask a bunch of questions to build up my understanding of the history of the codebase and why things were done a specific way.
I have and I am sure you have worked with some amazing people over the years but to me our entire industry is so far removed from anything resembling mastery or craft that even mentioning it at this point in my life makes me chuckle (and at times literally laugh out loud)
So my question then is how would you define mastery if you believe our industry doesn’t practice it.
If you have only ever seen one pattern to solve a problem, trivial example of inheritance, and therefore do that to the best of your ability then you have achieved mastery to your ability. Once you see a different pattern, composition, you can then master that and master identifying when which is suitable.
Lack of mastery is just using inheritance despite seeing alternative patterns.
Naturally mastery also includes seeking alternative solutions but just because a codebase uses inferior patterns does not mean those that came before did not strive towards mastery, it's possible that they didn't know better at the time and now cannot get the time to revise the work.
There's always a juggling act in the real world.
Assume incompetence and not malice, and incompetence is not a state of being. A person without experience can be seen as incompetent but quickly become competent with training or experience, but the code they write still stems from incompetence.
Strive to see your previous self as incompetent (learn something new every day)
Others have said some true things but the core is missed. It bothers engineers who care about mastery. It’s the same for architects who see design flaws in buildings that were done by those who don’t care about mastery. Or a filmmaker who watches a movie with lots of flaws. Caring about obtaining mastery means having the capability of seeing the flaws and resolving them.
It could be maturity to resign to powerless forces or it could be the inability to obtain that mastery or the willingness to let go of that mastery. I would think it’s more mature to fight the good fight, but at some point you just get old and tired I imagine. And it’s interesting to posit the author is nihilistic when this “uncontrollable forces” itself is a nihilistic take imho.