Closet Coder

I work in my closet. I code. Yep.

Pairing Post Mortem - @thecommongeek - Learning and Mentoring

| Comments

I had a great pairing session with @thecommongeek tonight. It was my first live-remote pair programming and I wanted to to a little “post mortem” on it to record my thoughts.

We spent some time on introductions and then jumped into a problem. Since my box was all set up, I typed. I’m more experienced than Dennis as a coder, so I viewed it as the potential to mentor him a bit. I also learned from him both in the “how to be a better mentor” department and the “how to pair better” department.

First off, the good:

  • As has been stated before, Google+ Hangouts are awesome. Low setup, easy to communicate and “meet” the people you’re pairing with.
  • ScreenHero is great software. It seemed like it was super easy for Dennis to control my box when needed. Loved it. No problems with setup.
  • Dennis is a great guy and I had a pleasure getting to hear about his journey becoming a coder. I hope the session was an encouragement to him!

The ‘could have gone better’:

  • If you’re ever the more experienced coder, let the less experienced coder do the typing, even if you’re dictating nearly every word. I got to the point that I was typing AND talking without much feedback towards the end. That’s when I knew it was time to wrap up the session and do things a little differently next time.
  • Pick a problem that you’re both somewhat familiar with – We picked Conway’s Game of Life even though neither of us had much experience or knowledge of it. It went well enough at the beginning, but it seemed like lack of understanding the basic rules made it difficult to visualize what the problem was we were trying to solve. A good portion of the evening was just figuring out how Conway’s Game of Life worked and what the nuances were. If you’re trying to get better at your craft, pick a domain you both have some knowledge of, even if it’s “create a blog app.”

Next time we’re going to let Dennis get his machine set up and drive most of the typing. I think this will help quite a bit. I also think having some knowledge of Conway’s Game of Life might make it easier to talk about the next time. I’m looking forward to our next session in 2 weeks!

Ping Pong Pairing Without Screen Sharing

| Comments

I often have a bit of time that I could spend on other tasks, but couldn’t set up a true share-and-pair session due to logistics and communication issues. A friend of mine suggested that we “pair” over github. I took the idea to the next level by creating a true ping-pong pairing project where each commit is a ping or a pong.

Here’s the basic setup:

  1. Create a README with the full description of the “task” at hand
  2. Create a github repo and add your ‘pair’ as a collaborator.
  3. Write a failing spec
  4. git commit and git push

Then, each individual takes turns doing the following:

  1. Get a tweet/alert/message/email… whatever… from your pair
  2. git pull
  3. Run the specs and see the failing one
  4. Write code until it passes
  5. Write a spec that fails based on the README
  6. git commit and git push
  7. Tweet/alert/message/email your pair (maybe github notifications will work?)

Basic benefits are : Zero setup, no need to learn other editor, a full commit history for every single step, no need to coordinate schedules.

Clear drawbacks are : No immediate guidance, less pushing out of comfort zone, less intensity, slower

It’s not the same as pairing since you’re not letting the discussion and 2 sets of eyeballs help, but it’s a lot like the mute pairing session Corey Haines talks about at Code Retreats. I’m interested to see where it will go. Maybe it could even go towards a “round robin” implementation? (i.e 3 or more collaborators?). Check out our little experiment on GitHub to see how it goes.

Pushing Past Programmer's Block

| Comments

As coders, we’re often given tasks to do. These tasks can sometimes overwhelm even the best of us. How many times have you stared at a problem and when you finally sat down to attack it, you spent a quarter of the time you expected to on it. If only you hadn’t spent 3 hours playing Angry Birds.

There are lots of things you can do to “hack” your productivity, but most of them are focused on helping you keep track of tasks instead of motivating you to get going.

Here’s a list of things I’ve done to get past the “block”. Most are not mutually exclusive and can be combined as needed:

1. Time Chunks (specifically The Pomodoro Technique)

Set a timer for 25 minutes and work for the entire duration on one task. Your goal is not to finish but simply to continue to focus on the single task you chose for the whole time. Not having something you “must” accomplish is a big motivator for some since it takes the pressure off.

2. Hardest Thing First

Get up early in the morning and pick the thing you dread and work on it for some period of time (Maybe 2-4 pomodoros?). Eat the frog.

3. Structured Procrastination (a.k.a. Mark Forrester’s Final Version)

Contrary to the last item, start at the top of your list, put a “.” next to that item. Then go down your list and put a “.” next to every item you’d rather be working on. Start from the bottom and go back up your list, doing each item you marked. Once you’ve gotten back to the top of the list and done the first item, lather, rinse and repeat.

