In Defense of Not Understanding Your Codebase
I argue that in large software systems, expecting engineers to fully understand the entire codebase is unrealistic. Unlike small projects where total comprehension is possible, massive systems require working with partial theories. I challenge the idea that we should always rebuild from scratch, emphasizing that navigating complexity with imperfect knowledge is a necessary and valid engineering practice.
In sufficiently large codebases, everyone operates with an incorrect theory of the program.
- FridgeSeal
This reads an awful lot like post-how justification of poor business practices.
It’s got a bit of”uhhmm actually, poor management and high turnover is good actually” vibes, which is then (over)extended to a kind of carte-Blanche justification of “why using kms and having no idea of what’s going on” is good-and-desireable.
Which is like, certainly a take, and I can think of at least one “technical skills hating” exec from a past life who’d read this and foam at the mouth to feel justified in their decisions to try and throw all engineering practices out with the proverbial bath water.
- ForHackernews
> However, at work you are paid to do a job. In other words, they pay you money to adopt their set of engineering values. It’s hopefully well-understood that however much you might personally care about performance, sometimes you have to write slow code at your job (for instance, to get a project done on time, or to accommodate some awkward requirement). Maintaining a theory of the codebase is the same kind of thing.
Sure, yes, this is basically the difference between a professional and hired goon. And it is true that the majority of software devs operate as hired goons.
For enough money, I will do (almost) anything management tells me to do. Not my circus, not my monkeys.
- andai
>[codebases break down into small ones, well understood, and big ones, poorly understood]
I'm in a third category, where I have many small projects, and come back to each one infrequently, so that I'm more or less starting from scratch each time. Small codebases, rarely accessed, poorly understood.
(I noticed with dismay that with some AI assistance, I no longer understood many parts of my code. Then laughed darkly when I realized, yeah, I had that problem before AI too...)
I've been testing various techniques to remedy this. One of them was the Feynman Technique: explain (a narrow slice of) the codebase in my own words. The issue here is that it doesn't necessarily force contact with reality.
For example, one time I investigated my game's bullet netcode, and then explained it until I was satisfied I had understood it correctly. Except, my explanation turned out to be completely wrong, because it was based on an assumption I hadn't made explicit (and therefore hadn't verified).
So it's a good start -- and a great habit to get into, I think, explaining things in your own words lets you "inspect the objects of your own mind", to see if they are sound -- but a forcing function, it is not! It doesn't check your work.
I found one I like, though: modding. Making a change to a codebase. This forces your mental model into contact with reality. (It's also more fun, in my opinion. Most programming is archaeology, but archaeology in service of building something new is a lot more satisf […]