Get your flu shots, kids!

I am just now emerging from a flu haze that first registered last Wednesday with a high fever that persisted through Christmas Day. Even after the fever went away, I was left with a cough and a general sense of fatigue that has been difficult to shake even now. Apparently, I’m not the only one — there appears to be a special California strain of the flu going around this year. In any case, I have a feeling that can only be described as deep disappointment that my visions of relaxation and movie-watching were simply not achieved (though there is still a little time). Instead, I was left in that state of being too feverish to read or even watch TV enjoyably.

On the bright side, if you’re gonna be sick, you might as well be sick when the world around you is moving slowly, because then you don’t get behind. And, I have to say, I had a lot of positive things to reflect upon as I drifted in and out of sleeping off the fever, so I can’t really complain too much. Life has been very kind to me this year, and I am very grateful.

The moral of the story: get your flu shot while you can. Don’t be like me and develop your immunity the hard way!

Merry Christmas

Merry Christmas (or whatever holiday you and your family celebrate!) Here are a couple of festive photos from my Flickr photostream:

Me on Christmas morning in 1975, at 3 years old — 30 years ago tomorrow
Christmas 1975

And my dog Jabari, after a trip to the pet store last week to get dog food resulted in an unanticipated purchase:

Jabari with Santa hat and beard

Happy Holidays!

Mashup Camp: a cool idea

David Berlind is working on a simple but killer concept for an “unconference” he’s calling “Mashup Camp” (and he’s already got the domain mashupcamp.com, so it’s not just an idle idea):

My goal for Mashup Camp is to do the opposite of what all these other Web 2.0-esque conferences are doing. It won’t be invitation only. The pilot event will be modest in size guaranteeing intimacy and low or perhaps even no cost to attend (perfect for some of the people doing the real innovation on a low budget). And, it will involve a mix of open networking time, leader-facilitated discussions that address some of the most important issues and concerns that the API providers and the mashup artists actually need to work out, and fun (for example, a hottest mashup contest with an even hotter prize).

I think David’s concept nails a clear deficiency in some “Web 2.0″ events: beyond all the talk about good ol’ RSS, there’s a deeper story about what’s happening in the broader world of APIs that is often glossed over. RSS is still important, but we need to expand the discussion. APIs are where the action will be in the coming months. The “mashup” theme broadens the discussion in all the right ways without losing sight of the technical guts that make everything work. I think the mashup concept is also something both business people and API providers can get their heads around. It’s a nice hook.

If you want to help David put this together, be sure to read the rest of his post about the idea drop him an e-mail. (Full disclosure: David is a friend from my InfoWorld days, but knowing and talking to David about this just makes me even more enthusiastic about the idea.)

(Technorati tag: )

A coding Christmas

The holidays make me a little reflective, and this year I realized something about my career that really blew my mind — for the first time since 1994, I am not directly responsible for production code or production systems! I can’t recall any particularly ruined holidays in the past (except a vicious DOS attack on July 4th one year), but in my past work, there has always been at least the possibility that a major system would have a problem and I would be responsible for dealing with it (or at least making the dreaded call to the person on my team who would have to deal with it). Right now (though I am super-busy), I don’t even have root on a single system at work. I might be lucky in that regard this year, but I will raise a virtual glass to all the people who keep the systems running during the holidays. . . . you deserve our thanks. Here’s hoping that your pagers and cell phones are silent during this holiday season.

I’ll be using the holiday opportunity to catch up on some non-tech reading, movies, guitar playing, etc., but Im also planning to get some hands-on time with some of the geek stuff I’m been too busy to play with lately, namely: Greasemonkey (using Mark Pilgrim’s Dive Into Greasemonkey), the super-cool new JSON stuff we’re offering at Yahoo!, and some miscellaneous blog tweaks. Yes, “fun” comes in many different forms.

I am not the founder of InfoWorld

There’s an article about what we’re doing at Yahoo! in the UK Guardian today that is worth reading (“Search for a fresher taste“), but there’s one thing factually wrong with this sentence (and also one stylistic tweak):

Through a series of hires and acquisitions, Yahoo is clearly assembling a squad of innovators and forward thinkers. Schachter joins a list of employees including Flickr co-founder Caterina Fake, the founder of technology news service Infoworld, Chad Dickerson, and blogging technology academics such as Danah Boyd and Cameron Marlow.

Though I would claim it with utter pride if it was true, I am not the founder of InfoWorld. Had I founded InfoWorld in 1979, many child labor laws would have been violated, I’m sure (I was seven at the time). InfoWorld’s 25th anniversary issue was published in late 2003. That being said, I am honored to be mentioned at all in the company of people like Caterina, danah (yes, lowercase — that’s the stylistic tweak) and Cameron, both of whom are far more than mere “blogging technology academics.” Nothing like working with brilliant people who are also a lot of fun.

