Danny Lewin's 42nd Birthday

It's been nearly eleven years since 9/11 and I still think about Danny fairly often. Sometimes I think about the wife, sons, family, and friends that he left behind. I'm sure they miss him terribly.

More often, though, I think of how his life relates to mine. We were about the same age in 2001, but not peers. I was an engineer at his company, Akamai.  He was a force of nature.

So when I think of Danny, I think about...

  • how much he did in his thirty-one years.
  • all the great things that have happened to me since I was thirty-one. Two wonderful kids, amazing life experiences with my lovely wife, good career stuff.
  • what a positive, can-do outlook accomplish. Both for yourself and others. Danny had that in spades.

If I was able to ask Danny how to best honor him, I think he'd tell me something amazing with urgency. He'd then kick me in the pants to go do it.  

My Concentration Is Shot

I've lost my ability to concentrate. I knew this before I started my time off, but thought it wasn't so bad. Hey, maybe it's actually a sign of being a good multitasker. Obviously, that is crap.

Now that I'm on sabbatical and I really need to concentrate. The external distractions I can deal with: shut off email and IM, take the editor full screen. What has me concerned is even with those tricks I still have a hard time. It's me. My mind wanders. I think about of that other thing I was going to do; wonder what's going on with that news thing that has no immediate bearing on me.

As Yoda said, "you must unlearn what you have learned." I'm trying these things:

  • Reading. Not blogs, but books. Business stuff is OK, but fiction is better. Best: dense science fiction -- that requires concentration. I don't view this as entertainment (which it primarily is) but exercise.
  • Coding. Anything less than a three hour block of time is almost worthless. But once the Flow comes, it is sooo good.
  • Watching lectures. The drier the better.

I'll report back in a month if my concentration is any ... wait, what was I saying?

"I absorb uncertainty."

It was my first day at Akamai.  They were still small enough that the all new employees had group lunch with the CEO, George Conrades.

For those who don't know him, George is flat out impressive. Partially that comes from being smart, thoughtful, and well spoken. But it also comes from being comfortable in big jobs. Prior to Akamai, George was CEO of BBN and GM of IBM United States, part of his thirty year career at IBM.

Somoene asked George what he did as CEO, and George unpacked his stock answer. Something about products, people, and finances.

The new hire followed up: "No, George, what do you actually do?" It was a pointed question, and a bit smart-alecky. But it was also genuine, and George took it seriously. His answer stuck with me.

"I absorb uncertainty," George said.

He explained: If you get this many bright people together you're bound to have differences of opinion. Those can escalate into a real disagreement. Soon it gets heated and feelings and reputations are at stake. When this happens, the CEO's job is to hear and follow the discussion, know when forward progress isn't being made, and then make a decision. And then communicate that decision clearly so everyone can move on.

Making a decision absorbs uncertainty. Uncertainty disempowers your people and paralyzes your organization. A good CEO doesn't let that happen.

Now that's a good leader.  Thanks, George.

PS - Googling around for this phrase, I see others might have used it too.  One is Vittorio Cassoni, reported by Esther Dyson (video). But in my book, credit goes to GHC.  

Making Browsers Better for Web Apps

I have two distinct use cases for web browsers: browsing and web apps.  I contend browsers are fine for browsing, but are clumsy for web apps.  This blog proposes how to improve the web app use case.

Case 1: Browsing. I interact with a variety of web sites for a variety of purposes. The common activities here are searching, moving between pages, filling out forms. What is most important to me are rapid navigation, working with multiple pages, even advanced things like saving images to disk.

Case 2: Web Apps. These I use in very limited ways: aside from an authentication flow, I'm often interacting with a single page. Browser features like tabs and search bars are inappropriate and confusing. I want these to feel as much like a native apps as possible.

A web app could be something as simple as embedding a little flash player.  I've done this for the Radio Paradise player, a little station that I like a lot.

A better web app example is Google Calendar. I don't want forward/back buttons, URL bar, or tabs. I want right click to either do nothing, or something very app-specific (new appointment?).  I want "quit" to just quit Google Calendar and not affect any my other work.

