Friday, November 06, 2009

In my dating life I have been trying to pay attention to what I can do to find and meet women who are really attractive to me. One piece of advice that I came across was that keeping notes on the conversations you have is a really good way to diagnose your weaknesses, especially when you share your notes with a coach. My project lineoftheday is designed for exactly this process, and I have really high hopes for it's potential to help people improve their conversation skills.

Even if you're not delivering handwritten notes, one principal reason having a coach is helpful is because you have someone you have to tell if you don't practice your skills. Being accountable to someone you trust is a powerful motivator for almost anyone. In my youth I felt guilty telling my piano teacher that I hadn't practiced. She encouraged me to diligently write down my minutes every day, not do it from memory later in the week. She was showing me how to manage my guilt, by allowing my accountability to release the pressure on me to make decisions.

Being accountable at work is an area I've had to explore because I've worked in a few situations where my managers weren't especially proficient at evaluating what I was doing, and I wasn't always interested in taking the time to translate it into their terms. I have tried out a couple different approaches for bridging the gap, and I'm definitely starting to think that there are some good ones out there.

Github provides a simple way to view the chronology of my work, although the timestamps aren't very precise in the commit history view. Pivotal Tracker also keeps timestamps for when you start, update and finish stories. And you can use pickler to synchronize your tracker stories with the passage of your cucumber tests. Using a similar tool to synchronize tracker stories with rspec examples would be great, but I'm thinking about taking it one step further, and using the spec log to analyze every time the spec is run, not just the first time it passes.

Apart from making you accountable, the other primary reason that having a coach accelerates your progress is that he has been there before and he knows what you can do to address your mistakes. He's probably seen it a few times before in other guys as well, and seen what eventually enabled them to get around it.

If you shared every attempt you made to get the spec to pass, a coach would be able to point out which approaches were more reliable for the future, or explain what was missing in your earlier attempts. And simply by being exposed to the problems you're trying to solve he would be able to recommend alternative approaches you may not have known about. It would be like watching instant replay of you writing the code.

Git definitely provides the technology for making instant replay possible. Integrating it with spec runners that run specs on every save, or those that run individual specs or groups, would be the pivotal step in making coders accountable to their coaches. Now that github is so fast, it might be the preferred method of reviewing the code, but others could definitely be devised that focused on the individual histories of specs.

Accountability to your business associates could also be generated by the timestamps and metrics of your journey. In a normal workday you might only commit code five or ten times, and there's no evidence that you weren't on youtube for an hour in between. But you probably save a file every thirty seconds. And maybe you always get your specs passing within three tries. After running the repo and spec data through algorithms that make graphs of it, these strengths could be visible to your managers at a level of detail that would make you very much accountable for the quality and consistency of your effort. To measure the effectiveness of it, instant replay mode for Pivotal Tracker could be implemented, perhaps via the api.

I learned recently that watching yourself on video is such an effective means of correcting mistakes that sometimes you don't have to do anything at all to unlearn them. Simply having seen it once is enough.

Viewing your own replays could give the same results. Being accountable to yourself and others helps you work smarter because there are manufactured consequences for writing lazy code. And being able to see new patterns can help steer you in a direction of not even having to write much code. But it's something you have to see many times before you can write it sometimes. Your brain is always busy learning patterns that it doesn't tell you about.

When a famous coder publishes changes to a library he knows that they're going to be read over by lots of people, so his accountability is in place. When a famous pickup artist talks to girls in front of a camera, or just a microphone, he knows people are going to listen. And in both cases, part of how he got so good was by establishing that accountability so that he had to be good. You can establish it faster if you use artificial tools to manufacture it, simply by layering abstractions on top of it. I know this approach seems frivolous to some purists but to me it's just observing and regarding the natural phenomena that motivate people to act.

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home