dandi8

I think this is compatible with TDD. It's just fancy divide-and-conquer.

You need the problem space to be restricted to a manageable bunch of classes. If that's not the case, split the problem until you get there.

Make sure you have 100% test coverage on this piece of code and that the tests are actually understandable and documenting the functionality well. You might find that there is unreachable code which should be deleted. Mutation testing may also help find code paths which are untested (and so edge cases you might not have considered).

Until that is true, write tests and/or refactor existing ones. At this point you may find a ton of new bugs there. Better find this now than later and then wonder whether your own changes introduced them. Your new failing tests will document the presence of those bugs.

By now you should have full documentation of what the code is supposed to do via tests. This will be tremendously helpful in understanding the code.

Then go public method by public method, line by line, renaming variables, extracting private methods etc. Your basic run-of-the-mill refactoring of classes, until you fully understand what's going on in the production code.

For every small refactor, run the tests and commit if they pass. If they fail, you only have a small amount of uncommitted code which you know is the culprit.

Finally, fix any bugs you documented in the test writing stage.

At this point you can add any new functionality to the code.

In Big Ball of Mud projects, it's easy to not notice AI generated code introducing more bugs into the codebase, slowly bringing the project to a halt and its inevitable death due to the rising cost-to-profit ratio of producing new features.

I'm guessing the project doesn't have the tests, tooling or practices to catch even the more obvious bugs before they go to production. Now consider that LLMs are great at producing code that looks just right, but may behave differently than expected.

Finally, LLMs are said to be a productivity multiplier. Now what happens if you multiply bad practices...?

You seem aware of issues within the company. I assume you either voiced them and were ignored, or felt it was unsafe to do so.

My advice would be to think about what you would want your next project to be like. Something with more of a focus on quality, I imagine. Perhaps using DDD? Maybe remote, with less focus on churning out code and more focus on the actual requirements? Write your wishlist down, then start looking at job postings. Apply when one seems "good enough". It will take a long time, you'll get rejected a lot, but I bet you'll eventually find something better.

This is incredibly disappointing...

Given the original announcement footage, it might be for the best...

That's not an insignificant number.

Why, given "Good Old Games" is no longer the name of the store?

I really want them to bring back self-hosting. Multiplayer games don't need to have a limited lifespan.

What an unnecessarily exclusionary take.

If you need comments to explain what is happening (and not why it is happening), then you've got some bad code that needs refactoring.

It depends. Extraordinary claims require extraordinary evidence.

I'm assuming it was hyperbole, not literal.