Hi,

I am amazed at how much work has been put by Casey and others into producing this documentary. The flip side of course is the overwhelming amount of material to absorb.

I'm working full time, so I could probably watch an episode a day after work on most days, but it would still take me over a year to get to where the project is today.

I can't be the first one catching the train late, so to those who did: what was your strategy? Did you skip some episodes? Did you grind through the episodes at 2x?

Also related, how much time do people spend outside of the video to implement what was discussed? Or am I missing the point and it's more about watching and learning from Casey rather than re-implementing that day's code?

I watch at 2x speed, and implement concurrently, pausing as needed. Which happens much less than you might think. Remember that doing is the most important part.

Binging on the weekends can help speed through.

Also, don't be afraid of watching live.

Browse the Github page, and watch the videos that motivate the sections that need explanation.

There's no awards for rushing, so I learn at a normal pace.

I started on the streams a couple of months ago and manage about one episode a day. I don't think it would be sustainable to aim for any more than that, considering work and my own project (to which I apply HMH knowledge).

Following Casey as he codes and ensuring that I understand why things are done, it usually takes me a good couple of hours to get through a full episode. I make regular use of the pause and rewind YouTube keyboard shortcuts too. I don't spend any time outside of that on HMH, unless there are bugs that aren't occurring on the stream that need fixing --- instead I toy with the ideas presented in the stream within my own project which is growing in a similar fashion to HMH.

I find that some parts of some of the episodes can be watched while doing something else, but other parts require full attention and repeated watching to really understand. Personally I don't think there's any real advantage in pushing for a watching rate that is unsustainable, especially if it is detrimental to the knowledge and technique actually gained.

Having said that, it's frustrating when there's something that I want to implement in my own project that hasn't yet been covered in the stream, such as SSE, which is almost 100 episodes away. Probably a good indication I need to watch more :)

Hi afeb,

I've just started coding along with the series.
I've documented my "process" on http://lclhstr.com/dpp/hh/

I'm using the preordered code - downloaded the github repo (which can be "rewinded" to any day you want).
For these initial episodes it takes 10-20 minutes per episode (after watching it) to hand-update the code (and I'm sloooow, because I'm also fighting the editor). I imagine in the later episodes, where there are more files and more serious changes, that timespan might double.

However, I'm having a lot of fun doing it.

Nothing really because it's a awesome learning experience for me and in order for me to learn personally I must not only follow the episode but also try it some of the stuff on my own which takes up time.

afeb
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.

afeb
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 ;)

My suggestions:

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 ;).

Skimming this thread I don't see any mention to the episode guide. Maybe at this point everybody knows about it (after all, it's on the header of this site!), but I'm leaving the link anyways because what's a book without an index.

Also, to anyone reading this thread, consider backing the guide's Patreon. Annotating Casey's streams is a ton of work (three hours per episode at least, unless it's a very blackboardy episode*) and it wouldn't exist as we now it without Miblo's unfaltering dedication to it.

* (fun fact: time-wise speaking, miblo is the greatest contributor to handmade hero, the second being casey)

Aww… thank you, Miguel! You were a great colleague and inspiration yourself. I gotta confess, though, I don't spend as much time doing them as you give me credit for. I've been monitoring my time pretty closely of late because I'm now also working for Sean on OBBG annotations, and they tend to take me closer to 1.15 × video length (often less, but occasionally more).

Well, I was speaking from personal experience there and I'm glad to hear that it doesn't take you so long. I should have guessed that after so many episodes under you belt you have a more refined method than I had and improved tools also. At a 1.15 multiplier per episode I guess my "fun fact" does no longer hold true, but I still wholeheartedly recommend everyone to contribute a few bucks a month to help you keep the guide up to date.

Ah, yes. I still remember the time when 2× was the fastest I could possibly imagine doing it.