Mike's Blabberings » productivity

Go fast!

Mike — Tue, 10 Aug 2010 21:22:49 +0000

I was reading Kill Zone by Gunnery Sgt. Jack Coughlin, and was struck by the personal mantra of one of the Marine snipers:

Slow is smooth, smooth is fast.

Even though lives are not usually on the line, it’s important in the software industry to understand that sometimes we shouldn’t rush around like chickens with our heads cut off. During your project’s crunch time, this is most important.

Slow down, take a breather, and think before you slam in a bunch of crap code. All the technical debt you create has to be accounted for by someone. Be the rabbit, not the hare.

Rally pairing

Mike — Mon, 10 May 2010 19:50:00 +0000

Iwein Fuld posted a great article about different styles of pair programming. It’s a great post, and I encourage you to read it if you’ve tried pairing but haven’t bought in yet. His rally car analogy is spot-on.

My favorite driver is an outspoken dutch guy. He’s quick on the wheel and if he doesn’t get the idea I’m trying to convey to him he’ll just type something to try if that works. When he does get what I’m mumbling it’s on the screen faster than when I would have typed it myself, so it doesn’t give me time to get frustrated over things not being like the would be when I had the keyboard. And that gives me time to look for exits and pittfalls.

He also dismisses anyone that tries to say pairing isn’t as effective as coding solo.

No you’re not faster on your own, you’re just creating more crap for your colleagues to puzzle over and eventually delete. The code you write alone sucks. That guy that is getting on your nerves is trying to tell you (clumsily) that your code sucks, try to listen to him and you’ll turn into a better programmer. Or maybe you can teach him something and he’ll stop getting on your nerves. … If you’re slowing the other guy down, that’s a good thing. That will prevent him from writing code that you cannot maintain. If you don’t feel worthy of your colleagues code, get over it, or get off the team.

My biggest stumbling block to date has been the ratio of time driving to navigating when you’re pairing a senior and junior dev. Trying to balance productivity and mentoring isn’t always easy. I find allowing the Sr. dev to drive 2/3 of the time and Jr. dev to drive 1/3 strikes close to the optimal balance. Any more driving for the Sr and you’ll lose the Jr entirely as he rides along for the tour. Any less and you lose valuable time in guiding-by-doing.

Whether you’re the driver or navigator, take your role seriously. Share in the responsibility and help foster a mutual respect for the other.

My Resolutions for 2009…

Mike — Thu, 08 Jan 2009 14:59:57 +0000

Going against a prior thought I had, in which I told myself to make a single important resolution and stick to it for the year, my 2009 resolution is to make a new habit each month and stick to it for 30 days. After reading Leo’s The Power of Less, I was inspired to do such.

Rules:

Habit shall be something simple I would like to improve about myself.
I will list the habit here on this blog, making myself accountable to the interwebs.
Progress shall be trackable and measured daily.
Results will be posted.

For January, I will change my sleeping behavior in order to wake up earlier each workday. Through most of 2008, I found myself not awaking until nearly 8am on weekdays, missing out on a great part of the day. I will strive to awake before 7am each day, giving me time to relax and have a cup of coffee prior to starting my commute. Today was my first day, and it was with only a minor struggle that I managed to pull myself out of bed at 6:54, after snoozing my alarm only once!