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.
I gave a talk at this year’s RESTFest teaching developers about how to talk about APIs with the business side of the house. The sound is less than perfect, but you should still get the point. The slides for this talk can be found online here.
I gave a talk at Startup Weekend Asheville this year on one of my favorite topics – customer validation. The premise is that your idea sucks until you prove it otherwise. Take a look!
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.
I’m on a blogging tear – everywhere but on my own blog it seems. Regardless, this just got posted to the Mashery API Strategy blog (which you should really, really follow). One of the best parts of my job at Mashery is staying on top of the rapidly changing API landscape. In this blog post, I explain how I keep on top of API best practices and why.
My first blog post for the Mashery blog just went live, wherein I describe what a RESTful API is and why you should care, especially if you’re not the technical type. Go read it!
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.
I just sent out the fourth exciting edition of the Fascinating Newsletter. Check it out!
This is absolutely one of the best presentations on the business value of APIs and how to market them to developers I have ever seen, courtesy of the fine folks at Apigee.
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.