Résumé Cover Letter

Oh, cover letters.

You can read my résumé and see all the work that I’ve done. You can look at the lists of languages and tools and platforms that I’ve worked with. They might tell you whether or not I can do a particular task.

None of that will tell you whether I can fit into your team. Or build a new one.

The whole point of this site (and this section in particular) is to “sell” you on my ability to work. Hopefully what you read here reflects a lot of my personality and work ethic, and not just a “spec sheet.” Those hard-to-gauge things that actually matter at least as much as specific technical knowledge.

In all of the positions I’ve held over the years, the one trait that I think has mattered most has been adaptability. Oh, I need to learn Perl? OK. We have to port the entire application to Android on short notice? Doable. I need to train developers on our in-house code base? Done.

No platform or programming language endures forever.1 I have changed many times and expect to change again. And the best people I have worked with have had a similar flexible mindset; a drive to solve problems with whatever tools the solution needs, even if that means finding new tools.

So what is all that experience good for? Aside from being adaptable, what makes me different from other developers?

Projects don’t succeed merely by willpower. The most dedicated developers can work sixty hours a week trying to get a product out the door, and still utterly fail because the product has no solid architecture. How you store your data matters because refactoring it later is costly.2 How you plan for future growth matters, because you don’t want to pay for code infrastructure you will never need. This is your platform architecture.

This is what I do. I write the code for it, too—I don’t just hand off the outline to a development team with a hand-wave and say “build this.” I firmly believe if you don’t have a hand in the code you can’t tell the difference between a good plan and a bad plan. You can’t architect what you can’t build.3

I love to solve hard problems. Sometimes, that’s figuring out how to make an application perform quickly enough while satisfying its business requirements. Sometimes it’s figuring out whether something is even possible at all. Solving problems… it’s what programmers do.

1 Although it sure looks like C, C++, and Java are going to try. FORTRAN is still in demand in some places and so is COBOL, but they’re certainly not as popular as they were in their heyday.

2 To be fair, this is never right the first time, because until you’re most of the way through the project you just don’t understand enough of the problem yet to nail it. But some types of refactoring are more expensive than others, and making intelligent bets on things that are likely to change can make all the difference in the world.

3 At least, not on the web. I am not a building architect and I will not presume to speak on their collective behalf.

Photo Credits: emus always have bad hair days: Damien Jones