Conscious Coding Practice: The Three Concrete Steps, by Noah Gibbs
Track: Learning Ruby
Abstract
You feel guilty about not knowing enough "Computer Science." But that isn't what you're still missing in your coding. If you could just pick up any problem and solve it, you wouldn't care if you used a formal-sounding algorithm to do it.
There's a way to get that "fingertip feel" for coding. And it comes from mindful, conscious practice.
Sounds abstract, doesn't it? Instead, it's very simple, specific and concrete. We'll go over the basic steps, the pitfalls, and how to do it. It works whether you're a beginner or an expert. You'll be able to create coding studies for yourself, not just find other people's exercises that are already worked out for you.
This talk is in Ruby. But the technique works with any language, library or paradigm. It's also good for pairing.
Details
There are many existing exercises for programming. This talk will present an unusual kind of coding study that consists of three parts: tool, task and purpose.
"Tool" just means your language and/or libraries. "Task" is the specific thing you're doing, such as a simulation, a small library or a mini-application. And "purpose" is what you hope to learn from the coding study. We'll talk about how to choose your task and purpose for the maximum rate of learning.
There are also guidelines to make sure you learn the most from each coding study:
- Choose your tool, task and purpose deliberately, first. Write them out explicitly, in words.
- Pick a time limit. If it's not done by then, quit.
- When you're done, throw it away.
- Study one idea at once.
- Start simple and build in layers.
- Look at a physical thing in the real world; being surprised by complexity is the whole purpose here
- Break rules.
You don't have to perfectly follow each guideline on every coding study (break rules!) But we'll talk briefly about what tends to go wrong if you ignore each guideline.
Picking tools is usually easy. Following guidelines is (mostly) usually easy. But we'll talk in more detail about how to pick tasks and purposes. We'll also give quick examples of using the "Life Study" method that visual artists use to pick their artistic subjects and purposes - it adapts quite simply to software. Just as visual artists can look around and then make a visual rendering, we can look around and make a system of behavior inspired by life.
The pairing guidelines will be presented very briefly, just a few words:
- Pair on defining the task and purpose, not just writing the code
- Start "flat-footed," don't bring in a fully-developed idea
- Brainstorm together before typing
- One person on the keyboard at once
- Do something small; then swap roles and continue or restart
Here's a rough breakdown of the talk time and topics:
- Intro; mindful practice is good; where common exercises fall short (5 min)
- The three parts of a coding study: tool, task, purpose (3 min)
- How you choose your task and purpose (7 min)
- An example coding study: kids on a merry-go-round (7 min)
- A different purpose for exactly the same tool and task, merry-go-round redux (3 min)
- Seven guidelines for studies (10 min)
- Guidelines for pair life studies (2 min)
- Q&A if there's any time available; URLs for followup resources on-screen
The intended audience is both newer programmers who worry about feeling "not good enough," and more experienced programmers who feel stuck in their current practice.
After the talk, audience members will have a specific method to quickly create and self-administer programming studies to help them advance rapidly in their craft. These instructions work well solo or can be used in pairs (or potentially more.) There will be a link to the slides, and URLs with more in-depth instructions.
(Examples may change as I refine the talk; I have some good ones, but I may find better.)
Pitch
I've been programming for around 30 years now, and I've always had an interest in teaching coding and in individual study and practice. Some of these are general good guidelines. Other parts really solidified when I started to learn drawing and found out more about how visual artists practice - a lot of their methods are surprisingly applicable to programming. And of course, the notion of "deliberate practice" has both a long history and some popularity in recent books.
This year I've been developing more specific guidelines for these coding studies, first on my own and then by pairing with friends. I think I have a solid, useful set of instructions that other people can use after seeing a couple of examples. I intend to continue developing these techniques, both before and after RubyConf.