In my day-to-day life as a Mac user I use Fluid to get pretty close to what I want. With Fluid I get one window per site, a so-called site-specific browser (SSB). Fluid removes a lot of the browser features, like bookmarks, URL bar, or the search bar, because it doesn't need them. The app get its own top-level icon so it can be in my dock. It's great, I totally endorse Fluid.

Here's a screenshot of another web app that I love: Remember the Milk.  Excellent web app.  Just don't clutter it up with all that browser junk.

But it's tricky enough to get this working that I can't recommend it to "normal" users.   Here are two examples.

The definition of what URL's make up this app can be a bit fussy, and changes over time.  URL's in the app open need to open in the same window, outside the app should open a new full-fledged browser.  This bit me when I started using Google's two-factor authentication.  This additional step in the auth flow, implemented with a new URL, spawned a new browser.  Since Fluid uses Safari, and my default browser is Chrome, the auth cookie got set in the wrong browser, effectively breaking authentication altogether.

The second complication is finding a good app icon. This isn't as acute as broken authentication, but don't trivialize good icons either.  Fluid's default is to use the favicon (32x32 pixels I belive) which is just lousy. Luckily people have sets of icons they share on sites like Flickr, but you have to find them, unzip, etc. That's doable for me, but not for everyone.

I'm glad to see Chrome and Firefox making this easier, albeit slowly. Chrome has the "Make Application Shortcut" feature, but it's been Windows only for a long time. (hint hint Chrome team).

Here's a neat idea: a crowdsourced recipes database for Fluid that would encapsulate all the good settings to make it work and keep them current. As the apps change, the recipes would update and your local apps would get those updates. You could even take that one step further to enable features like limiting geometries and font sizes to presets that make sense for that app.  For example, Remember the Milk (screenshot above) looks good tall and narrow.  Fluid does seem to have a premium feature to allow Userscripts and Userstyles, which could help a bit.

Hmm, maybe I'll see if the Fluid guys want to work on something together on this.

Working Hard, On The Right Stuff, and In The Right Way

Pointy Haired Boss

So now you're an engineering manager. How do you know if you're doing a good job?

This was an important question for me about thirteen years ago, when I moved from a code-every-day software engineer into my first management job. In the decade-plus I've been an engineering manager (up until recently) I've relied on three measures for myself and engineering managers under me.  It's the title of this post.

The problem is that managers enable their people to produce. An engineer's contribution is measurable, more or less. Even when the scale and units are slippery (is that 95% or 50% done?) at least you can see forward progress: releases, bugs closed, API users. But an engineering manager? At best it feels squishy; at worst it feels like overhead, and nobody wants to be overhead.

The question of "am I doing a good job?" came up when I was a first-time engineering manager at Akamai Technologies.  This was 1999 and Akamai was still small-ish (30 engineers).  Us first-time managers were learning on the job. That's when I distilled down my three rules.  They are:

A good engineering manager's team should be
  1. working hard,
  2. working on the right stuff, and
  3. doing it the right way.

The key insight here is that you don't measure the manager herself, since management done well just enables the creative work of the team. Judge the team and you judge the manager.

Working Hard

Of course a high-performing team is inherently good. But it's also the best indicator if the manager is doing their job right. A productive team is a motivated team. In my experience, teams don't work hard unless they have all the wonderful qualities that we want in a team: empowerment, alignment with company goals, feeling of camaraderie, trust in management. They should be equipped to do their work and know why they're doing it. A manager should try to give their teams these things, or at least not get in the way.

Let's consider the alternative. If your engineers are demotivated or bored then long before they quit (and they will) they will check out.

One caution: working hard is often confused with long hours and face time. It's not. And there are few things more demotivating to a team than a manager demanding more hours. (Some places are really productive and only work four days a week.)

Hiring and firing figures into this too. An under-staffed team can't do what it needs to do or can get burnt out. Worse, lowering the bar to hire someone beneath the team, or not firing the low performer, is hugely demotivating.

Working On The Right Stuff

This is where the manager can have a more direct and immediate impact. You have to set up a few good processes (not too many) and enforce them.  Your goal is maximize useful work.  One way is to prevent work on stuff that will be wasted.  Another is to reduce thrashing by finishing one thing before starting another. This is where delivery comes in: it's one thing to be busy, but how much makes it into real customers' hands?

