Squirrels Should Not Code

Today, I saw many fat squirrels in High Park eating and hoarding nuts for the winter. This behaviour runs deep for this furry animal and I believe it runs deep in us as well. It’s built into our genes and it made sense for our caveman ancestors to have this mentality. It helped them to hedge against long periods where they couldn’t find food. They over ate and hoarded just in case they couldn’t find other food sources.

Fast forward to now. I think we carry this trait into our coding practices. In this context, the behaviour causes more problems than good. The code we write every day is stuffed with “just in case” scenarios. This means we write extra features into the application that may or may not be needed. They obscure the meat of the solution, they introduce more bugs, they make maintenance a nightmare and so forth.  How do we stop it?

Pair programming. When I add the  “just in case” code, my pair will snap me out of my caveman thoughts and get me back to thinking about coding what it’s needed. With enough practise, we can change and we can be less influenced by our caveman thoughts. Just in case, we need to do more pair programming.


Was It Okay? Did You Like What I Did? Huh?

Remember in school, there was a guy who always looked for feedback for everything he did? He checked in to make sure it was cool with the group. If the group liked his action, he did it more and, if not, he tried something else. I found him annoying. I always thought the rebels were cool.

But I’m wondering if this feedback-seeking personality is actually good in the context of Agile? From pair programming, TDD, continuous integration, stand ups, sprints, retrospectives and so forth, Agile philosophy is built on communication and feedback. That guy would be a natural in this environment. He would be a role model. As for the rebel dude, he would be working at KFC making double downs.

What do you think?


Pair Book Editing Between a Beginner and an Expert

Late last night I paired with Shawn on editing her upcoming book, Help Me, Asia. She was driving and I was navigating. Actually, I was sitting beside her to support her. I don’t know anything about book editing. She is the expert and I’m the beginner. I wasn’t sure how much value I could add, but at the end of the session, we were both glad that we paired to edit her book.

Observed Benefits:

  • By being there, I helped her focus and increased her energy level. Before, she was tired and unmotivated to edit.
  • I was a sounding board for her. Just the act of her asking me questions, helped her find solutions.
  • I learned how she edits a book (I could use some of her techniques in my writing).
  • The experience of having a common purpose and, together, we worked through it. It made us feel more connected and we had a lot fun.

I wonder how much greater companies could be, if pairing was the norm for creative and problem-solving work?