Somehow, I ended up on this mailing list about leadership.  The articles–put together by a local company–focused on teaching leadership and team building, and I always looked forward to reading them.

Last September, I took a few minutes to write the author and company owner.  I told him that I enjoyed the articles, and said I had considered signing up for his seminars. I concluded my email:

“As a reader of many business books (Good to Great, Breakthrough Companies, Small Giants), I can appreciate your references to Polaris and themes aimed at helping businesses grow.  Just my applause for a job well done.”

Guess what his response was?

Nothing.

Two months went by before another article appeared in my inbox from the author.  At the conclusion of the article, he suggested that readers share their ideas and feedback.  In fact, he welcomed it, he said.

Ah, he did, huh?

So, I wrote him again expressing my thoughts and informed him that I had in fact written to him once before–over two months prior, I told him.  This time, he did write back with a terse response that didn’t feel like he welcomed my feedback at all.

I decided that maybe this guy wasn’t the person I should be learning leadership from, because the way I saw it was this “leader” offered more words than actions.  So, I took action.

I unsubscribed.

Now that I’ve been here for a couple months, I guess it is time to post a blog, but about what? Since, in large part, testing is new to me, (and an important part of developing Thundertix) I thought I’d start there. So read on if you want to hear about my experience. It’s been a wild ride.

Auto testing your code is a sexy idea to any programmer who has asked themself - ‘does my code work?’ Most importantly, ‘will it work when I move it to production’. Most of the time, the answer is “I think so, let’s see”. So testing, in theory, should allow you to forgo that nerve racking question altogether.

But testing, in my experience, is hard. More difficult than writing the code to begin with. By a long way. Not only because you are learning new constructs to exercise, poke and prod your app but also because you have to think differently about how your code is structured. Is the code in the right place - is it simple enough? Should I be moving my code out of the controller and into the model, as many of the best Rails programmers suggest? (When you start testing complex controllers, I can tell you, the answer is YES!)

So far, testing for me is like taking vitamins - it’s good for you - but may not taste good. So I tell myself, “every test makes your code stronger”. It’s a bit like exercising. The more tests you have the stronger your code will be. And you will know it - especially when you have to make sweeping changes.

I’ve got a long ways to go before I can say for sure that my code will work but, as I learn and get better, I can see the light at the end of the tunnel.

But, at the end of the day, if I never have to ask “Will my code work when I move it to production?”, it’ll all be worth it.