Some of this sounds like product management, especially prioritization and product definition. But it doesn't happen well without the engineering manager communicating well, working closely with those product managers, pushing back constructively when needed.  So actually read that spec!

Much of my career has been in backend systems. Infrastructure projects to enable features are the exceptions. Most aim to improve reliability by doing things like removing bottlenecks (scaling) or bulletproofing systems. Unfortunately I think the only way to judge these projects qualitatively.  Measuring how often it would have broken is so hard. Just make sure you get a techie who you trust to evaluate projects impersonally and critically. And be careful of pet projects.

Doing It The Right Way

For many years I only had the first two measures. But I've come to value this one more over time.

This criteria captures quality and culture. Are the manager's engineers working well together? Best judge of this is if other engineers want to be in this group. Do the engineers have a culture of quality? They should speak with pride of their work. If they feel their products are slipshod, through lack of care or lack of room to do the job right, then it will show.

It also means that they aren't leaving scorched earth behind them. Their systems are maintainable and usable by others; the ops guys don't hate them because of missing tools or crappy logs; they've done code reviews and actually listened to the feedback.

Anti-Patterns

There are a couple of other things that I haven't mentioned as being important. They're probably on others' lists, but not on mine.

  1. "Leadership." To some people this means that you know how to tell people what to do. To others it means just doing a lot of the things above well, like communication. I'm not disagreeing that it's not important, I just don't know how to define or measure it. It feels like one of those "you know it when you see it" things.
  2. Well-triaged bug lists; great status reports; well-run team meetings. If any of these things help you accomplish the three things above, then do them, if not then they're paperwork.

For example, when I managed a large team at VMware I spent a lot of time triaging bugs. That's the VMware's engineering culture, but it's also what you need for a large, distributed team delivering enterprise software. By contrast, at Ning I spent very little time in the bug database. That team was much smaller (6 vs 100), and our releases were less complicated and less scary. And that was the right way to manage that team.

Finally, I want to credit some of those early managers in those Akamai days that I learned with/from:

  • Experienced managers like George Conrades, Danny Lewin, Tom Leighton and Ross Seider
  • Fellow newcomers like Joel Wein, Ravi Sundaram, Harald Prokop, Marty Kagan, Jay Parikh, Julia Austin, and Bobby Blumofe
  • Thoughtful techies like Danner Stodolsky, Bill Weihl, Erik Nygren, and Chris Joerg.

My Sabbatical

"Don't bug me, I'm on sabbatical."

Over the past 20 years I've worked on interesting problems, delivered some great software, learned a bunch, and worked alongside bright people. And had fun. It's a fulfilling career. What has gone well is due to a little hard work and a lot of good fortune for which I'm grateful.

