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.
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…
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 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.
Past me understood my codebase. Present me wonders what the hell that guy was thinking
There is a salient point being made, but the statement is “I’m here to stand up for the big guy”
Manager say what
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.
That sounds pretty crazy!
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.
Complexity engineering. You have to develop an intuition of how much chaos your change will introduce. And learn to be fast when shit breaks.
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.
