[neko-kai]

I don't think it's possible to write a flawless codebase. That doesn't mean SWEs don't seek mastery of their craft. Moreover, achieving mastery doesn't mean you would actually want to write an 'ideal codebase', that seems like an art project disconnected from the purpose of the craft.

[bdangubic]

“mastery of the craft” is a myth… whatever codebase you see (and I’ve seen more than I can count) you will go “wtf is this?!” over and over again. furthermore, whatever codebase someone was lucky enough to initially start with, after X amount of time you asked those same masters (if they are still around) and they will inevitably tell you “oh boy, if I can start this over, I would have…” there just is no mastery, there are just people that deeply care about what they are building and try their best not to F it up along the way but all the “craft” and “mastery” talk is just empty words people talk around fireplaces and/or at various conferences where people pitching “craft” and “mastery” and “you need [insert dev process du jour XP/agile/…]” are there to make money selling the bullshit

[vlovich123]

I think you are conflating mastery with some kind of beautiful codebase that is completely obvious to everyone else. Einstein had mastery over physics and yet his ideas required a lot of studying to understand and explore.

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.

[zingar]

I’m shocked to hear how different your experience is from mine. I very often see good code and bad code and the difference is very clear, even years into a project.