Read Next

Guest Post: "Want to be a hero? Start systematizing."

You Wanna be a Hero? Grow a Set and Systemize

by Shanna Mann

“We don't like checklists. They can be painstaking. They're not much fun. But I don't think the issue here is mere laziness. There's something deeper, more visceral going on, when people walk away not only from savign lives, but making money. It somehow feels beneath us to use a checklist, an embarrassment. It runs counter to deeply held beliefs about how the truly great among us – those we aspire to be-- handle situations of high stakes and complexity. The truly great are daring. They improvise. They do not follow checklists.

“Maybe our idea of heroism needs updating.”

Atul Gawande, The Checklist Manifesto

Programming: System Planning on Paper and Dealing with Interruptions

On The Best of Sett

It's been a while since I wrote a blog post. Don't get me wrong, I've been devlogging and making videos for my current game-in-development, Code Name: King Randall's Party. OK, not so much of a code name as the games actual name, but I gotta make efforts to be super cool like the big boys, right? Anyway, today I wanted to write about the power of making checklists when programming. 

I read a lot of articles about how programmers need a lot of uninterrupted quiet time in order to get their work done; after all, it's hard to keep the scope of what you are trying to do in your head if you keep getting interrupted. However, that's not always a possibility. I currently live at home with my folks while I develop this game, and my room is on the first floor with doors that open to both the house entrance and the back hallway. Suffice to say, I get a lot of traffic. Also, since they are helping me out with rent, I like to help out around the house, and want to encourage my folks to ask me to help with stuff, when reasonable. But that means I'm going to get interrupted more often than I would typically like. So I formally gave up trying to keep a problems scope in my head all at once, and instead keep it in a notepad. What does that really mean though?

Well, whenever I face a tough challenge I write down a design for the system on a notepad. What do I want it to do and what I want it to do. Then I start writing down a technical design which includes a list of all classes and methods and how it is going to affect and/or interface with them. Of course, I don't get it all in one go, but I find that it's easy enough to add to this list as I develop. Having it all written down has some other benefits too: I have a checklist for what needs to be done, and clearer vision of exactly how the feature will fit into the program. Whenever I use this method, I inevitably get the system completed faster and with better quality than if I had just jumped straight into programming. 

This kind of protocol is unnecessary for smaller tasks, obviously, but I usually do it anyway. You never know when something you thought was going to be simple ends up being obnoxiously complicated in ways you couldn't have predicted until you sat down and detailed it out. 

When you are about to program a system, how do YOU go about planning it? Or do you not? I'm interested in hearing about what works for others. 

Rendering New Theme...