But now I'm taking some time off, maybe a month or two, maybe as much as six. It's my first sabbatical of sorts. (I'm still not sure sabbatical is the right word.)

So, why? I have three reasons.

  • I want to sharpen up my tech skills. I didn't like the atrophy I was seeing. Management will do that to you -- at least it was doing it to me. Sure, you write a few little things (utilities, tests, page-long SQL queries) and go to code reviews, but that isn't the same as "real software." More importantly, the longer it's been since you've coded, the harder it is to just pick it back up.
  • I want to explore technical areas that I didn't have time or an excuse to explore before. Mobile is the first example, there are more.
  • I feel the need to put myself out there. Being part of teams is useful and gratifying, but you can hide in there too. I want to work on my own projects, not for ego, but for motivation. I am already out of my comfort zone.

I'm not looking for a career change. I like software engineering management. And I know that I'm a better manager than code-all-day hacker. This is about proficiency with the tools and branching out.

So it's been two weeks now: what have I gotten done?

  • Took a vacation to Hawaii.
  • Got my first toy iPhone app running.
  • Made three dishes from my Indian cookbook (thanks for the pointer Devin).
  • Wrote my first blog post.
  • Made it through the DMV and lived to tell the tale.

The biggest change so far has been in my mindset. When I first considered this I had no clue what I'd do; now my "ideas" folder is chock-full and growing. It is creative and exhilarating.

That said, this is all still new and I'm figuring out the how's and the what's. If you have suggestions or advice I'd love to hear it.

 

Too Many Clouds (or: Why I Don't Use Evernote)

Like pretty much everyone I know, I have moved the data that I care about into a cloud. Actually a few clouds. Mostly this has resulted in lots of goodness: multiple device access, reliability, backup, sharable. But it's also caused a problem.

Where did I put that list of frequent flier numbers? Where are those notes on running a Minecraft server? Will Spotlight help me find it, or do I need to open up a browser?

The challenge is that I need a mental index of what I've stored where (and sometimes when). That index is getting larger and more difficult to maintain. On top of that, all hell breaks loose when two clouds rub together and data is synced/reconciled between them. Witness the mess that my once-pristine address book has become.

Granted, this is a bit of a high-class problem to have. But it does cause friction and confusion, especially as more "regular people" (ie. non early-adopters) switch to cloud storage.

Here's a sampler of the clouds that I have some stake in, to some degree:

  • Dropbox
  • Google Docs
  • iCloud
  • Instapaper (only for its own app, but still)
  • Box.com (50GB free!)
  • Evernote (no longer)

(For this discussion I'm not even broaching things like relationships. Let's keep "data" simple.)

Each stack has its special wins. For Dropbox, it is elegance, always-works simplicity, and cross-platform. Google Docs' real-time collaborative editing is so awesome, it feels like science fiction whenever I use it. And so on. Either you forego those features, or you live with fragmentation.

I look suspiciously at a new application that brings its own sync and store. Is its trick so compelling to offset the complexity? Take Evernote, for example. Their iPhone amd desktop apps are super; data synchronization is quick, clean, and reliable; they have nice integration with apps and a growing ecosystem. But it's yet another cloud.

I wish this would shake out by itself, but I fear it will not. What I want is these stacks to begin to use other backends in addition to (or instead of) their own.  Instapaper on Dropbox; Evernote on iCloud.  But there are at least two big headwinds: first, the big consumer companies will always go it on their own (Google, Microsoft, Apple); second, even the small guys realize that data is sticky and what really matters, so they will hug that data as long as they can.

So in the meantime I hope for integration / consolidation, and try to keep things simple.

An interesting corollary. The consumer backup problem is becoming simpler by devolving into specific types (and sizes) of data. The free clouds big enough to house documents and high-value data. Gmail is large enough for all but the biggest email junkpiles. That leaves two classes of data: music and video libraries (big) and personal movies and photos (also big). With iTunes Match Apple has a unique take on the first set, I wonder who will have a good solution to the second?

Those Little Utilities That Make All The Difference

I tend to obsess a bit about creating a nice work environment. Software environment, that is.  This blog post focuses on the setup that I have that works for me, specifically those little glue utilities that are so helpful. So I won't cover the big local apps (email, browsers, productivity, dev/test) or web apps (todos, photos), that's for a future post.

Witch ($14, Many Tricks) - Maybe the one I use the most.  I find that the default OS X cmd-tab switching to be annoying by cycling through apps instead of windows. Maybe that's just because I spent so many years living in windows and this mimics the Windows behavior, I don't know, but this is what I consider natural.

WItch Screenshot

Adium (free) - Best IM and IRC client I know of.

iTerm 2 (free) - Replacement for built in terminal.app. Terminal isn't bad, but the one feature this has which I miss from old terminal programs is auto copy selection contents when switching to another app. I do that all the time. Doesn't just save a few keystrokes -- seems every time I expect my selection to be in the clipboard, and when it's not, I find myself hunting around.

Fluid (free) - I like web apps I use a lot (gmail, Remember the Milk, Google Calendar) to function like real apps: own icon, startup and quit behavior distinct from other browser windows, etc.  I've now come to appreciate those as Site Specific Browsers (SSB's), and Fluid is the best way of doing those.  It's a little strange as that relies on Safari, and I use Chrome for everything else, so those SSB's don's share cookies or anything else, but that's not a big deal.  Fluid even has some nice little special cases, like adding unread mail badges to your gmail icon (neat!).

Homebrew (free) - the missing Mac command line package manager.  There are others (most notably MacPorts) but I've tried both and this one seems cleaner and easier.

My current package list is:

  • autojump, multitail -- surprising gems
  • macvim -- worthy of its own blog
  • watch, wget, figlet, dos2unix/unix2dos, wget -- how can they not be included standard?
  • fping, wireshark -- network hacking
  • gnupg -- crypto