Update: Look in the comments for one from Bobbie at the Guardian — they are going to correct the error. These things happen. I am impressed with the thoughtful follow-up and remain proud of my association with InfoWorld and the work I did there as CTO.

Corporate blogging panel at Syndicate

(Update: links added as the wi-fi improved)

I’m sitting in on the corporate blogging panel at Syndicate moderated by Charlene Li from Forrester, featuring Jeremy Zawodny (fellow Yahoo! and my cubemate), David Geller (WhatCounts), Greg Renaicker (Newsgator), and Jodi Baumann (Network Appliance — where Dave Hitz has a blog). A few random thoughts on the panel (if you’re looking for a blow-by-blow summary of the panel, this is not it):

Early in the panel, someone in the audience asked Jeremy what a “blogroll” was when he used the term. I’m pointing that out not because it’s a bad question, but precisely because it’s a reasonable question for someone who wants to learn about blogging. Luckily, there’s a decent blogging glossary that I just found (though I’m not sure I’ve ever heard terms like “blogroach” before and many of the words are superfluous to someone who wants to understand the basics).

Earlier in the panel, Jodi Baumann said, “we’re a public company” a lot in describing their relatively conservative approach to their corporate blog — of course, so is Yahoo! (granted, we are a consumer-facing company, not a hardware company) I work at Yahoo! (so I’m biased), but I think the way Yahoo! handles “corporate blogging” is a model for any public company — and it hasn’t gotten us in trouble yet that I know of (same goes for Microsoft and Sun, of course). We have a handful of official Yahoo! blogs (Y! Search blog, Y! Developer Network blog), but the corporate blogging policy (PDF) for individuals with their own blogs (which I think is reasonable and necessary for a large public company) allows and encourages blogging within well-conceived guidelines that address appropriate legal issues. Official corporate blogs aside, as the talent wars heat up again in Silicon Valley and elsewhere, I think encouraging employees to express themselves in their personal blogs is a competitive advantage in hiring. In that sense, I think companies thinking about “corporate blogging” should have the courage to extend their policies to address employee blogs explicitly. Yahoo’s blogging policy was a big factor in why I joined the company (and since I joined, my blog has helped me meet people within Yahoo! which has helped me get up-to-speed faster).

There’s also a “just do it” quality to blogs (again, within reason). Charlene Li noted in closing the panel that the first GM blog went from conception to launch in eight days. If GM can do it in eight days (with all the legal issues of a giant public company), it shouldn’t take much longer than that for any company to do it.

Platforms and the rule of three

Back in my old gig, I wrote a feature-length story entitled “Top 20 IT Mistakes” and wrote a followup blog post in which I referenced the excellent Facts and Fallacies of Software Engineering by Robert Glass, writing:

The book contains 55 facts ranging from the people-specific (“Fact 1: The most important factor in software work is the quality of the programmers”) to more specific rules of thumb about the process (“Fact 21: For every 25 percent in problem complexity, there is a 100 percent increase in solution complexity”). There are also 10 fallacies (e.g. “Fallacy 3: Programming can and should be egoless”). Both the facts and the fallacies are organized in a uniquely readable way — each one is a self-contained unit (cross-referencing the others when appropriate) that is divided into “discussion” (an outline of the collected wisdom behind the fact or fallacy), “controversy” (a description of why it is controversial), “sources” (a discussion of the source material available on the subject), and “references” (a traditional bibliography for that particular fact or fallacy).

These days, I’m thinking more about platforms than avoiding IT mistakes, and Glass’ book has helped clarify my thinking once again. Recently, I was thinking about what made a technology a “platform” technology (particularly in the context of the Web 2.0 “web as platform” concept) and I had decided that the platform test was simple: if a piece of technology served two or more separate systems, then it’s a platform, so platform technologies should be designed to do that. With that in mind, I looked into Glass’ book again and this time, Fact 18 suggested that my minimum was one short:

There are two “rules of three” in reuse: (a) It is three times as difficult to build reusable components as single use components, and (b) a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.

This sort of language seems very particular to writing code libraries/modules for use inside an organization, but I think the thinking clearly extends to web services that are intended to be “platforms.” Glass goes on to say that the skill set and approach required in building reusable code (and therefore “platform” code in my mind) is unique:

It is no wonder that knowledgeable experts say it takes three times as long. It is also worth pointing out that, although most people are capable of thinking about problems in a generalized way, it still requires a different mindset from simply solving the problem at hand. Many advocate the use of particularly skilled, expert generalizers.

