I’m overdue in announcing: I’ve left Pandora and rejoined the startup ranks at Xensr. I loved everything about my experience with Pandora, and in many ways I’m crazy to leave. But after 10 years of Internet radio, the lure of something shiny and new is proving just too irresistible.

Xensr builds technology that allows athletes to quantify and visualize their action sports activity in real-time 3D. I’m leading the software dev team and I’m super exciting about the work we have in the pipeline.

We’re hiring! If this sounds interesting to you, drop me a line.

Trust Nothing

Seasoned developers resist the temptation to believe what they read in code. Yeah yeah, so your professors told you that commenting code and using descriptive variable names are good practice. It won’t save you when reading someone else’s code. It’s true, these things can help guide you to truth, but they’re not truth in and of themselves. When you’re heads-down debugging a mysterious problem in code you didn’t write (or maybe you did), you might as well replace all that helpful text with hieroglyphics. Because you’ll save time by eliminating red herrings.

I saw this transpire with a recent news story, allegations of wrongdoing backed up by evidence from configuration files. The allegations were later debunked. It all centered around the word “throttle”, assumed to have a meaning that turned out to be inaccurate. The accusers had to rescind their story, presumably to much embarrassment.

When I first read the story, I cringed. Not because of the alleged wrongdoing, but because the accusers were being sloppy. They trusted what they were reading, that it meant something that was obviously true, and did nothing to verify those assumptions.

Seasoned developers don’t make this mistake. And there’s an interesting social awkwardness that results. When you are brought in to debug a problem you’re not familiar with, you face a social dilemma: be nice and accept what people tell you without skepticism, or question everything in what appears to others to be a pedantic ceremony of wasted time. Good developers accept nothing and question everything in the face of social scorn, and they’re right to do so. Here’s why: if assumptions accepted as truth are in fact correct, why hasn’t anyone solved the problem yet? On average, unsolved problems are far more likely to be based on invalid assumptions than to have inexplicably invisible solutions.

Lessons Learned From Being Stupid

You probably didn’t notice, but my ISP shut down my website for a while yesterday. They notified me by email that my site was “causing performance problems.” My initial response was, “uh, if my 15 hits per day is bringing down your box, that’s not my problem.” But then they sent me a server log. Whoops. Turns out that it’s kinda hard for a single shared box to keep up with millions of requests for a large file. Who knew.

Lesson learned: don’t take shortcuts when writing software. Software usually lives for a long time, those shortcuts come back to haunt you. Of course I already knew this years ago, but did that stop me from taking the shortcut a couple years back that brought down my site yesterday? Of course not. So do as I say and not as I do, and take the long route next time.

My poor shared host. Kudos to my ISP for catching the problem and handling it. And for their very professional responses to me. They eventually turned me back on after traffic died down without my prompting. Nice!

Lessons Learned From Blogging

My blog is on a new host with a new, modern design. The transfer has given me a chance to reflect on nearly 6 years of intermittent blogging. Here’s what I’ve learned about what it takes to write a successful blog (from the point-of-view of someone who yearns for a better blog):

Blogging is hard. To understand why, it’s important to define what “blogging” means. When launched my first blog, I defined blogging as “the act of writing a blog post.” I now define it as “the act of building and maintaining an interesting, frequently updated blog.” The former, challenging but not hard. The latter, hard.

It’s not just what you say, but how quickly you can say it. Time is the enemy of blog maintenance. So is perfectionism. A single post can be planned, crafted, reworked, slept on, and then finally published. But not daily, while holding a full-time job and raising a family. To be successful, you have to quickly produce engaging content in one try that’s good enough.

The most interesting content is also the most controversial. Back when I was developing Pandora Radio for iPhone, I grew accustomed to reading inflammatory, raging iTunes “reviews” that hated on me and my company for a host of minor irritations that, for some reason, really pissed certain people off. Such is the Internet. But angry comments directed personally at me on my blog? Different story. Plus, I hesitate to write anything that might embarrass or strategically hinder Pandora, which knocks out a bunch of interesting topics.

Writer’s urge isn’t guaranteed to align with spare time. And that’s the crux — spare time. My blog is a spare time activity. To have a successful blog, you need to prioritize and schedule time for it.

Casual reading doesn’t translate to casual writing. Like all great art, a well-written blog looks effortless from the outside looking in. But in reality a ton of effort lies beneath that silky text.

So those are a few of my lessons learned. Though I haven’t been as successful at blogging as I’d hoped, it’s been well worth the effort. I’ve learned a ton and it’s nice to “build” a product that “ships” so easily.

The iPhone 4S

I’m surprisingly not an early adopter type. I have my conventions for doing things, and I don’t like to change my patterns very often. So it’s pretty rare that I find some gadget that makes me feel like I’m going to change the way I do things. I think the iPhone 4S might just do that.

Speed: it’s not eye-poppingly fast, but it is intrinsically fast. You don’t notice it at first. But as you move around and play, you begin to notice that everything flows with you in a way that it didn’t before. It doesn’t look faster, it feels more intuitive. And that’s pretty subtle but important.

Siri: amazing first try, nowhere near its potential, but still quite useful. As with most AI systems, it’s the odd quirks that get you. It asks you if you want to send, and you say yes or okay or yes please and it does nothing but give you an error. But if you say send it, it works. There are also problems with the conversation flow. It’s hard to tell if we’re done with one conversation or not. And there have been several times where I’ve thought we were starting a new conversation but Siri thought I was still continuing the old conversation. I’m hopeful that they’ll work out a lot of the kinks during the beta period. And the fact that it’s in the cloud should help make it easier to develop iteratively.

Speech recognition: this is the killer feature. I’ve never used speech recognition that didn’t annoy the hell out of me. But speech recognition on the iPhone 4S delights me. It’s amazingly accurate and way more efficient than thumb typing. My only complaint is that I haven’t found a way to cancel if you get tongue-tied midsentence. So far, I love it and I plan to use it a lot. In fact, I used it to write this post.