In The Checklist Manifesto by Atul Gawande, he gives advice on how to design a checklist. The main problem? It's buried within the text. So I took the liberty of creating a checklist of my own. Ah, so meta.
The first thing you have to decide is what the trigger will be for you to consult your checklist. Where you put it depends on whether you have a Do-Confirm checklist or a Read-Do checklist
"When surgeons make sure to wash their hands or talk to everyone on the team, they improve their outcomes with no increase in skill. That's what we're doing when we use the checklist." (emphasis mine)
Shanna Mann is kind of geeky about creating SOPs and checklists. She writes at Change Catalyst, and teaches clients to design systems from which to trust their instincts. No, the two are not mutually exclusive.
Yeah - 'memory-based' checklists - I find that the very act of writing it down, plus the process of making what I'm writing make sense, imprints things pretty solidly (unless it's something that I have a BigBlock against doing anyway.)
Thanks, Shanna, for your "Around the Web" pointer, or I'd never have found this!
I think Gawande would probably say that you need to break the process into segments. His examples in surgery seem to indicate they pause for the checklist at least a few times.
For my own process, (geek warning) I have a binder of SOPs which is basically a record of the systems I've taken the time to optimize. It's heavy and unwieldy and isn't used often, but I find the practice of recording and refining the system largely internalizes it. I imagine someday when I get a VA it will be worth its weight in gold, though.
The binder is supplemented by checklists on Post-its or short-cuts in my desk top. (I favor do-confirm checklists.)
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
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.