3 lines of code shouldn't take all day

On the other hand, at least it's a motivator to look at the build pipeline every once in a while and see if there's anything that can be improved.

That said, working in a typed language with good IDE support definitely helps build up the confidence that things will work as intended before you hit compile.

It's hard to do unit tests in a large part of the area of gamedev. How do you ensure that a picture is rendered correctly? You can take a screenshot and compare it to a stored one. But then what happens if you do artistic changes that you want to do? You have to update the stored screenshots of the testsuite. Who will review that the changes all made sense? And more importantly, there might be slight differences in the output of GPUs, depending on driver versions, model, etc.

So let's say you have a bug in your game where if you walk through a level in a specific direction, the game crashes. The error is easy to check for: just make sure that there is no crash. But how do you create a reproduction of the bug? You could record controller inputs and play them back. Then a different department changes something how quickly players move and increase their walking speed by 10%. Suddenly your player walks into a wall and the test is basically broken.

Compare this to a CRUD app where you have well defined operations and their impact is well described.

That being said, even in gamedev there are areas that are well testable. You can do a unit test of the low level networking layer by trying to make a server and a client, dropping some packets, then looking if the packets still arrived because the networking layer sent them again.

As a more general thing: you can learn a lot by removing tools that you usually use from your toolbox. For example, going from a managed language to manual memory management. Going from an IDE to shell commands. Removing tools like language servers. Each time I did one of those things, I learned a lot. However, there are lots of things to learn and I don't know if this was the "most effective use of my time".

Another example of hard to balance learning: I'm currently working for a company. Should I focus my learning on their business and our codebase, or on general technology? General technology is a transferrable skill, and I'm scared of being "trapped" in a company if I focus on their specific parts too much. But on the other hand, companies want to recruit efficient people, and I think focusing on the business and our codebase would make me more efficient.

I'm a junior engineer, so maybe that's due to a lack of experience. If anyone has insights to share about that, I'd love to hear them.

…I just googled for “React TDD” and the top no-money result suggests finding divs in containers and spying on dom changes. It’s like testing your cli app by hooking into tty driver’s section in /dev/mem.