Ask HN: What is the best code base you ever worked on?
Engineers swap stories about the best codebases they’ve worked on, ranging from greenfield “blank slates” and tightly focused side projects to massive monorepos like Google’s internal repository and safety‑critical avionics systems. Common qualities they prize include strong code ownership, consistent patterns, simple and well-documented designs, fast and reliable tooling, and the freedom to refactor over time, while overuse of advanced language features, convoluted architectures, and weak testing are recurring anti‑patterns. Many conclude that the “best” codebases are less about specific technologies and more about culture: small, empowered teams, clear boundaries, and steady, continuous improvement.
What People Consider a “Great” Codebase
- Often the favorite codebase is one the person largely designed or fully owns.
- Small, focused apps maintained over many years are described as joyful: easy to fully understand, refactor, and keep consistent.
- Safety‑critical and long‑lived systems with strict standards, exhaustive documentation, and uniform style impress people, even if they’re slow to change.
Tooling, Monorepos, and Developer Experience
- Google’s monorepo and tooling are frequently cited as peak dev experience: fast, reproducible builds; powerful code search; consistent style and presubmits; easy cross-repo changes.
- Some argue this ecosystem is hard to replicate and often not transferable outside such companies; others report frustration with complexity, OWNERS/readability overhead, and internal fragmentation.
- Similar praise appears for other well-tooled environments (Bazel-based mono-repos, Facebook’s continuous codemods, strong CI/CD setups).
Ownership, Culture, and Process
- Clear code ownership (individual or small team) is seen as crucial for quality and long-term evolution.
- Lack of ownership or dysfunctional core teams leads to stagnation, silos, and top talent leaving; overly rigid codeowner systems can also slow work.
- Teams with low ego, strong communication, and shared standards are repeatedly linked to excellent codebases.
Simplicity vs. Advanced Features
- Many value codebases that avoid heavy metaprogramming, DI frameworks, and overused patterns; “advanced” features often make onboarding and maintenance harder.
- Others argue advanced features are fine when used sparingly, with good documentation, and when the codebase is “just a bit more advanced” than its users to enable learning.
- KISS and sticking close to idiomatic framework usage (Rails, Django, etc.) are recurring themes.
Architecture, Modularity, and Scale
- Modularization and clear boundaries are emphasized: small, understandable components, well-defined APIs, and separation of business logic from infrastructure.
- Microservices are praised when each service is small enough to fit in a mental model and can be rewritten independently; skeptics note that a well-architected large monolith should be equivalently manageable, but is rare in practice.
Greenfield vs. Legacy
- Blank-slate projects are romanticized but quickly become “legacy.”
- Some see large, useful systems as inevitably messy; others insist disciplined design, continuous refactoring, and time to clean up hacks prevent that fate.