Andrew Clark

ALT 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 codebases. Here’s what I wish I’d known at the start. The cardinal mistake is inconsistency

ALT 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 consistency so important in large codebases? Because it protects you from nasty surprises, it slows down the codebase’s progression into a mess, and it allows you to take advantage of future improvements.