the thing I've found that's produced the most productivity is actually reducing the size of our code base. Makes it way more manageable and easier to add features/fix bugs.

I'd guess most code bases you could reduce by about 50% without losing anything at all.

▲

dimitrios1 2 days ago | parent | next [-]

Which again is ironic, because I've been doing that for most of my career whenever I am introduced to a legacy code base: The first thing I try to do is delete code. I think it's just good engineering practice to try and delete code as much as possible.

	▲	Cthulhu_ 2 days ago \| parent [-]
		Yeah, the best practices for software engineering haven't changed, it just feels like a lot of people forgot about them for a while.

▲

nxobject 2 days ago | parent | prev | next [-]

With luck, SWE culture will change towards caring about large-scale rearchitecture (and reward those who care enough to refactor and polish, polish, polish.)

▲

HPsquared 2 days ago | parent [-]

It's all about massaging out those tight spots and untangling knots. A bit like kneading dough, perhaps, or annealing metal.

▲

0x696C6961 2 days ago | parent [-]

I don't think this will ever be appreciated or rewarded.

	▲	HPsquared 2 days ago \| parent [-]
		Yeah that's basically craft. Craft and beauty aren't usually rewarded unless it can be used for marketing.

▲

rustystump 2 days ago | parent | prev | next [-]

You would lose something but it is because the trade off in complexity isnt worth it. This is the key to keep code low. If there is a thing that is barely used but is 60% of the code, maybe it can go? Ai will try and keep it backward comp forever.

	▲	HPsquared 2 days ago \| parent \| next [-]
		Backwards compatibility is the biggest source of complexity, I think. Although it does alleviate another type of complexity that results from incompatibility.
	▲	soperj 2 days ago \| parent \| prev [-]
		We've done a refactor recently where we removed over 50% of our code, and we still had the exact same product.

▲

BobbyTables2 2 days ago | parent | prev | next [-]

I recently found Opus is pretty good at consolidating very-similar-but-different codebases.

Sure, I had to tell it to so, but it trudged through and did it fairly independently… Was especially nice as refactoring test infrastructure code isn’t always very exciting…

▲

everforward 2 days ago | parent | prev [-]

I’ve toyed with the idea of splitting a deeply nested tree of code into separate libraries for this.

First impression is that it’s a net negative. It gets a lot better at working within that library, and much worse at making it work within the project as a whole.

	▲	rcxdude 2 days ago \| parent [-]
		I think the opposite is probably the way to go: strip out some layers of abstraction, try to keep them to only the really valuable ones. In my experience LLMs are better at dealing with more concrete codebases. It's also a lot cheaper to experiment with different abstractions within a codebase to really get them right, and especially to evolve them as the codebase changes.