Category: Computing

September 1st, 2013

Some Lessons Learned from Pair Programming (Part 1)

There are many simple ways improve my programming!

That was the biggest thing I have learned from my pair programming efforts so far. The more useful things I need to pay attention to:

  • Be more careful with my git commits — I can learn to rebase before committing so my commits tell a coherent story.
  • Listen to my gut more — Several things I felt “iffy” about also concerned my partner. I should speak up more during coding rather than skate over things, for example names I think are not quite right.
  • Pairing up takes energy and focus — It’s rewarding too. I have to have mental energy and focus, otherwise I’m wasting my partner’s time if I am not participating fully.

The incidental benefits were great too. We explored more options than I would have done by myself. We learned about more than just the problem we were solving. It was good to have someone to celebrate the successes with, as well as another pair of eyes to give a better perspective on the things which didn’t work out.

So far pairing seems to have amply rewarded my investment in time.

August 31st, 2013

Adventures in Pair Programming (Part 5)

At the August Toronto Perl Mongers meeting I gave a “brief” presentation of my experiences of pair programming. Fortunately some of my pair mates were in the audience, as were some Perl programmers with challenging questions, and they improved the presentation’s value to me.

As I have yet to succeed at getting pairing accepted at #{work}, I had become pretty despondent about ever getting to do any pair programming. Luckily for me, Avdi Grimm started publicising and I reasoned that if I cared about trying pairing seriously I might as well do it for myself, and the past few weeks have been enlightening.

Doing the presentation the the Perl programmers this month served as a useful retrospective. Some of the points raised were:

  • Enhanced discipline — As an example: both pair members admitted that it was hard to stick to TDD individually, but when in a pair it was possible and seen to be beneficial.
  • Willingness to try different approaches — If we had a couple of different ideas it was easier in a pair situation to try them all, and learn from those which didn’t work out so well as well as those which seemed to work.
  • The code, and any metaphors being used were discussed — this improved all kinds of things: code complexity, naming of things, conceptual coherence, and more.
  • Time management (pomodoro) led to frequent “mini-retrospectives” — this was unexpected. When the timer went off it seemed natural to discuss what had just happened in a broader context, reflecting on the way we were working rather than what we were doing.
  • Time management helped us remember to switch roles — This made sure one person didn’t accidentally hog the keyboard by making sure we tracked time and were interrupted.

There were some good skeptical questions asked too, about pair programming and extreme programming. Their essences included:

  • Isn’t this just a fad?
  • What if my personality type isn’t suited to pair programming?
  • Isn’t relying on communication flowing through a chain of pairing sessions dangerously like a game of Chinese whispers?
  • Didn’t the project where XP emerged end in failure?
  • Don’t we still need comprehensive and accurate documentation of some elements of a project to be developed?

I had a great time presenting it, and appreciated the audience participation. Some of the questions made me look at my assumptions and prejudices.

A PDF copy of my slides is available here: TPM Adventures in Pair Programming 2013 08 29. There are some links in there which are good starting points for exploration.

August 24th, 2013

Adventures in Pair Programming (Part 4)

Another beautiful Saturday in Toronto, and another chance to do a good couple of sessions with Stuart Watt. This week there was a good mixture of programming in Ruby (a language I know and love), programming in Elixir (a language which has piqued my interest), exploring a few tools, and reviewing my presentation for the Toronto Perl Mongers‘ meeting this Thursday.

The Ruby was just a few odds and ends, renaming, refactoring dense methods, and doing things I probably would never have done had I been working alone. I was also helped by 8th Color‘s reviewing service — though that meant I pushed to the branch way too often just to see what would happen. All in all it was a good experience, knowing my partner would be checking that I had made the changes as agreed made me more careful. These changes were to code I wrote solo after last week’s session — they probably wouldn’t have been needed if we were pairing when I was writing the code.

The Elixir was a case of starting to pick things up — Stuart has some functional experience so he was able to point me in a reasonable direction. Here pairing was doing knowledge transfer and helping avoid rat-holes. It seemed important to step away from time to time and chat about other things in the world to let my subconscious process what I was doing.

The tool I experimented with today was Atlassian‘s SourceTree which is a graphical git (and mercurial) client with built in support for git flow. Seems nice, although I couldn’t find a way to get nice diffs for all the files in a commit in one pane — but I can use github for that.

Having a partner look over my presentation was useful, I think the presentation will be better for it!

Best of all we headed out to Merryberry for some lunch. The food is always great there, and it was a beautiful day to walk out past Riverdale Farm to get some lunch.

