Programming

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.

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 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.

An argument could me 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.

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

Manager say what