3 ms·

In defense of not understanding your codebase

22 points by saikatsg 3mo ago

bediger4000 3mo ago
Looking at this blog post, and the history of blog posts from this blog on HN - Goedecke apparently assumes his audience is VP's and CTO's. Goedkecke doesn't quite write the anodyne sound bites that Seth Godin does, but neither does he write anything of engineering use, just vocabulary explainers for people who want to know kind of what their tech leads and line managers are talking about.
- turtleyacht 3mo ago
  It's disconcerting most of the time. I follow the technical line of reasoning, and then it goes off into a kind of uncomfortable place. Deferring to their experience, but thinking, "Is this what winning is?" And wondering if that is the natural endpoint of progression.
- zero_shift 3mo ago
  Goedecke seems to me like a Professor Pangloss type character, explaining to executives in prestige tech orgs (like his employer GitHub) why we should trust and respect the decisions of executives in prestige tech orgs
- stephantul 3mo ago
  I think he is a good example of someone who writes mainly to show he is ready for the next rung of the corporate ladder. That is, his posts are not meant to be useful, but to show higher-ups he is useful to them.
FridgeSeal 3mo ago
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.
- incrudible 3mo ago
  I read it more as pointing out the inevitable and accepting the implications. You can not call it the result of poor practice when every business beyond a certain size has this problem. Perhaps the problem could be mitigated by keeping the company itself small, but that has nothing to do with programming anymore.
  - deleted 3mo ago
    [deleted]
ForHackernews 3mo ago
> 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.
feverzsj 3mo ago
That's why enterprise software suck. And LLM just makes them even worse.
sorokod 3mo ago
The author seems to refere to software systems, code base and programs interchangeably. We can choose human-comprehensible scopes and do that all the time with modules, packages,services, APIs. In nobody understands it all , "it" is doing a lot of heavy lifting and given the choises we can make is wrong and should be resisted.
andai 3mo ago
>[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 satisfying, at least to me!)
- Ferret7446 3mo ago
  Well, that's why clean, well documented code is (was?) so important, because even if it's your code, you will forget and have to read it later.
andai 3mo ago
The article links to another article by the same author, Wicked Features, which I now reposted to HN because it seems worth discussing: > Wicked features are features that must be considered every time you build any other feature. https://news.ycombinator.com/item?id=48932749 https://news.ycombinator.com/item?id=48932749 Highly related to TFA, in my opinion, this question of "how do you keep the code comprehensible in the first place?"
mentos 3mo ago
Whats the discussion around architecting a codebase where you don't need to understand the whole thing to operate inside of it? Which large/massive codebases are considered the best to work in and if we examine their architecture what provides for that?

22 points by saikatsg 3mo ago

Looking at this blog post, and the history of blog posts from this blog on HN - Goedecke apparently assumes his audience is VP's and CTO's. Goedkecke doesn't quite write the anodyne sound bites that Seth Godin does, but neither does he write anything of engineering use, just vocabulary explainers for people who want to know kind of what their tech leads and line managers are talking about.

turtleyacht 3mo ago
It's disconcerting most of the time. I follow the technical line of reasoning, and then it goes off into a kind of uncomfortable place. Deferring to their experience, but thinking, "Is this what winning is?" And wondering if that is the natural endpoint of progression.
zero_shift 3mo ago
Goedecke seems to me like a Professor Pangloss type character, explaining to executives in prestige tech orgs (like his employer GitHub) why we should trust and respect the decisions of executives in prestige tech orgs
stephantul 3mo ago
I think he is a good example of someone who writes mainly to show he is ready for the next rung of the corporate ladder. That is, his posts are not meant to be useful, but to show higher-ups he is useful to them.

FridgeSeal 3mo ago

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.

incrudible 3mo ago
I read it more as pointing out the inevitable and accepting the implications. You can not call it the result of poor practice when every business beyond a certain size has this problem. Perhaps the problem could be mitigated by keeping the company itself small, but that has nothing to do with programming anymore.
- deleted 3mo ago
  [deleted]

ForHackernews 3mo ago

> 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.

feverzsj 3mo ago

That's why enterprise software suck. And LLM just makes them even worse.

sorokod 3mo ago

The author seems to refere to software systems, code base and programs interchangeably. We can choose human-comprehensible scopes and do that all the time with modules, packages,services, APIs. In nobody understands it all , "it" is doing a lot of heavy lifting and given the choises we can make is wrong and should be resisted.

andai 3mo ago

>[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 satisfying, at least to me!)

Ferret7446 3mo ago
Well, that's why clean, well documented code is (was?) so important, because even if it's your code, you will forget and have to read it later.

andai 3mo ago

The article links to another article by the same author, Wicked Features, which I now reposted to HN because it seems worth discussing: > Wicked features are features that must be considered every time you build any other feature. https://news.ycombinator.com/item?id=48932749 https://news.ycombinator.com/item?id=48932749 Highly related to TFA, in my opinion, this question of "how do you keep the code comprehensible in the first place?"

mentos 3mo ago

Whats the discussion around architecting a codebase where you don't need to understand the whole thing to operate inside of it? Which large/massive codebases are considered the best to work in and if we examine their architecture what provides for that?