Developer Experience Matters

In my latest post on the Mashery API Strategy blog, I explain why developer experience matters and why you should spend as much time, money and effort ensuring you have great API design and documentation as you do on your web site’s UI and UX design. I also make the somewhat controversial claim that, just because you built your application in an MVC framework like Ruby on Rails or Cake PHP, you don’t really have a good API. No matter what the designers of those frameworks say, you can not get a good API for free.

I welcome your shocked and awed reactions.

My First Mention in TechCrunch and My Nose Was All Snotty

This happened a few weeks back, but I’ve been remiss to mention it here. After more than 20 years in the industry, I finally got a mention in TechCrunch. Sadly, it was for having a ginormous booger in my nose.

In truth, it was because of a cool app Neil Mansilla and I developed during the TechCrunch Disrupt Hackathon this year. Though we didn’t win, our idea and pitch for Hot Mess stood out enough from the crowd of about 270 other pitches to be worthy of writeup in TechCrunch. Frankly, that’s a win in my book.

You can see the video we produced for our pitch below.

So You Think You Can Dance

Dustin will be in his first talent show today (preschool – seriously). Last night, he informed Danielle and I that he was nervous and didn’t want to go to school because he has no talents.

This is patently false. The boy has several talents, chief among them the odd ability to dance. Odd because his mother and I are completely devoid of any sense of rhythm. Put on a house beat and Danielle and I will just sway awkwardly. The boy, on the other hand, gets into this crazy pop and lock groove that is mysteriously in time with the music. I’m not sure where he picked it up – he sure as hell didn’t learn it at home – but I am impressed, even beyond the normal “proud father” level.

So we encouraged him to dance for his talent. He sort of resignedly agreed and the conversation ended. This morning, he told me he’s still nervous. We had a small bonding moment over it. I told him that every time I get in front of a crowd, no matter what size, I always get nervous, but I ride that nervous energy to make my performance the best I possibly can. He seemed to understand.

Nothing profound here today, just marking the boy’s first time entertaining a crowd. No matter how it turns out, I’m certain it will be awesome.

Code Review as Line Editing

This morning, I’m reading through a ton of Github comments our VP of Engineering added to the codebase last night. Initially, I was annoyed by his nitpicking – it’s not my code, but I tend to think that niggling comments about using throwaway variables or other things that have negligible impact on performance can kill a coder’s sense of creativity and individuality.

Then I remembered that our engineering team has a style guide for Ruby. When I ran TechKnowMe, I wrote a coding style guide that I expected my freelance developers to follow, but it was fairly minimal. The only other time I had a style guide to enforce was back when I was an editor for a newspaper, line editing the stories my writers turned in.

The line editing process is not intended to kill creativity and individuality, it’s intended to help communicate information as efficiently and consistently as possible in an editorial setting. I always line edited my writers’ work while they looked over my shoulder, just as my editors had done when I was a reporter. I explained my reason for making each change to the writer as I made it, which allowed for some debate. It was an educational process for both of us – they honed their skills and learned how to write articles that required less editing, while it forced me justify whether the changes I was making were genuinely an improvement.

Looking at our VP’s comments in that light, I view the code review process in a whole new way. Coding is functional editorial – you’re communicating not only with the computer to feed it instructions, but with future developers who have to maintain that code. Those future developers include yourself, and I’ve found that code I have written as recently as six months ago can look foreign to me. It’s been a while since I was a trench developer, and I definitely miss the education I got through these code reviews, as even the act of making the comments is educational. I’m learning a lot by reading these comments. It’s not my code, but reading them is going to make me a better programmer.