The second rule of thumb is about being sure that your reusable component really is generalized. It is not enough to show that it solves your problems at hand. It must solve some related problems, problems that may not have been so clearly in mind when the component was being developed. Once again, the number of three — try your component out in three settings — is arbitrary. My guess is that it represents a minimum constraint. That is, I would recommend trying your generalized component in at least three different applications before concluding that it truly is generalized.

Those three applications don’t have to be huge, of course, and not all companies even have three products, but the “rule of three” seems reasonable when you’re thinking about building platforms. Maybe you won’t build those three apps to leverage your platform immediately, but you better be thinking about what those three apps might be.

The efficacy of time-constrained hacking

Friday’s successful “hack day” experience is still fresh on my mind and a couple of blog posts popped up on my radar today that
reflected some of the philosophical underpinnings of our event. A post from David Heinemeier on the 37Signals blog (“Constraints breed breakthrough creativity“) pointed me over to Kathy Sierra’s post entitled “Creativity on speed.” I’ll quote the same section that David did because it’s so on the mark:

One of the best ways to be truly creative — breakthrough creative — is to be forced to go fast. Really, really, really fast. From the brain’s perspective, it makes sense that extreme speed can unlock creativity. When forced to come up with something under extreme time constraints, we’re forced to rely on the more intuitive, subconscious parts of our brain. The time pressure can help suppress the logical/rational/critical parts of your brain. It helps you EQ up subconscious creativity (so-called “right brain”) and EQ down conscious thought (“left brain”).

I totally agree, and I’m glad that Kathy stated is so well. I feel fortunate that early in my engineering career (both as manager and coder), I worked in environments (like a big sports site that I and my team built from the ground up) where we weren’t shipping software as much as we were shipping experiences around very specific — and totally inflexible — events. When you’re dealing with sporting events, you can’t not ship. The World Series, Olympics, and Super Bowl happen whether your code to provide the experience is ready or not. In that environment, I learned that sometimes you really have to ship. Sometimes there literally is no more time — no one is going to postpone the World Series because your code isn’t quite ready. I also learned that if you have the right team in place, the team often does its best work under this intense time pressure. That’s why I had a strong hunch that some really cool things were going to happen at our hack day, and they did. As David writes: “Don’t worry about having more time, build less software.” If you can’t build less software (e.g. you have to have scoreboards for the World Series), build what you have to build in the simplest possible way — another practice that was clearly in effect at our hack day.

The end of Kathy’s post suggests a compelling structure for a two-day hacking event that I’m going to file away for future reference:

It would be fun to see a combination camp where the first half of the weekend was about actually making something, solo or collaboratively, and the other half was about exchanging ideas with the other participants (including the things you made during the first half, and lessons learned).

Sounds like a great idea. . . .

(Also, don’t forget to read Kathy’s “Build something cool in 24 hours“)

Hack Day at Yahoo!

Yesterday (with the help and support of all kinds of people across Yahoo!), I organized and ran the first “Hack Day” for the Search and Marketplace group (Jeremy does a good job of capturing the day). A few weeks ago, I put together an all-volunteer advisory team to decide how we should structure the day. The advisory team included engineers, of course, but we also had solid representation from the UED (user experience design) and product management sides. The advisory team did everything from make Costco runs with me to get “portable geek snacks” to making trips to a local trophy shop to help choose prizes. (In one trip, I was briefly lost with a product manager from Yahoo! Maps — we had a good chuckle over that one.) The help of the advisory team and many others made Hack Day a true grassroots effort.

A Hack Day team contemplatesThroughout the planning, we had a lot of discussion about what the “rules” should be, and we essentially settled on what amounted to no rules. I made sure there was plenty of food and drink throughout the day, but the teams ultimately self-organized and procured their own resources to make things happen during the day. Hacking is about code, without a doubt, but I was equally interested in the organizational hacking that took place throughout the day — teams commandeered conference rooms and turned spaces around the company into hacking war rooms. We kept food and drink in a central place and many people worked there. At the end of the day, anyone with something to show did a 2-minute demo in front of their fellow hackers.

Everyone rose to the occasion. I was absolutely blown away by the sheer number and quality of the hacks that emerged at the end of the day and the teams did a great job with the two-minute limit. The crowd at the end of the day was enthusiastic and boisterous. As hack demos were shown, yells of approval filled the standing-room-only room. The range of hacks was truly mind-boggling — I’m still getting my head around everything that people put together yesterday. One of my weekend tasks (and a really fun one) is running through the hacks again to take a deeper look. I don’t know how to describe it except to say that it’s a privilege and honor to experience and catalog such an incredible burst of hacker creativity. Yahoo! hackers — you ROCK!