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.

  • Kissaki@programming.devEnglish
    1·
    1 hour ago

    They’re making good, correct arguments, but by not acknowledging and valuing understanding [partials of] your codebase, it ultimately (subjectively) reads like “too far in that direction”. Maybe it makes more sense in a big enterprise setting, but I think we’re talking about software development in general.

    Like many software tools, LLMs are a double-edged sword: they make it harder to construct a detailed mental theory of the software, but they allow you to build a partial theory quickly and they can help you leverage that partial theory more effectively. This is a complex tradeoff that I’m still thinking about.

    Building a theory model is simple, verifying it is not. If possible, assumption verification, automated tests verifying assumptions, manual review of coverate of tests vs assumptions and cross references are important to validate theories.

    In the end, it’s always a weighing of effort, necessity, and more, and weighing factors depend on the environment.

    Other people being allowed to write code in your codebase

    I work in a small team but on a big and long-running project [ecosystem]. I’m fine with people doing stuff without me in the loop as long as I can depend on them for care, due diligence, and understanding. Even then, I often find it valuable for me and the project to be in the loop to be able to raise concerns, ensure quality and longlevity/maintainability.

    I struggle with one colleague in particular, which I can not be sure to be even surface-level correct (they often are, but at times, repeated absolutely obvious wrongdoings), who does not document their understandings intentions or thoughts, and does not seek out understanding from sources or colleagues. Ultimately, we as a team and I personally are responsible for the customer’s product, so this situations is quite frustrating and tense to navigate with some inefficient reviews, concerns, and my other [more productive] tasks.

    I don’t think waving away other colleagues’ contributions is constructive and productive for a project and it’s health, but I do try to move myself away from owning or being involved in everything, even at the cost of quality, certainty, and risk.

    I would assume even for big teams that split into local and wider teams, it’s a concern you should think about and make conscious decisions about. Teams should own their products, they have to navigate and nurture how they work together, and have to continuously weigh effort and consequence.

    they pay you money to adopt their set of engineering values
    […] sometimes you have to write slow code at your job […] Maintaining a theory of the codebase is the same kind of thing.

    They certainly don’t pay me to only adapt to their engineering values. This is probably again about huge companies vs smaller teams. For me, they pay me to bring my engineering values. As a lead, I ensure we have, adjust, and follow engineering values.