6 ms·
> The 5000 lines of if else that handles the menu state is a striking witness to this insanity. > He takes the code from 40,699 lines to 7,731 and notably love
by efields 3y ago
> The 5000 lines of if else that handles the menu state is a striking witness to this insanity.
> He takes the code from 40,699 lines to 7,731 and notably loved an excuse to work in C. “I had an absolute blast cleaning up this mess!”
I't just marvelous to learn what kind of crap coding makes it to production. It's a huge boost to my self-esteem.
- rgoulter 3y agoThe risk of 'bad' code is that it might be hard to make the change you want. I would believe that spaghetti code is more likely to have bugs than 'well designed' code. When code is fresh in your mind, there's more tolerance for how disorganised the code can be and still be easy to change. If your shipping method is "one shot".. time spent cleaning it has a chance to provide value; but time spent adding features is very likely adds value. -- Probably if the code is very clean, then at least some time would have been better spent adding features.
- taeric 3y agoYou aren't wrong, but a lot of the risk of "good code" nowadays is that there is more of it. An added risk is a lot of "good code" is leaning heavily on practices that are not good for performance. I don't want to push for lax testing standards. And I generally prefer modern build practices for programming. It is hard to take a lot of criticism of gaming code seriously, though, as games were shipped at what feels like a higher success throughput than most business software.
- Pannoniae 3y ago"Bad" code also has way less abstractions. It's ridiculously easy to change something (unless it's really spaghetti/everything is intertwined) "Good" and modern code often has many abstractions. In some cases, that gives ultimate flexibility, but in some cases, if you are fighting the abstraction or the framework, it will make it almost impossible to change.
- ldjkfkdsjnv 3y agoI was going to post this, abstractions almost never work out well as the code base changes
- gopher_space 3y agoThe IRS isn’t going to get involved if your physics don’t match reality. Defining and creating your own data means you get to skip most of the headaches in business software development.
- taeric 3y agoNot a small point, but I think it is more than IRS concerns that have caused web bloat. Gmail taking seconds to respond to keyboard is definitely not explained away with business logic being hard. Is it?
- fidotron 3y agoIn games it happens quite a bit. The great debate is always "will I want to change this tiny thing here without impacting everything else?" vs DRY. Studio cultures differ, but I would say at least half resort to hard coding things like positions of every item manually given the excuse they might want to shift something by a bit later (in a hurry, crunching etc.) without side effects. Thankfully the emergence of more standard tooling and engines has pushed this to being more of an art resource concern, but it does lead to things like being told that taking a game that assumes a 16:9 1080P display and making it more flexible will take multiple years of person time. Personally I cannot stand this tendency, but do get why they do it.
- hinkley 3y agoYou can get pretty close to the end of a project before you really understand what it was you were trying to do. Especially if management is allowed to keep moving things on you. I think this is substantially the instinct that leads to Waterfall. I just want to know what I'm supposed to be building for a while before you 'ruin' it.
- tomcam 3y ago> You can get pretty close to the end of a project before you really understand what it was you were trying to do. Truer words were never spoken.