← Back to context

Comment by eddythompson80

2 days ago

Pretty normal in many corporate cultures especially ones with high turnover. You get assigned to a team that's "maintaining" a 10 year old code base with few million LoC. The most senior person on the team has been there for a year or 2 and it's just business as usual. You don't know what those 1M+ lines are doing. No one does. It's not a passion of anyone to work on it. You just get a bunch of requirements handed to you, you blackbox everything but the surface areas you need to touch. It's why there are 14 implementations of a background service 8 dependencies that do the same thing, 6 overlapping frameworks, a complete mismatch in style, approaches, etc. It doesn't really matter.

> It doesn't really matter.

It does matter, that's why those people quit because it's such a shitshow, progress happens at a glacial pace, more and more defects and slowdowns keep being created even if they have a big QA department/teams and the users are probably trapped because the software is the only thing in town, the bosses are the ones that makes the purchase decisions, or the it comes attached to big and/or expensive machines and they can't just buy another one for another X years.

  • yes, of course. I meant "it doesn't really matter" in the sense that businesses have been dealing with this since the beginning of software. Strong ownership and passion was one of the selling points of OSS, but that style of ownership was always very very rare in corporate. It just doesn't really fit with how businesses operate. The "passion" is ARR, not engineering principals. Most software is built, sold, and bought by people who don't use it directly.

    • Businesses have been dealing with - more capable one refuse your business and walk away. Or you have to drop prices. And yes, I have seen it happen.

      It is not immediate process, but it is a thing.

  • People quit because maintenance is an unsexy job with poor career prospects.

    The code base itself has never and will never matter in the big picture

    • > The code base itself has never and will never matter in the big picture

      Clearing my throat: I am the first person to tell everyone on the team (repeatedly, until they are sick of hearing it) that the users, use cases, and organizational objectives are always more important than the technology.

      But, in "the big picture" - the Linux codebase doesn't matter? The codebase that powers AWS doesn't matter? Hell, the Microsoft Office codebase doesn't matter? Look at what's happening to Windows when they treat it like the codebase doesn't matter.

      For a tech org, the codebase is the reification of all of your objectives, all of your knowledge about your users and use cases and processes. Long term, a mature codebase plus people who understand it is one of the most valuable things you have. When orgs don't realize this, when they treat their workers and their work product as disposable commodities, we call this "enshittification."

      1 reply →

Human-written code is theoretically surmountable.

Large LLM-written code is called slop for a reason. It's hard to understand because oftentimes it does not follow human logic.

  • Even a bad developer, that is, the average developer, develops a whole in which the parts have some degree of coherence. AIs simulate that, but they don’t have intent and thus this coherence is broken in large code bases.