Zero to One

What Do All Good Books Have In Common?

When it comes to my favorite technical books, I’ve found that they tend share a set of common traits. Here’s what comes to mind, in no particular order.

• facts
• patterns
• humor
• examples
• links to other resources
• recipes
• challenges
• stories

Thinking about what makes a good book is on my mind because I’ve convincing myself to write another book. It’s been four years since my first book was published. SInce then I’ve become a professional teacher and a better writer, so I think the time is right to take a stab at it again.

This time, the topic will be purely beginner-focused. With luck it will be published before 2013 comes to a close. Most importantly, it will contain all of the traits I’ve listed above.

I’ll be using this blog to expose my struggles and triumphs as I try to find the motivation and self-discipline to write, write consistently, and write well.

Hindsight

Agile teams are encouraged to follow a practice called the sprint retrospective (or iteration retrospective, depending on the vernacular chosen by the organization or team.)

Retrospectives are crucial to agile practitioners. A retrospective is typically a fairly short, time-boxed meeting of everyone involved on the agile team: developers, business stakeholders, technical writers, the project manager (or ScrumMaster), and anyone else who had a role to play in building the product during the most recent sprint.

Agile teams who aren’t consistent with retrospectives tend to fail faster than other teams, even other agile teams. Retrospectives ensure that everyone has a voice in steering the project toward improvement. Without retrospectives, those with larger personalities or higher titles will tend to dominate the decisions that affect the culture and success of future sprints.

Personal Retros

I’ve also applied to concept of a retrospective to other areas of my life as well.

When I teach programming classes, I include all of the students in class retrospectives. When I was still actively teaching 2- or 3-day workshops, I held a quick retrospective at the end of each day, asking the students what I could do to make the class better for them the next day. Now that I’m at Code Academy, we involve all of the students in a brief retrospective at the end of each week. Although I may not adopt every suggestion, I use retrospectives to help me shape the course as we proceed through the quarter, in an effort to make it the best possible experience for everyone.

I also use retrospectives in other areas of my professional life. Every September, I hold a “personal retrospective” with myself. I may not change jobs every September - I held my previous job for 5 years, and four years the job before that - but reflecting on the past, and getting the courage to make changes for the future, has been the best way for me to shape my career.

Try It

So I challenge you: have you tried a retrospective lately, on your team, at your company, with your book group, or even just by yourself on something important to you?

Just ask these four questions:

1. What can I start doing to make things better?
2. What can I stop doing to make things better?
3. What practices should I continue?
4. What “aha!” moments have I had since my last retrospective?

Just one answer to each question should help point the way to making life better.

Order Matters

I remember learning how to drive a car for the first time. My driving instructor put me behind the wheel, and asked me to pull out of the parking space and onto the street. Here’s what he told me to do:

1. Press the gas pedal with your right foot.
2. Turn the key until you hear the engine start.
3. Turn the wheel to the left.
4. Put the car in reverse.
5. Insert the key into the ignition.

No, wait… that’s not quite right.

Obviously these would be terrible directions! Any experienced driver can see that. But how about a new driver?

Can you remember the first day you got into the driver’s seat of a real car? Can you recall being given instructions from that well-known, experienced teacher sitting in the passenger seat next to you?

If you were given the instructions I have at the top of this article, what would you have done?

I think you would, in fact, have followed those crazy instructions! You would be taking it on faith that the instructor “knows what she is doing.”

Up until step #4, that is, which wouldn’t work at all (most cars these days require you to step on the brake in order to shift out of park). Only then would it become clear that these instructions were entirely in the wrong order.

When teaching beginners how to code, I face a very similar problem. Except that sequencing a web development course for true beginners is a whole lot harder than sequencing the instructions to get a car out of a parking space.

Most beginners have a hard time learning how to code because the teacher doesn’t know how to sequence their learning steps in the right order.

It’s one of the hardest parts of my job at Code Academy, and it’s also probably the part I’m most proud of. We continue to refine our sequencing every quarter, because it affects the success of our students probably more than anything else we do in the classroom.