flâneur

Mistakes engineers make in large established codebases

seangoedecke.com · 1,542 words · saved by 2 readers

Working in large established codebases is one of the hardest things to learn as a software engineer. You can’t practice it beforehand (no, open source does not give you the same experience). Personal projects can never teach you how to do it, because they’re necessarily small and from-scratch. For the record, when I say “large established codebases”, I mean: I’ve now spent a decade working in these codebases. Here’s what I wish I’d known at the start. There’s one mistake I see more often than anything else, and it’s absolutely deadly: ignoring the rest of the codebase and just implementing your feature in the most sensible way. In other words, limiting your touch points with the existing codebase in order to keep your nice clean code uncontaminated by legacy junk. For engineers that have mainly worked on small codebases, this is very hard to resist. But you must resist it! In fact, you must sink as deeply into the legacy codebase as possible, in order to maintain consistency. Why is co

Working in large established codebases is one of the hardest things to learn as a software engineer. You can’t practice it beforehand (no, open source does not give you the same experience). Personal projects can never teach you how to do it, because they’re necessarily small and from-scratch. For the record, when I say “large established codebases”, I mean: Single-digit million lines of code (~5M, let’s say) Somewhere between 100 and 1000 engineers working on the same codebase The first working version of the codebase is at least ten years old I’ve now spent a decade working in these codebase

saved by

related reading