0
In defense of not understanding your codebase (www.seangoedecke.com)
submitted 4 months ago by to c/programming@programming.dev
22 comments fedilink hide all child comments
 

My guess is that people who work on small codebases with low-turnover teams (say, Redis or games like The Witness) would say “obviously you have to understand it completely, otherwise you can’t do good work”. I’d also guess that people who work on large codebases with high-turnover teams (say, the Google web search backend or GitHub) would say “obviously you can’t understand it completely, you just have to do the best you can in your local area”.

These are two largely different ways of programming with different methods, practices and cultures. However, the first group is over-represented in online discussion about software engineering. I want to defend the second group against the first.

you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 4 months ago

I've worked on both kinds of codebase and on the big ones nobody ever had the full picture anyway. The understanding got rebuilt when it was needed, from the tests, the docs and the commit history. Agents make that rebuilding much quicker, so partial understanding doesn't worry me too much, as long as the team keeps writing those things down. If they stop bothering because the agent seems to cope without them, that's where I'd expect the trouble to start. I've written up the tests side of this here: https://prickles.org/tenet/living-documentation/TS1

  • permalink
  • fedilink
  • source
    •