[dieselgate]

The most difficult part about software engineering and IRL engineering is the feeling of “everything’s broken always” and just constantly needing to fix or tweak things. I understand that’s the job description basically but nice to hear it articulated by someone else

[Aperocky]

This is why TDD exist, it doesn't necessarily improve the product or delivery speed, but it keeps you sane while the project is half baked.

I've found incorporating tests on my personal projects allow me to pick it up after even a year or two, but if I don't have tests, they inevitably become so jumbled that they cannot be salvaged once the initial effort is over.

[Nemrod67]

tests mostly work for technical code, it would be harder to pick up gameplay stuff.

Though that's why open betas exist I suppose, but for most studios that want to keep things under wraps, paying a lot of testers is extremely costly (and thus buggy releases).

[q-big]

> The most difficult part about software engineering and IRL engineering is the feeling of “everything’s broken always” and just constantly needing to fix or tweak things.

Who says that this feeling is not entirely correct and most of software development is insanely broken, i.e. software development as of today actually mostly means working around these insane problems such that not already a monkey that was conditioned using electrical shocks realizes how broken everything is.

[dieselgate]

Not sure I understand this comment very well but should have added it’s “the thing I personally find most difficult”. I was referring to “putting out fires” at work mostly, even with tests and other checks there are often regressions in a “large codebase” when working with a team of devs