That's the exact point of HM. Abstractions come from the knowledge gained after wrestling with problems, not as a form of premature optimization.

And this is especially true in games because you need to get all abstractions right otherwise the game will be limited and/or not performant enough.

In many other programming fields you don't get punished for adding a few abstractions that are not strictly necessary, so usually other programmers are used to abstracting things away fairly early (eg in OOP: properties vs public variables, ...) because they're free as long as you don't overuse them.

Also you should keep in mind that the stream is educational so Casey sometimes takes the scenic route before getting to the point, and he's both implementing the engine and designing it, so sometimes he doesn't know yet what he wants exactly.

I'd say you're right if we'd talk about a junior dev, but not when talking about a seasoned senior.

this isn't really an issue of "junior" or "senior".

I've watched roughly 90% of the series to date and I'm happy to report that this "jumping around in a bunch of files trying to figure out what memory write caused an issue at run-time" is infrequent, at best. Occasionally there's a gnarly wild-ponter-esque bug that takes an hour, and very occasionally two, to debug, but the vast majority of the time on the series is spent writing new code and refactoring old systems that need to use some new feature.

I actually find it amazing that sometimes 400 hours of programming and 2 years later he goes back to code written in the first few weeks and is fairly easily able to modify it to work with a new system that's just been implemented.

EDIT: Formatting

This is not uncommon in game development. Jonathan Blow and others have spoken at length about why game development is different than web development or other types of software engineering (not in a condescending way but in a "it's different, here's why" way):

- https://www.youtube.com/watch?v=JjDsP5n2kSM

In order to really start talking about it, we'd need to see someone writing something of similar complexity and longevity live in the same amount of time, and see whether they've spent less time to get to the same place.

With the same restrictions of course - relatively little dynamic memory allocation, and hitting frame rate consistently on the lowest supported platform.

The entire point is to show him code an entire game in C from scratch without using libraries, for educational reasons. Given that, what would you like to change and why?

If you writing complex code, you are going to be having bugs, abstractions or not.

C certainly isn't the language where one expects to encounter deep abstractions, is it?

I've gone through the first 20 and don't think you are accurately characterizing them. Maybe 2 or 3 of them involved significant time hunting down a bug.

You would likely still encounter bugs while building the abstractions to not have bugs. It might be neat if you could pick out a particular example and show how your approach would have avoided the problem or be quicker though.

So? Watching most folks code is the most boring thing ever. Very few people are entertaining to watch. Abstractions get in the way when one is hacking.