September 2011 Archives

Helping you fish better!

Helping you fish better!

In one form or another, I’ve been a contractor for the vasty majority of my career: building other people’s software for them. Along the way, I have mentored developers, founded and continue to run a conference (now going into its fifth year) to enrich and educate both beginning developers and expert alike, have shared some of what I have learned along the way by speaking at user groups and conferences, and regularly pair with distant developers to both educate, share with, socialize, and learn from them (I wrote most of RubyPair as well).

This has led me to realize that I am happiest when I am helping eager developers improve their skills. Seeing the “eureka” moments can only be described as a rush!

A couple of months ago, I began setting aside at least 3 hours each week, when I’m not on travel, to remote pair or otherwise consult with other developers on Open Source. Again, that time is only for Open Source and not for commercial use. I’ve taught a lot. I’ve learned a few things. I’ve met some cool people who I wouldn’t have otherwise. It’s been a blast!

As the Chinese proverb goes:

Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.

That’s what I’d been doing. I simply had not put a label on it! The mentoring, the conference and user group presentations, the (not-so-) occasional rant about why people should be writing their tests first and then move on to evolve a Test Driven Development discipline: it has all been about trying to help other developers get better.

I’d blog but, while not a terrible writer, I don’t have the writing bug as much as some. But, man, do I ever love a good conversation or pairing session!

I want to touch and enrich lives. I want to help people fish, that is: write software, better!

What only occurred to me a month ago was that this mentoring fills a real need. I could make a living off of helping people have “eureka” moments!

And, so, for anyone who is looking to improve: this one’s for you.


Via Triple Dog Dare (I admit, I really need to update this page with more recent work but I’ve been too busy!!!), over the past several months, I have helped bootstrap one company from almost no Rails knowledge to a working application. For another client, I’ve provided occasional periodic one-on-one mentoring in building his web startup with Rails (shhhh….. it’s a secret for now!). For both, the majority of the collaboration has been online. Although, for the former client, I’ve occasional traveled out to San Fran to help them onsite. San Fran is just such a terrible town to visit, after all – and, yes, I’m kidding; San Fran is pretty awesome.

But, yes, most of the mentoring occurs online. Sometimes I’m answering questions via email, more often IM, doing a code review, or helping via VOIP or a remote pairing session.

And, let me tell you, remote pairing works pretty darn well. The technology is not only there but it’s been there for some time. Frankly, VOIP was the missing component for a long time. The other technologies involved are tried and true *NIX apps.

I’ll write about remote pairing in a later post. It’s been at the forefront of my mind a great deal lately.

If you or a team you work with is new to Rails and you believe you would benefit from someone to shepherd you through the learning process, drop me a line!

Posted by evan on Sep 23, 2011

The automated testing confessional

Hi, my name is Evan. And I don’t always start a new app by writing tests.

There, I said it! Crazy, right? Well, ok, maybe within our test-obsessed Ruby world.

As much as I promote automated testing and Test Driven Development, and you can call me a hypocrite, but I don’t always TDD or even test first. Sometimes I just want to write some %#@&ing code!

But here’s the catch: it almost always bites me in the ass later.

Take for example Ruby Pair. Ruby Pair is, currently, a humble little directory of people interested in pairing on Ruby, remotely or in-person, for fun or to work on open source.

Bad Evan! You only started writing tests a few weeks in!

Now that I’ve berated myself…

Ruby Pair hasn’t been my full time job; it’s been my hobby project for the past 3 weeks. When I’m working on a project for fun, or on my own dime, I’m more likely to try to see how far I can get without automated tests.

Why? Because I’m lazy, dammit!

The key is to be lazy in a good way.


So I have another confession: until I found Ruby, Perl was my favorite tool to avoid writing shell scripts. I deplore writing shell scripts. Sure, I live in the shell (zsh, thank you very much) on a daily basis but that doesn’t mean that I have to code for the shell using the shell!


Larry Wall, the author of Perl, talks about the “three great virtus of a programmer”. He lists laziness chiefly among them. When Larry says “laziness”, he means the kind of lazy where you’ll go to great lengths to avoid doing unecessary work later.

Sounds a little like automated testing, if you think about it.

When writing a new app, at first, it’s almost always easier for me to begin by just banging out code. How many times have you set up authentication in an application? Or created a User class or a users table? Pretty motherhood and apple pie, right?

So you’re writing your code, you think everything’s fine, everything’s good. Then the next thing you know, you’re on fire!

Ahem Ok, I mean “you discover that your code base is a flying spaghetti monster”.

My point is twofold:

  1. You don’t miss something until it’s no longer there. It is important and reasonable to sometimes avoid writing automated tests. Now don’t go and use that as an excuse to your momma if you get busted for it. Occasionally skipping your automated tests is a healthy way to develop an appreciation for them.

  2. Not every piece of code should necessarily be tested.


Well, not really…

Have you ever tested every path in your application? If you say “yes” then that application must have been no larger than a few methods.

Instead, we pick and choose what to test. We do it all of the time.

Typically, most of us write tests for the happy path. “What’s the happy path?”, I’m occasionally asked. It’s that magical case when all of your inputs are valid, all of your external dependencies are met, and so everything works as expected. Everything else is a “sad path” a.k.a. “degenerate” or “edge” case.

“What not to test” is a heuristic that varies from project to project. Personally, I decide what not to test based on the (1) risk and (2) impact of failure of the particular component/feature.

A couple of anncecdotal examples:

  • ALMOST ALWAYS TEST: Whenever I’m dealing with currencies, virtual or otherwise, I’m writing a test. Few things tick off a user faster than mishandling their money!
  • RARELY TEST: Authentication? Psh! I’ve set up Devise enough times. For the happy path, it’s easy!

If you’re not familiar with the basic ideas behind risk management (and you’re too lazy to follow that Wikipedia link), use this rule of thumb: just how confident are you that your code will work? How bad will it be if it doesn’t? Listen to your Jiminy Cricket.

To sum up: not TDDing or writing your tests first is a decision. If you’re going to make that decision, do it in an informed way. Occasionally, writing code without tests serves as a useful touchstone to remind us why we write tests and use TDD.

Posted by evan on Sep 04, 2011