Pairing on Everyday Tasks

Have you ever done yard work, cleaned your house or move some furniture by yourself and then all of a sudden someone joins in to help you? Don’t you just love that feeling? Now you know it won’t take as long, you get an extra boost of energy and the sum of your work will be greater than the individual parts.

As I’ve worked in Product and UX, I’ve found that pairing with another designer works on my productivity and thought process the same way it works when I’m developing software. I’m able to simply accomplish more work with another person than if we had both gone off for a couple days and had a meeting afterwards.

Now in some cases it won’t make sense, such as implementing a sketch in Photoshop won’t be as productive when both designers have similar skill sets but it’s definitely possible to pick up a few tricks from each other if you haven’t already established equilibrium. The same can be said for a couple developers wasting away on CSS tweaks for IE. It’s not going to be much more productive with two developers getting frustrated at IE than with one since the process for dealing with it can be mostly trial and error.

It would still be interesting to try pairing with traditional professions. For electricians and plumbers, the process of a journeyman but also having multiple professionals working on the same project is normal. It’s normal to see multiple technicians working on the same problem. But what about accounting? Or marketing?

Maybe I’ll find out one day. I’ll probably need to create a company first though.

Happy pairing!

The Open Source Promise

The recent fuss over Sparrow reminds me of something a friend was doing the other day on Pinterest. She was copying and pasting the images out of the site into a Word document. Mind you she hates Word. I told her she could pin it to her own board and her response was: “Why bother? They’ll just close the site down in a couple years and I’ll lose everything. This way, I know I’ll have it.”

Unfortunately this proposal doesn’t work for highly trafficked sites that require a team of dedicated engineers to keep it operating but it would work for Sparrow and a number of other useful applications that have disappeared.

The Open Source Promise.

The company promises that the product Foo will be open sourced should the company be acquired or shutdown and stop maintaining the product.

The benefits to the customer are obvious. We still get to use the software and help keep it going. The benefits to the company are numerous as well. It helps the company brand as their product gains popularity. It bolsters the parent company’s brand as they acquire their talent. There’s little need to worry about the brand since the company was going to kill it anyway but if lawyers are involved, it could easily be ripped out and left for the community to rebrand it as part of the transition plan.

I would love to see a variation of this license available online but we need baby steps.

So if you’re looking to quell some of our fears or shine a better light on your new corporate overlords, put up an Open Source Promise.

Pairing During the Interview

I found that sometimes even good developers lock up when given the “code on a whiteboard” option. It makes sense to do a basic FizzBuzz exercise or talk through an architecture design but writing outside of an editor is odd for anyone unless they’re a professional interviewee.

If possible, I jump into a pairing opportunity. A few hours or a day of pairing on something can show a lot of details.

  • How do they approach a code or design problem?
  • Do they TDD?
  • How quick are they to backtrack on a bad idea without investing too much time on it?
  • What tools are they already comfortable with or experienced with?

It’s always interesting to see someone’s desktop and their setup. Or to see first hand how they utilize their time.

Here’s my recommendation for technical interviews. At this point, they should have spoken to someone for at least 1 hour attempting to assess their technical capabilities but usually it’s 30 mins talking about your company and 30 mins talking about the candidate. Before interviewing, come up several applications to design. The ideas can be fun and interesting down to ETL and data scrubbing. For instance:

  • The Game of Life
  • A service to grab music artist information from 4 different APIs
  • Parsing some data from NYC Open Data

The long form technical interview will take 2-3 hours. Two people spend 30-45 mins each going over their own questions covering problem solving, language preferences, details on implementations in the past, thoughts on this or that, etc. Any or all of which could’ve been their co-worker’s work or their mentor’s preferences. Then ask them to sketch out, on paper or just out-loud, a solution to one of the problems from above.

In the last hour, you then ask them to build one of the solutions. By this time, they have already walked through two of the designs. They don’t have to finish, they just have to start and show off enough. This is where pairing comes into play. Work the problem with them. Let them drive and do most of the work, nudge them when needed. You’ll be a poor pair partner this way but at least you’ll be there to answer questions without letting the candidate spin. Which is one of the essential benefits to pairing. Another key insight will be in how they work the problem, discuss the design and implement the code.

Another technique I encourage is to setup the candidate as a contractor for 8 hours (1099). If they can take an entire day off of their current job to be your pair partner, great. If they can’t, how does 2 hours every night during the week or 4 hours over two days? If you’re going to be sitting next to this person for years to come, you should at least date a little before getting hitched.

Earlier →