December Update

I haven't been doing much on the game this month. I have rethought the puzzles an looking for the next steps to take in the game design. This will also inform where the programming will go from here: what needs to be developed, expanded upon and simplified.

In the mean time here is some stuff I wrote after watching the interview with Mike Acton and Casey at Handmade Con 2015


The Practice of Programming
In an interview by Mike Acton about programming and engine development, Mike said that practice was the thing he wished programmers did more of. That just 30 minutes a day spent implementing an idea from scratch or researching a topic was beneficial for the development of the programmer.

He was adamant that the practice session should be completely new each time, and not taking off from an existing project. By doing this you allow the brain to come up with different solutions to the same problem and stretches the brain in how it conceptualises a topic. For example if I used the same win32 platform layer for every game, I would never rethink the problems posed by the platform layer, and never confront some concepts I may have not fully grasped the first time in doing the layer.

Mike said he would go as far as throwing away the practice you do each day; the benefit being gained not from the text written, but how the brain reorganised its structure in writing that text. Casey, the interviewer then asked about simple projects like an asteroid game, and how this relates to practice. The answer was that as long as you started the asteroids project from scratch each session, it was still a valid practice session.

The reason why these should be differentiated could be in that if I start a project from scratch each time, the productivity to time ratio is much greater than for a continuing project. This is because you may have a system in place that cues you to think in a certain direction, or that the system allows you to free ride concepts you may have not fully understood. For example say we are implementing a profiler. In this system there is a number of tables that get filled out with performance data which gets buffered up, than you process that data into a more beneficial format. However after you write the system, you will piggy back on what you have already written in future revisions and won’t have to confront the original problem in its entirety again.

Mike also said the craft of programming should be very little about typing code, going as far as to say that 99% of the programmer’s job is not writing text. It’s much deeper than this; it’s about researching, thinking about new solutions to old or new problems, understanding a system.

Mike also said what he doesn’t look for in a programmer. He doesn’t look at what school they went to, their grades, what assignments they completed. Mike even downplayed the role of projects. Curiosity was the most important attribute he looked for in someone. If they had an insatiable desire to learn about an idea and they displayed that, either personally like asking large amounts of questions or through the projects they had completed, this was a good marker for curiosity.

For example seeing a blog post about shadow mapping and really digging into the details of shadow mapping: reading research papers, implementing test programs, posting improvements they found etc.