4. Pairing

Nothing like an extra pair of eyes on your screen to keep you in check and on task. There are many other benefits to pairing, but you can gain motivation and accountability quickly by just calling a collegue over for 15 minutes to start work on a problem.

5. Change your work schedule/location

Work off hours for a bit, starting at night and reserving your day for meetings only. It gives you quiet, focused time to move on an item. Spend time at a different location in your office, at a coffee shop or at home. Sometimes just the act of changing things up is motivating.

6. Spend a limited amount of time specifically goofing off

If you are struggling to get anything done, sometimes the best thing to do is goof off. Set a timer for 15 minutes and do whatever you want for that amount of time. Play on Facebook, argue on Twitter, watch cat videos… whatever. Just goof off. When the timer is up, pick the first thing on your list and go to it.

ToDo Lists and Bug Trackers

| Comments

I love GTD. I love making lists and having things to do. I love having a system. That also makes me love bug trackers when I’m on a team. I love having everything listed in one place. I love letting it be the communication point for a team to get things done. Bug Trackers and To Do lists are great.

They just don’t seem to work very well together most of the time.

When you have a ToDo list, it is almost, by nature, a personal, single-person list. You might have one you share with your family, but in general there are things that YOU have to get done and there’s a way YOU caputure things from your brain. Everybody’s list looks different. They’re allowed to. They are there to do a job that is really meant to help you.

A Bug tracker, on the other hand, is a communication tool. It’s meant for a team. It’s meant, even, for people outside the team to a degree. To let people know the status of a given defect or feature. To let people see the state of a project where there are many collaborators. You have to agree on HOW you’re oing to communicate between each other. You have to agree on what style of tracker you’re going to use and what way you’re going to use it.

And somewhere between those two worlds, there are things that just don’t work well.

I’ve seen “collaborative ToDo lists” like WunderList Pro, Kickoff, and Producteev, but they miss the mark on both counts. I can tell you that I don’t think there will ever be a good way to make a single app that does both.

But here’s how see them sort-of working together:

  1. You can capture a task to create a bug or feature (Push to tracker)
  2. You can convert a bug or feature to a personal task. (Pull from tracker)
  3. Don’t put a bug in your task list (see #1)
  4. Don’t put a task in your bug tracker… just in your task list.
  5. Bug Tracker issues have the final say in what’s on your plate for a given project, so pull from them at the beginning of the day, and possibly other times throughout the day.
  6. Personal task lists have the final say for what’s on your plate at a given moment, so dump into them frequenly and only grab tasks that are ACTUALLY listed on your task list. If it’s not there, either add it, or ask why it’s not there.

It would be great if there was some kind of agreed upon protocol that might sit in the middle and talk to some of these bug trackers so that it was simple to “promote” or “pull”. Hmm. I see an idea brewing.


| Comments

I always find it interesting to place artificial constraints on myself. I don’t think it’s the constraint itself that is good as much as what it shows me about myself or what I do. I read an article on Rands in Repose a few years ago that talked about giving up your mouse for Photoshop. The idea isn’t to rid yourself of the mouse entirely. The idea is to make you aware of when you depend on the mouse.

What I’ve found is that moving to VIM / tmux has made me less dependent on the mouse altogether, which makes me want to make more small hacks to make it easier to do without the mouse. I even saw that Corey Haines suggests no mouse as an exercise for Pairing. Yet again, it’s not about becoming independent of the mouse, it’s about showing you how you ARE dependent on it so you can begin to control it.

Mouse movements reduce speed most of the time (though not all the time). It’s good to use a mouse when gaming or when browsing some websites, but being able to navigate without a mouse is usually much faster (if periodically mentally taxing).

Here’s the exercise:

  • Take your mouse batteries out
  • Begin doing your work
  • When you notice that you’ve reached for the mouse, take note
  • Try to figure out how to perform your task WITHOUT the mouse
  • Spend a few times practicing doing the task without a mouse
  • Note it down so you can evaluate if it really is speedier later

There are several things that can really help with this. Here’s my set of tools and hints for getting through the Exercise:

  • Alfred is a good way to get around the mouse in a lot of situations that you want to use it.
  • On OS X, you can press CMD-? (CMD-SHIFT-/) and you’ll bring up your help search for a given application. Type in a menu command and it will be highlighted, complete with the keyboard shortcut if it exists)
  • If your menu item doesn’t have a keyboard shortcut, you can specify application specific shortcuts in the Keyboard preferences
  • Tab after typing in a Google Search will start cycling you through search result links. Enter takes you to them.
  • If you’re a developer, learn VIM