August 17th, 2013

Adventures in Pair Programming (Part 3)

Time is passing, and my pair programming presentation at the Toronto Perl Mongers is looming. So it’s time to do some more preparation…

Today I had a friend over to try some pair programming. I wanted to attack a simple problem so we could focus on the mechanics of pair programming without being too distracted by the problem itself. Some of the things I wanted to try included:

  • One keyboard / screen / mouse.
  • Pomodoro time management so we made sure we swapped rôles.
  • A real attempt to do Test Driven Design, where we let the error messages guide us and didn’t let the temptation to code wildly seduce us.
  • A real attempt at the red / green / refactor cycle, so we could make it work and then make it right.

The experience was positive. Very positive! As I work as part of a dispersed team it was a delight for coding to become a fun, social activity.

I didn’t quite succeed at the one keyboard / screen / mouse — we used a laptop with an external display, and a USB keyboard and mouse. For most of the time we were doing pair programming, and occasionally the “non-driver” would use the other keyboard to look something up. For the bulk of the time both of our attention was on the shared screen.

The Pomodoro time management worked well, a chance to get up and walk around, get away from the computer and let our subconscious minds kick in worked. We used the interruption to change rôles, and we were pretty good at stopping when the timer went off — if a test was failing then it would remind us where to pick up (particularly after lunch at the House on Parliament).

TDD worked well, we did discuss things a couple of steps into the future and yet managed to focus on failing tests and doing one step at a time. This lead to discussions about possible ways to continue and every error seemed to open up possibilities rather than be a blocker. It was reassuring to do things in small steps because we were never far from a working state. Several names got changed as we discussed what was being written, and saw how the tests communicated (or failed to communicate) the intent of the code we were testing.

The red / green / refactor cycle was useful because it reduced distraction. We could make it work and then rearrange code in the refactor phase. This was the first time I had had a partner to do refactoring with, and the discussions about where stuff belonged and what it should be called were fun and useful.

There were other benefits too. We shared information about tools which we had used, when I couldn’t explain Ruby namespacing then I realised I had to do some learning myself. “Failing” in this environment was a learning opportunity.

In conclusion… What a great day. Good research for my talk, good progress on a project, and a very satisfying day. Thanks to Stuart Watt, my partner in pairing!

Background: The problem is how to iterate over an IO stream which contains a tar file in an idiomatic Ruby way. This will fix a problem at #{work}, but I’d like to enjoy it so I’ll do it on my own time. If you care, the work is on GitHub.

August 2nd, 2013

Adventures in Pair Programming (Part 2)

A few days ago I had my first remote pair programming experience which got some real work done. Dave Doyle had set up the Toronto Perl Mongers meetup group, and we thought it might be good to deal with at least one issue with our web site.

One tool which I first heard about on the Wide Teams podcast was Screenhero. I had had a couple of opportunities to use it at work for code reviewing, and this was the first time I was going to try real development.

Using Screenhero was a real pleasure, the fans on my MacBook Pro sometimes leaped into high gear, but the performance of sharing multiple windows in both directions while having a Skype video chat running was never a problem. There were a few times when the remoteness of the other machine intruded, but it was a very natural feeling experience. We could talk and gesture with our mouses (micen?), roll our eyes or give thumbs-up, and Screenhero didn’t get in the way of solving the problem. We tried a few things, explored some dead-ends, and came to a conclusion quite easily.

Definitely a positive experience.

July 28th, 2013

No Adventures in Pair Programming (yet…)

Both pair programming partners have yet to pair with me. I have learned a few things getting my infrastructure set up, and I’m getting impatient to try it!

July 20th, 2013

Adventures in Pair Programming (Part 1)

Recent lifestyle changes have left me with more energy and desire to learn, so I am looking into doing some remote pairing with some friends in the city. I expect that working with people I already have a relationship with will help get the kinks out of my setup, and then I can look to people further afield.

One thing I think I’ll miss is the food and beer afterwards, but that might be an advantage from the perspective of my wife and my doctor!

The current plan is to get a droplet or two at Digital Ocean – they have SSDs and per hour pricing – and maybe do some pairing as I work through Michael Hartl‘s Rails tutorial.

This has a couple of benefits for me:

  • My progress on the Rails tutorial is open to others, and that helps keep me honest
  • I have an excuse to start exploring Vagrant and Puppet in my own world as ways to build and provision machines

For now I have some simple scripts at which I use to build a VPS. There are lots of routes open to improve them, and I want to get the pair programming experience first before burning hours on perfecting a useless system.

