Saturday, September 5, 2009

97 Things Every Programmer Should Know

This past week 97 Things Every Programmer Should Know was made available to the public. This project was driven by Kevlin Henney, who I know from the early Pattern Languages of Programming conferences, . The list of contributors contains many familiar names, and I'm honored to be among them.

My contributions are about the agility, deployment, and their intersection. They include:
This project has contributions from many really interesting and insightful people. Maybe you already know everything on the lists, but you might get a fresh perspective by reading the contributions. You are very likely to start thinking.

On a related note, this past week, there was a conversation in my office between one of my colleagues who is a parent of a toddler, and one who isn't about why one works so hard to sound excited when talking to children about tasks.

You might say in an excited tone:
"Let's brush our teeth! It will be fun!"
instead of
"You need to brush your teeth because it's good for you..."

Being the proud (some who know me IRL might say too proud) parent of a 2-year, 9-month old boy, this got me thinking about why parents do this, and why it works so well. I suspect that the reasons are two-fold:
  • Toddlers don't (yet) get the idea of consequences, but they get the idea of "fun" so framing something as fun and exciting is just the path of least resistance.
  • Toddlers are wired to explore and learn, and every new thing is fun!
I'm realizing that, while as professionals, we need to do things for purely practical reasons learning about how to work better can (and perhaps should) be fun too. Seeing how toddlers learn makes me wonder how much of that joy of discovery we give up as we grow, and whether we need to lose it.

So as you read through the contributions in 97 Things, try to find something new and learn about it not just because it's something you should know, but because you enjoy programming, and because learning new things is fun!

1 comment:

Steven Howard said...

This book is generally a selection of articles by a wide range of experienced developers who are each providing their individual perspective on the subject of what all developers should know. The value of the outcome is combined. Some of the articles will probably be reasoning and arguing for thoughts that you hadn't really regarded, while others are probably elements that every slightly qualified designer already knows.

A Contract for One on One Meetings

One on One meetings between a manager and the people being managed are an useful tool for effective management. While “good” one-on-ones ca...