There are probably various analogous helpers and tips for other OSes, but I can’t test them now, so you’ll have to Google it yourself

Tic Tac Toe TDD

| Comments

I spent a little (longer than I thought… maybe 2 hours?) implementing Tic-Tac-Toe in the TDD As If You Mean It style. Ended up with a VERY different implementation than I ever would have done if I just “started coding” – everything was only in one class, including the AI to “play” against itself.


  • It was quite different to implement things inside the test method. I ended up coding like
it "does something..." do
  player =

  def player.something
    # do work

  player.something.should be_true
  • It was difficult to not refactor as I went. Many times I would see the duplication and want to refactor immediately. I resisted this urge until I felt the implementation was done, then refactored out duplication, ensuring that the tests continued to pass after each change.
  • I’m still not quite sure how you’re supposed to improve design without breaking the rules. Doing pure method move seems limiting and doesn’t allow for you to see duplication. The only thing I could think of is that there can be additional refactoring after you’re “done”

All in all, a very interesting exercise. I want to do it now on something broader, and eventually on something that has a core with a wrapper so that the core is purely TDD’d and the wrapper is thin, but swappable. I think Dominion is my next big attempt.

TDD and Pairing Ideas

| Comments

When pairing, especially remotely with someone you don’t work professionally with, it is sometimes helpful to have some ideas about how to go about getting the session going or what to do. This is just a set of ideas that might get the ball rolling.

Problems to work on

  • PuzzleNode - 15 shortish (30 minutes to 4 hour) problems. Great for pairing.
  • Conway’s Game of Life - Can implement a basic version quickly. Lots of ideas for restrictions on this site.
  • TDD Katas - Can be done in 30 minutes alone.
  • Dominion - A larger problem, but it will tease out larger design issues that you don’t get with smaller systems.
  • Build a Twitter - Simple system that can be extended. Adding a UI and continuing strict TDD is very interesting since you might be able to TDD the core system, but have more difficulty with the surrounding. Are there ways to mitigate the risks of using a framework as a shell? Are there ways to make the shell “swappable” – not so you’d actually swap, but so you have loose coupling?

Ideas to practice

  • Ping Pong - Pair back and forth, one writes a failing test, one makes it pass, then writes the next failing test, and so on.
  • Various Limitations - No loops, no conditionals, limit lines per method, no voice communication (or typing out in chat… only communication is through code)
  • TDD As If You Mean It - Strict TDD that involves real tests before code and strict refactoring rules. This can be combined with any other limitation or idea, but it’s so difficult (And rewarding) that it’s okay to Just Do This.


Pairing as a Life Habit

| Comments

I’m interested in creating a culture of pairing… not just in my workplace, but in my life. I want to be able to pair with people in order to improve on the skills I alread have. This is seen clearly in the relatively new #pairwithme ‘micro-movement’ that is happening on twitter. It shows that people want to learn from each other and improve their craft.

But it doesn’t have to apply solely to programming. Last weekend I “paired” with a neighbor to fix my lawnmower. He is a bit more mechanically inclined than I was, but it took both of our efforts and problem solving to diagnose and fix the problem. All in all, a worthwhile time where I improved both my relationship with Ben and my ability to cut my grass. He got something out of it too, he felt great and is excited to tackle more mechanical projects. This is exactly the same reasons we talk about the benefits pairing in the first place.

It makes me wonder how we can do this in other areas of our lives. Maybe it doesn’t look quite as analogous as fixing a mower does to solving a puzzlenode problem, but could it look like something? What if we “paired” with our spouse to work through a problem we’re having with our kids? What would that actually look like? It seems like now it looks like a lot of yelling and saying “you don’t understand me” – maybe it could look different. Maybe it could look like sitting down, trying to define the problem (‘I feel like Josh is out of control’, ‘Our kids watch too much TV’, ‘It seems like Karen is having trouble listening’) and then talk through possible ways to address it. I think the key here is that it doesn’t have to be a fix. There is not One Right Answer, but simply a way to attack the problem. Isn’t that what pairing is anyway? Sometimes you don’t get to the end of a problem when you pair, but sometimes you do. It’s much more about helping each other move forward in attacking it.

All that to say, I intend to begin looking for ways to pair in my life, including my professional life, by setting aside time to do so. For my programming, that means 9-10 CDT on Monday, Tuesday and Wednesday nights. There will be exceptions, but that’s my goal for the next month. I’d like to see my TDD improve, as well as my ability to work alongside others.

See you on!

Using VIM Fulltime

| Comments

