The flip side of course is the overwhelming amount of material to absorb.
I'm not sure that is true. It depends a great deal on your learning style and your previous programming experience.
I can't be the first one catching the train late, so to those who did: what was your strategy?
Initially I am spent *more* time per episode, not less. I set up local git with a branch that follows the dayNNN tagging pattern, and other branches for other things. I'm also doing SDL in parallel to Win32 (which I build against WINE, mostly) and keeping everything in Pure C11, so I'm going over the code at least twice. I'll be getting an X11/XCB and Wayland platform layer working soon, too.
That said, some days are more work than others. Sometimes there isn't enough new material in one session to take me a whole day. You can push through stuff you find easy faster that stuff that you don't understand. The key point is recognizing which stuff you don't understand, and marking it so, and taking extra time to practice and review that material specifically.
CAVEAT: I am a professional Systems Engineer in a DevOps Agile environment. Adsorping large amounts of technical matter all the time is my bread and butter. If you are super new to programming and technical work, expect your mileage to vary. DON'T diversify your focus to include anything more that you can comfortably manage, eg. Don't work on multiple platform layers simultaneously ;)
First and foremost, get visibility of the code. And I don't just mean that you have to pre-order the game (although that is necessarily true as well). What I've done is put the private github repo on my workstation so I can diff the files between commits as I work to see what's changed. Most of the time, the concepts are *superbly* obvious just by reading diffs. If you want a really pretty visual tool for that, try gitlab or gogs.
Secondly, I play the corresponding video in the background while I work. If something cool is happening, I stop and watch. I use the annotated bookmarks on the Handmade Nework portal to jump around to parts where I need clarification on Casey's code. I push hard to get the code I have typed by hand functionally equivalent to Casey's by reading git diffs *before* I worry about parts that I might not understand 100%. Either I jump to the part of the video where he was doing that code, or I just mark it for later study. Since I am also transliterating C++ to C, and Win32 APIs to SDL/Linux APIs, its more productive for me not to follow Casey's material in a strictly linear fashion.
Thirdly, with a good healthy repo built up to a decent temporary platform layer, I can get through 2-3 or more episodes of material per hour instead of one. Even before that, I got through the entire week of Platform-independent * in a couple of hours or so.
Lastly, once you are moving at pace, take some time off from breaking new ground and debug. I found lots of bugs in my Win32 layer, because I was paying way more attention to the SDL layer. They weren't big deals, but it was bad enough that code that compiled and executed on Windows, SIGSEGV'd for WINE compilations. (Running a WINE compilation isn't a bad idea to catch that stuff, too ;).