Manager say what

An argument could be made that the first group is about engineering software, while the second group is about navigating a certain kind of adversity.

I guess one could call the latter a kind of engineering, but not of software.

I worked on a 1.8GB c/c++ codebase, split up on 720 something projects, all making a one monolithic software. There were loads of other code too like python, shellscrips, diverse databases, c#, you name it, you could probably dig it up somewhere.

No one knew half of even a quarter of it all. Some parts were known to many, some parts were feared, some were known to nobody.

Fantastic software but also having some of the most hilarious bugs provoked when developing.

Two things: this is phrased as if each change by another developer ruins your theory of the codebase. This is an oversimplification. Changes to the core engine of the codebase can change the theory of the product but many changes are cross cutting concerns. This is why new developers on large codebases are commonly assigned integration work. You develop a theory with a real lower stakes output.

Second the llm thing. Putting aside hallucinations you could get a start of a theory from an llm but you’ve conditioned yourself to be reliant on the llm. To put things in similar terms of tech job stuff like this article does: prior to llms most teams had at least one SME on the whole codebase. They’d get bombarded with questions and if you had any politeness you wouldn’t bother them with every single question about the code or product as a whole. Occasionally you would need to but there was a natural social forcing function to figure stuff out on your own. Llms are the complete opposite: they tell you “good question” “good insight” etc. brains like short cuts so now there is no forcing function.

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.

There is a salient point being made, but the statement is “I’m here to stand up for the big guy”

Past me understood my codebase. Present me wonders what the hell that guy was thinking

Completely unrelated, but I see this person’s photo pop up in the link preview frequently around Lemmy and it always reminds me of the type of condescending smile someone would make as they bait you and say “go ahead, punch me”. I’m sure they’re a nice person. Just always trips me up.

I really don’t want people using this as justification for going from human coding a code base they understand fluently, to AI shitting out loads of files and lines of code they don’t understand…

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.

There’s no defence for that. If you’re incapable of understanding you vibecoded mess, don’t get it out. Basta.
And companies slapping together a Iceberg of frameworks, that’s a lesson they are still learning but which shows results already (security nightmares everywhere).

I’ve worked on both kinds of codebase and on the big ones nobody ever had the full picture anyway. The understanding got rebuilt when it was needed, from the tests, the docs and the commit history. Agents make that rebuilding much quicker, so partial understanding doesn’t worry me too much, as long as the team keeps writing those things down. If they stop bothering because the agent seems to cope without them, that’s where I’d expect the trouble to start. I’ve written up the tests side of this here: prickles.org/tenet/living-documentation/TS1

I’ve noticed that there are two types of people

Messy & ordered

Both can produce functional systems, but the second tends to produce higher quality systems with higher success rates.

The first group doesn’t believe that the second group exists.