I've only watched a few full episodes, mostly the earlier ones. I don't have the patience nor time to sit through even a quarter of them :P, but I do like watching Casey do his thing. What really intrigues me is that he seems like he's always in the zone, programming away at an incredible rate. There are about 350 episodes out now where he programs for about an hour, meaning all the work he has done is about 2 months of full time work whilst explaining everything along the way... from scratch.

I had long felt I used to be more productive in the past, but until Handemade Hero came along I had never given it a second thought. I wrote a journal about it and decided to start an experiment where I radically change the way I program in C++. My experiment is still ongoing and I've written about 4-5K LOC and have learned a great deal. Most importantly:

• Being able to assume all zero is initial state is very powerful.
• Hot-loading code is not only a powerful tool, it makes programming a lot more fun.
• Not having generic containers available like vector or list is really not a big deal, or small deal for that matter.
• Full rebuilds within a few seconds, sweet heavens. I hope it stays like this as the project grows.

It also seems like my code is easier to adapt and less rigid. I'm trying to think of some major cons but I can't think of any at this point in time. There is a bit more typing involved, but I'm okay with that as that's hardly ever a bottleneck in productivity.

But then I've always fundamentally disagreed with some of Casey Muratori's ideas, such as his 'immediate mode GUI' which I consider an abomination.

In use or writing such a system?

What really intrigues me is that he seems like he's always in the zone, programming away at an incredible rate.

That's exactly what I don't like. What you call "programming away", I call "improvising". While I find it cool that someone is doing such a series (and from having watched a few random episodes after hearing about it for the first time here, it seems like it is really complete, leaving out nothing), I personally dislike the attitude of doing something and not being ready or having tested. I'm the "do it properly" or "don't the fuck do it at all" type (but yeah, different people will think differently).

As an example: "Today, I'll show you how to analyze your code with IACA. Huh, this doesn't work. Huh, it still doesn't work, I don't know why it doesn't compile. Right, now it works, so let's see... we have this, uh, lotsa output. Honestly, I can't tell you right now what this means or what that means because I'm using this for the first time, but uh... well I guess here this means...". Things like this are of the kind that makes me shout at my monitor: "Well thank you for wasting 15 minutes of my life!!!". That's maybe somewhat unfair, especially since he is putting these videos on the web for free, but it's like I feel. My time is not free either, you know. Watching something for 15 minutes only to learn that the guy who made the video recorded it unprepared simply annoys me. Yes, "cowboy style" is hip, but I'm not a hipster. I'm old fashioned. Means if you hold a lecture and it turns out you didn't prepare for it, then well, prepare for the audience throwing things at you. :lol:

Wait that sounds a lot similar... i am nearly in the same situation.

We're not alone, I've heard others say this as well :).

I personally dislike the attitude of doing something and not being ready or having tested. I'm the "do it properly" or "don't the fuck do it at all" type (but yeah, different people will think differently).

Being burnt by bad decisions in the past, at some point in my programming career I was trying to fully design everything before I wrote a line of code, in the hopes to avoid it in the future. Once I started thinking of a problem my brain would branch off into a gazillion possible scenarios where things could go wrong and what would be the right way to do things. I'd be proud of having thought of problems before I ever ran into them, but I'd also get these moments of not knowing what the hell to do because I just couldn't handle all the complexity that goes into games. Almost as if my brain ran into a deadlock, and I'd feel less motivated to work on the project. In the end, I keep making the wrong decisions and having to rewrite code anyways.

You might go and say well you didn't design it well enough then, but I'm starting to believe you can't, or not without paying a price for it. Doing it "properly" is to me, reaching your goal in the fastest way possible. If writing code and then refactoring it a few times gets my game done with the goals I had in mind faster than spending time designing all of it and writing it only once then I'd choose that. Now this isn't as binary as I make it out to be, some things require no thought and others require more, but I see nothing wrong with putting your thoughts on 'paper' by programming whatever comes to mind initially and then refining that.

Like samoth say i have not the time to sit and wait for someone writing code and trying out things. And like Icebone1000 i prefer short and to the point articles on specific subject instead of watching someone slowly getting somewhere.

The idea of the series is that you get to see the entire process, what problems you run into, how to tackle them etc. It's mostly aimed at beginners and not meant to be a dense information source. So yeah, this is not really for experienced programmers, but there are some nice takeaways.

I would love a blog format instead, it's so much better for learning code, I only have to scroll up or down, follow a link to the particular underlying function's documentation, etc. Video blows for that kind of thing, I hate having to play back a part over and over to get at the information I want.

That said, I actually enjoyed watching him flail a bit in the one video I recall I watched. You get to see his actual process, and how he goes about solving problems when he runs into unexpected blockers, like odd compile errors. Makes him seem human, and I think it's important, especially for new programmers to see how to solve problems like that when they come across them.

...

...

Wait, wait, that's not exactly what I'm saying (although I am indeed preferring to plan before coding, too... 30 minutes thinking can save you 8 hours of swearing -- just don't spend all week on planning and not writing one line of code).

What I'm saying is that if you hold a lecture or publish a how-to which others will be watching/reading (and investing, or wasting their time on) then you should -- in my opinion -- at the very least have tried what you're going to show before you do the recording, and have a good plan, and some preparation done. That is, no such thing as "uh, I'm doing this for the first time, you know", or "uh, I don't know why this doesn't work right now".

For example this guy here made some really stunning videos on procedural cave generation. You can instantly tell that he spent some valuable time on making the videos. For example, when explaining marching squares in part 2, he isn't doing some improvised scribbling in GIMP. Sure, it's cool if you just scribble down something barely readable on the fly, proves that you are really a total pro. Except you have to assume that the people who are listening and watching are maybe a little less awesome, and not quite at your level, or else they likely wouldn't be watching! Now compare that to the live demonstration with clickable nodes that Lague has prepared to explain what's going on, and which he blends in in the corner while coding so the (not so super experienced) audience knows what's going on. Fucking awesome.

Yes, he, too, is coding live during the video, but he is not improvising. Yes, he makes one or two mistakes (and once he has the algo fail deliberately, only to say: You will notice that... we will fix this in the next episode by...). But this is not about pointing fingers at someone for making a mistake. Mistakes are fine, anyone who ever had to hold a lecture knows how much of a fool you feel in that situation and how easy it is to make a mistake -- only giving the impression of being unprepared and dabbling for 10 minutes trying to figure something out which you could avoid if you had spent 10 minutes before recording the video is not fine in my opinion.

But again, that's just me. I'm not "cool". I remember there was a lecture at CPPCon where the source code examples were basically unreadable, both because of the font being way too small (for no good reason, 2/3 of the screen being empty) and a syntax coloring scheme being used that made all keywords more or less unreadable. The audience took it with humour, but... tell you what, this is the kind of mistake that could have been avoided by spending 30 seconds looking at the presentation once before holding it.

This is what people were drilled for in the good old times when "lecture" still meant showing diafilm slides. You had better made sure you grabbed the correct box and that they were complete and in-order, or your boss would fry your ass.

I skipped a lot of episodes. I'm mostly interested in his audio stuff because documenting DirectSound is extremely helpful! He briefly covered metaprogramming via parsing, I thought that was super cool. But he didn't go into depth and only mentioned that he has personal tools to the Nth generation. Too bad, really wanted to see them.