this post was submitted on 11 Jul 2026
4 points (70.0% liked)

Programming

27651 readers
241 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 3 years ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
UlrikHD@programming.dev
bugsmith@programming.dev
Spyro@programming.dev
4
In defense of not understanding your codebase (www.seangoedecke.com)
submitted 1 hour ago by codeinabox@programming.dev to c/programming@programming.dev
7 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
[–] CombatWombat@feddit.online 10 points 1 hour ago

I find this argument kind of facile. Sure, the codebase that you are working in is 10 million lines and you can't understand it, but your team owns a subset of that, hopefully with a well-defined interface, and it is reasonable to expect a team to fully understand their subsystem. Whether all submodules are broken out into separate repositories or stored in a big monorepo doesn't change my expectation that when I sit down in a meeting with the engineers from your team, I expect them to be able to readily answer questions about what the system does and how it does it, even if they had to implement something they would have preferred not to for legal reasons.