he/him but also any
Recovering software developer, computers resenter
I like playing the bass guitar, painting, and some other things I’m not very good at
Mastodon @sjolsen@tech.lgbt
RDR2 suffers heavily from the same problem as GTAV’s single player mode: it’s a movie posing as a video game and both aspects suffer for it.
RDR2 would have been great if it was just the part where you wander around tracking critters and collecting flowers and playing cowboy dress-up, but the game really doesn’t want you to do that. Not to belabor the point, but between how unpredictable the connection between “interact with item/character X” and “start mission with character Y” can be and the game’s tendency to fail missions the second you go off-script, RDR2 often felt like it was directed by someone who actively resented the concept of player agency.
At my last job, doing firmware for datacenter devices, almost never. JTAG debugging can be useful if you can figure out how to reproduce the problem on the bench, but (a) it’s really only useful if the relevant question is “what is the state of the system” and (b) it often isn’t possible outside of the lab. My experience with firmware is that most bugs end up being solved by poring over the code or datasheets/errata and having a good long think (which is exactly as effective as it sounds – one of the reasons I left that job). The cases I’ve encountered where a debugger would be genuinely useful are almost always more practically served by printf debugging.
Profilers aren’t really a thing when you have kilobytes of RAM. It can be done but you’re building all the infrastructure by hand (the same is true of debugger support for things like threads). Just like printf debugging, it’s generally more practical to instrument the interesting bits manually.