Beeping

Personal

About five minutes ago, the beeping stopped.

I was in Texas last week for BBQ, clouds, and a wedding. At some point when I was gone, something in my house started beeping. When I arrived home there was a high-pitched chirp about every 45 seconds to a minute, coming from somewhere in the house. Generally when things beep annoyingly it’s one of the UPSes which like to complain loudly after a power outage. The one at my desk and at the closet both had a weird light on back saying “Building Wiring Failure.” (Probably because I removed the ground plug to plug them into a two-socket extension cord.)

I tweaked the UPSes for a good hour or two trying to get them to stop beeping, I pressed the buttons, reset the circuit, unplugged them, left them off, I even flipped my master breaker. (Which reset all of the thermostats to 62, a chilling fact I realized the next day.)

Eventually, I realized the beeping wasn’t coming from a UPS at all, but rather from the smoke detector in my office. I stood on a wheeled chair and sure enough there was a 9-volt battery in there that looked pretty dead, yet it was still wired into the wall in a way I couldn’t disconnect easily. Now that the problem was identified, I just had to find a 9-volt battery (I didn’t have any) and everything would be okay.

That was three days ago. Since then, I came to live with the beep. I found that if I closed the office door and my bedroom door I couldn’t really hear it while sleeping, any more than a cricket chirping. I took calls in my living room instead of my office. Even sitting at my desk, not 5 feet from the smoke detector, I was able to get productive work done with the beeping like a minutely metronome that was hardly noticable. For days.

Engineers do this all the time. We ignore the high-pitched beeping 5 feet away from us that would drive any normal person insane because whatever gene that gives you the programming knack also makes it disturbingly easy to focus and ignore things we’re familiar with.

This is why releases are so important, they force you to clean up your house like you’re having company coming over.

Your assignment today is to take a walk around your blog, application, website, whatever you work with on a daily basis, and allow yourself to be supremely annoyed with the beeping smoke detector in the corner. Let the nagging details of what you do grind like nails on blackboard and amaze you that you have ignored for months or years something so familiar yet so annoying. Obsess about it until you can’t do anything else except fix it, and take the 10 minutes to walk to the store and get a 9-volt battery.

Podsession Responses

Asides, ,

There have been two interesting responses to the podcast I did with Om and Niall the other week. The first was Scott Johnson who responded in a podcast. As I expected, most people are taken aback by my statement to “let the engineers pick” what language and enviroment you use for your product. I think there is one important assumption that wasn’t articulated in that statement: you have brilliant engineers and you trust them. As a psuedo-engineer, I find it insulting when people suggest engineers are unable to factor anything other than their selfish language preferences, things like loaded costs, hardware costs, platforms, long-term viability, hiring, etc are simple variables that can be considered by any intelligent person. If anybody in Automattic came to me that was writing a tool in Python, C, Perl (it’s happened) or whatever, I might ask a question or two but at the end of the day I know they’re able to weigh the costs and benefits just like I would. If you’ve hired an engineer that isn’t able to make these decisions as well or better than you, then you’ve already lost the battle and over time more and more of your time will be spent plugging holes in a descent to mediocrity.

The second response was on the Pronet blog which in an amazing feat of blogging acrobatics managed to mention and link every single person tangentially associated with the podcast except me, even though I’m quoted in every heading. The Google Pages example is brought up again to illustrate that all the hardware in the world sometimes solve a scalability problem, but I still think that’s faulty because none of us had any idea why Pages was slow when it launched, it could have been a faulty router for all we know. Pronet responds to “Go with what your happiest working with” with a set of points to consider for a language, but again with the right people none of that matters. Happiness, in all things not just the language, should be the number goal and metric for everything in an early-stage startup. Happy engineers work smarter, longer, more efficient, attract better candidates, and have a better quality of life. (A corollary is that if you’re already set on a language path, don’t hire anyone who isn’t thrilled with working in that language.) For an example of how this can work in a really extreme case, I suggest everyone read the story of Viaweb and Lisp. (Another talk.)In my mind Lisp is a ridiculous language to build a web application in, but to them and their engineers it was heaven and they had better products earlier than their competition as a result of their unusual choice.

(As an aside, I wonder how many people said the same thing about Ruby for web apps before David Heinemeier Hansson, Rails, and 37signals, or even about PHP before Yahoo and Wikipedia? An example (and a little bit of promotion) is better than a thousand whitepapers.)

Whoops!

Asides

Sorry for the interruption in service, things should be back to normal now. *ahem* If you missed it, someone guessed my not-at-all secure password to this blog and posted an entry and changed the “siteurl” setting.