I’ve used various IDEs for the last 10 years of development. Started with Eclipse while developing in Java. Switched to TextMate when I moved to a Mac and started developing in Ruby. Eventually, TextMate’s development became stale and things other people were able to do with their editors started to look good. I began searching, and even bought a license for Sublime Text 2. It had a lot of what I was looking for, but what I wanted was an editor that let me never leave my keyboard unless I wanted to and had good integration points. I’d love a good fullscreen mode since I’m a bit of a FullScreen addict on Mac.

Turns out, there’s no such editor.

There’s one that can come close, though; the editor I’ve used for little tasks for over 15 years… VIM.

Just a Text Editor?

VIM isn’t just a text editor. I’ve used it since my sophmore year in college to handle little tasks on servers since it’s ubiquitous and powerful enough. I know my way around without the arrow keys, and how to insert, etc, but I’d never really used Visual mode or tried to handle anything more than one file at a time.

There were a handful of commands, .vimrc configurations, and plugins that helped me get past all that.

Commands I already knew

  1. i/I/a/A - enter insert
  2. o/O - enter insert mode on line below/above
  3. p/P - paste deleted/yanked text on line below/above
  4. Y - Yank the currently selected line(s)
  5. / - search file
  6. :## - go to line
  7. :wq - write and quit
  8. d - delete, dd - delete row. d3 - delete 3 rows
  9. jklh - directions without using arrows. Awesome.

Favorite New Commands

  1. V - Visual Mode

    The VISUAL mode is something I’d seen a lot, but hadn’t really understood. Now it’s invaluable.

  2. Ctrl-V - Vertical Splits

    Vertical splits were something I always wanted, but never quite understood. I ended up with them randomly and then would :q vim to get out. Now I know and master them.

  3. :bd - Delete Buffer

    Delete the current buffer. This lets you close a file quickly.

  4. Ctrl-ww - Change Windows

    Quickly change from one split to another.

  5. :e <file> - create a new file

    Lets me create a new file without leaving vim

  6. :!<command> - execute a shell command and then return.

    Useful for rake tasks, git pushes, etc.

  7. W, w, B, and b - word navigation

    Forward and backward one word or one “programming” word. Can also be combined with d to delete words, etc.


In my .vimrc, I did a handful of things that were helpful to me that I’d never done before:

  1. Turned on the 80 column highlight
  2. Turned on syntax highlighting
  3. Turned on autoindent and :ack
  4. Mapped my LEADER key to ‘,’
  5. Automatically stripped trailing whitespace on save.
  6. And provided a crude tab-complete

Useful Plugins

  1. Pathogen

    A plugin to manage plugins. Makes it easy as long as you have a git repo to clone.

  2. Command-T

    Lets me use <leader>-T to do what I’d do in TextMate/Sublime to find a file in the project

  3. NerdTree

    I needed it at first, but now, not as much. Good to have for periodic filesystem navigation

  4. Fugitive

    A good git plugin that provides the :Gstatus command, which let me quickly stage/unstage files, see diffs, and blame

  5. Ack

    Lets me search the whole project quickly and navigate the results. This was the final “missing piece” to get off of Sublime/TextMate. I would always go back becuase I didn’t want to use a goofy RegEx to do very basic searching in my project–luckily Ack and ack.vim provide it quickly and with great result navigation

Taking the plunge

Ultimately, the things that really helped me were getting to know a few basic commands, installing Command-T and Ack, and tweaking with my VIMRC. I’ve been using VIM for years and never really got it until the last month. Over the last 2 weeks, I’ve actually made it my primary editor and only brought up SublimeText 2 once. Now, all I have to load up to get started is iTerm + vi. Guard runs in a separate pane and everything else can be done from inside VI.

Now I have a long way to go before I become a VIM ninja, but this is what got me started. Maybe it will help you too.

Spec Run Snapshot--for Nostalgia

| Comments

I thought it would be interesting to take a snapshot of a full, timed spec run every month or so and post it. Who knows, sometime I might look at this and think “13.7 seconds! THAT’S FOREVER” – Or I might look at it and say “13.7 seconds! I Wish!”

I also have been pushing to improve the coverage by 1% ever 2-3 days (That’s roughly 10-20 additional covered lines). My goal is to get to 85% and stop. Lots of stuff doesn’t need to be tested and lots of stuff is “covered” but not actually tested properly. Testing is hard.

time be rspec spec --tag ~slow
Run options: exclude {:slow=>true}

Finished in 4.61 seconds
187 examples, 0 failures
Coverage report generated for RSpec to /Users/marksim/dev/reqhub/reqhub/coverage. 1082 / 1502 LOC (72.04%) covered.

real     0m13.772s