July 14th, 2013

The Joy of Concrete Automation

In the Pragmatic Programmer the section on Ubiquitous Automation starts with this quote:

Civilization advances by extending the number of important operations we can perform without thinking.

  • Alfred North Whitehead

I understand the reasons why automation is an essential aid to software development, yet there’s a part of me which likes the familiarity and order of going through a well rehearsed set of physical actions which rely more on muscle memory than though.

Recently I read David SparksPaperless, and soon after that I surveyed some of the piles of paper in the basement. Thinking “I’ll give it a go…” I armed myself with a Fujitsu ScanSnap and a copy of Hazel. After a few minutes I had things set up so with one push on the scanner’s blue button a bank statement would be slurped in, Hazel would read the OCRd PDF and find the statement’s end date, and file it away in the right directory (backed up by time machine and BackBlaze).

This is automation which I get – there is a physical pleasure in the feeding of the paper, pressing the button, and watching the computer do its stuff. The computer handles the tedious stuff, and I indulge in pleasant rhythmic work which achieves an end I care about.

Once I have worked through the physical backlog I get to set up rules to file my electronically delivered statements in the same folders, again using Hazel to watch my download folder for interesting documents.

Out of a couple of hundred documents I have scanned so far I have had to manually intervene for less than a dozen, usually the statement had been creased through the date so the OCR hadn’t picked it up. I am pleasantly surprised by the ScanSnap’s speed and accuracy.

A part of me would love to feel the same pleasure from developing automation at work, the rational part of me says to be happy with what I have!

July 7th, 2013

Vagrant: Up and Running – a review

Vagrant: Up and Running is a relatively new book from the reliable O’Reilly stable. The author of the book and creator of Vagrant, Mitchell Hashimoto, says: “Vagrant is a tool for building complete development environments, sandboxed in a virtual machine.”

This is a short and dense book. It can be read “cover to cover” to get a good overview of the whys, hows, and details of Vagrant; it can be used as a reference – although you should keep an eye on the source as Vagrant’s a living project.

For me the book provides a solid foundation for day to day use of Vagrant, with plenty of guidance for getting into more advanced usage. Automation is encouraged by Vagrant’s workflows, and Vagrant plays well with Chef and Puppet to provision systems. There are no obvious gaps in the book from my perspective, it covers a lot of ground in a relatively slim volume (196 pages on my iPad, 156 pages in paper according to O’Reilly).

To me the big benefit of Vagrant is that you can provide a project with a base box and a Vagrantfile, and any contributor will be able to quickly and easily bring up a standard environment in which to develop and test. This can eliminate any number of “…but it works on my system!” type problems.

The book explicitly states The Tao of Vagrant which essentially means that developers and systems operations engineers are all able to use identically built systems in VMs while still able to use their favourite tools and workflows on their development hosts. These systems are easy and quick to mint. The book works its way from simple set-ups to more complicated examples using multiple virtual machines networked together. By the end of the book you have been exposed to Vagrant plugins, and you will most likely have enough of its concepts under your belt to navigate the source (even if you’re not yet familiar with Ruby).

There is some repetition in the book which makes it easier to use as reference, but seems a little odd when reading it end to end. As there’s no filler in the book this is not an issue in my eyes.

If you need to distribute environments which can be run inside virtual machines to developers, testers, or deployers then Vagrant is a tool worth a long hard look, and Vagrant: Up and Running is a great kickstart and reference guide.

July 7th, 2013

Discipline (is a Vehicle for Joy)

My revisiting Ruby and Rails is moving ahead well, each week day I spend an hour or so to do a couple of Vitamin R sessions to work through Michael Hartl’s Rails Tutorial. Progress is good, and the content seems to be sticking.

The difference in approach this time to my last attempt is that I do it first thing in the morning, getting up an hour earlier to make myself some time, and I don’t do anything before it except make a cup of coffee. This means I don’t get distracted by news, email, software updates, and all those other things which can sap energy, and I have some focus. This is a qualitatively different experience to trying to squeeze in an hour at the end of the day, at the end of the day I’m tired and work’s irritations and frustrations have clouded my mind, and I don’t have that much focus available for tasks regardless of their fun or interest.

A side benefit is that it is re-energizing me to review books, and work through some of the more interesting looking ones because I have a sense of progress from my hour’s disciplined work in the morning.

The books I’m looking at now are the Ruby Rogues‘ next book club book – Understanding Computation, and Avdi Grimm‘s Much Ado About Naught.