James Grimmelmann is a resident of Seattle, Wash., a software design engineer with the Microsoft Corporation, and the madman behind The Laboratorium.
Monday, 30 Oct 2000
SEATTLE, Wash.
I’ve worked at Microsoft for a year and half total, and in that time I’ve received two spider Koosh balls (Kooshes with only 20 or so hairs, giving them the lean look of predators), three twisty link toys, an indoor Frisbee, a magnetic poetry kit, a high-bouncing rubber ball with a motion sensor and microchip inside (when bounced, it flashes and makes a loud breaking noise; now banned from lectures at MIT), two fleece pullovers, a reversible vest, a propeller beanie, four coffee mugs, a miniature globe, a Koosh yo-yo, a hard plastic noisemaker shaped like a hand, two bumper stickers, a picnic backpack (containing a blanket, a carving board, complete place settings for two, salt and pepper shakers, wine glasses, and a bottle opener), an oversize hardbound book, boxed copies of three different Microsoft products, a bottle of “Microsoft Brainwash” cola, two water bottles, and ten T-shirts.
The question one naturally tends to ask is, “Why does a software company need so much stuff?“
Microsoft is, by and large, a pretty responsible corporation, and I’ve been continually struck by how well plugged-in and environmentally conscious the people I work with are. Unlike at Silicon Valley companies, conspicuous personal consumption is discouraged; there are surprisingly few sports cars in the parking lot. Those who have it don’t flaunt it. Individualism at the expense of hierarchy is encouraged, but everything else is communitarian. Everyone gets the same office, the same office furniture, the same computers, the same perks. And this also means they get the same useless freebies — and the same recycling bins. Microsoft’s push toward conservation and its encouragement of waste are flip sides of the same coin.
Take the computer pool as an example. Your computer comes from some unknown source and returns from whence it came when you don’t need it any more. Your old computer too slow? PC-Recycle will come pick it up and give it to someone who doesn’t need a super-fast computer; meanwhile, your group admin will quietly see to it that a shining new dual-proc 800 GHz Pentium III shows up in your office. How does it work behind the scenes? Nobody knows. The magic computer elves take care of it. What happens to the aluminum cans collected from the gray bucket in your office once weekly? The magic soda can elves who keep the fridges stocked with free soda take care of it. The supplies in the copy room? Magic copy paper elves.
On the one hand, Microsoft is fairly clearly doing the right thing with the resources that pass through its control: I need to separate my trash more carefully at the office than I do at home. The office lights go off at night unless some night owl specifically turns them back on (and then only in single-hallway increments). The same desk units will be reused into the next century. On the other, this sort of zero-exertion everything-you-need policy creates a certain concomitant complacency. Grab a knife with lunch even if you don’t need it: It’s going back into the polystyrene bin afterwards, so there’s no harm done! Your desktop machine is only 600 GHz? Come on, man, why are we wasting your time during compilation like that, let’s get you a new one and put the old one back in the pool! I’m just flipping the switch that turns my office light on, what harm is there in that?
These are somewhat trivial examples, but the problem is that Microsoft corporate culture, as typified by the truckloads of freebies, pushes us into a communal mode of mass consumption. Young and otherwise environmentally conscious people with a little too much cash can be swayed by an environment in which nothing physical should ever be difficult and where there are “free stuff for everyone!” days every month. Softies don’t often buy SUVs to show up their neighbors, but sometimes they buy them to fit in with the other Softies who own one. Strangely Spartan in their home furnishings they may be, but they’ll impulse-buy the new generation of every consumer-electronic device that might save them five minutes a day. It’s not a bad life to live, but not everyone can live this way — a bit of perspective it’s easy to lose track of when you’re making as much as your parents in your first job out of college. Context doesn’t always come easily. We’re working on it, but there’re still some areas for improvement, as the performance review forms say.
One final note: If anyone wants the backpack and picnic kit, they’re yours. First email gets the lot, plus hand-delivery if you’re in Seattle. I’d like to see them get some use.
Tuesday, 31 Oct 2000
SEATTLE, Wash.
Software development is a resource-obsessed business, even though these “resources” are close to pure abstractions. Everything is measured in terms of its costs: how many CPU cycles this algorithm will take to run, how much disk space the program requires, can I do this search-and-replace with two passes over the list, or will I need three? It’s typically pretty easy to write something that works; it tends to be much harder to write something that works without excessive waste of time and memory. We do everything we can to make sure we do things right the first time, but because we’re mortal, we also schedule plenty of time for debugging.
It’s debugging season here in my group, that slow and arduous march through waist-deep mud that every software project must engage in. We had a round of writing new code at the end of the summer, and now we have to clean up after ourselves and kill off as many of the bugs we introduced as we can.
Strangely enough, the more catastrophic the failure, the easier it can be to figure out what’s going wrong. Something like dereferencing a null pointer (the software equivalent of trying to walk through a nonexistent door) sets off so many internal alarms in your program that you have some fairly specific evidence to start from. When a supertanker runs aground, at least you know where the problem is and where to work on dealing with it.
On the other hand, there are the memory leaks.
Imagine that you needed to store everything you owned in identical unmarked boxes, and that the only way to keep track of the contents of more than the few you can remember offhand is to keep lists of box contents in other boxes. This is the situation faced by a computer program storing things in memory. It’s dangerously easy to have two boxes, each of which says “HANG ONTO THE STUFF IN THAT OTHER BOX,” but no useful information as to what those two boxes were helping you keep track of. The program can’t afford to take the risk of throwing out a box unless it knows that it’s absolutely safe to do so; the space taken up by an unneeded box has “leaked” out of the system.
Specifically, I’m working on editing expense reports, employee reviews, shopping lists, and things like that. When I open up our sample expense report, and add an expense, the program uses 100 kilobytes more memory, which is fine, since it’s presumably using that memory to keep track of the new expense item. But if I delete this new expense, the program is still using about 30 kilobytes more than when it started. If I add another expense and delete it, memory usage is up by 60 kilobytes
. Three times means 90 kilobytes lost, and so forth.
This is no good; if the program runs for long enough, it will eventually start to choke on its own wastes, as it were. The computer will run out of memory and slow down to a crawl, even though very little of the memory is really being used. So I’m going through with a fine-toothed comb, trying to figure out which of the program’s detritus it’s forgetting to take out to the virtual curb for recycling.
Basically, I’m trying to leave behind enough explicit instructions — e.g. things of the form
if (numberOfDaysSince(today, k_December25) >= 10)
      {
      pChristmasTree->Release();
      }
— to make sure that we’re not hanging onto stuff past its useful life. This can be a tricky business, because if a program allocates a million objects and releases all but 1,000 of them, just figuring out which 1,000 it’s still hanging on to is a tricky task. Figuring out which 10 of these 1,000 it doesn’t really need is even harder.
It’s complex bookkeeping, and tiring, detail-oriented work, but it’s also quite necessary. Especially for things like the software that powers major websites — and doubly especially for the sections that get run millions of times in a day — even a tiny memory leak can be fatal. Multiplied ever the course of a few days, losing even a few bytes every now and then rapidly adds up. Software has to live within its means, and unless it cleans up after itself, a program is quite capable of running its virtual ecology into the ground.
Wednesday, 1 Nov 2000
SEATTLE, Wash.
How much power does your computer use? It’s probably around 100 watts for a desktop machine, but what does that 100 watts mean? I work in an office with two honking current-guzzlers, and I have a pretty visceral sense of their power usage: I can feel it in the temperature gradient between my office and the hall.
A computer, at heart, is a resistor: a device that turns electricity into heat. By the end of the day, my office has a warm and cozy feeling, thanks to the pair of space heaters under my desk. Our building has a couple of labs, home to rack after rack of machines, running test suites against our code day and night. The air-conditioning in them runs on high full-time; if the HVAC in our building gave out, the lab machines would need to be shut down before the room became uninhabitably hot.
Nor is power free. The figure I’ve heard is that leaving your computer on overnight releases about a pound of pollutants into the atmosphere, although that figure will vary with your source of electricity.
Of course, the power drain is the least of it. The clean-room manufacturing process needed to make a modern microprocessor requires both a great deal of energy and a great deal of water, both of which have to come from somewhere. And at the other end of its useful life, your computer isn’t exactly compostable. The radiation shield in your monitor is made of lead, and other bad-boy elements like mercury and cadmium abound in the chips and connectors making up your motherboard. The computer industry is just beginning to face up to its responsibility in this matter.
For all of this, I’m actually optimistic about the overall impact of computer technology. Part of this belief is pure cynicism: We’re such wastrels in other ways that computer-induced waste isn’t really the top issue right now. That 100 watts your computer draws is the equivalent of one lightbulb, and the question becomes “are we doing more good with the computer than we would be with the lightbulb?”
My belief is also informed by my experience with life at Microsoft. People have been talking about a paperless office for a long time, but sometime between when I first interned at Microsoft four years ago and now, that paperless office snuck up on us. I haven’t printed anything for work purposes in the last six months, I’d say. Status reports, design documents, pay stubs, even all my actual work — all these things exist solely in email, on servers, on my screen. On the whole, I’m doing far worse by the world’s trees through my book-buying habits than I am through my working environment.
And what are we doing at work? We’re trying to do in software the kind of things that used to be possible only in some tangible form, with all the attendant waste of stuff. If my expense-report sample does what it’s supposed to, nobody will need to use paper expense-report forms again. When Microsoft Research sponsors an interesting lecture, I watch a live video feed — and can ask questions of the lecturer — using telepresence software. That conference room is smaller than it would otherwise had to have been, and that’s one less shuttle ride. More generally — and this is a goal of software developers everywhere — the less time we need to spend doing stupid unnecessary repetitive tasks, the more time we’ve got free to think, to pay attention to things that matter. Every time someone fixes a bug and our software gets that much more usable, I can focus a little more clearly on what it is I mean to be doing when I use it. It used to take phone calls and 10 minutes of coordination to schedule a meeting; now I can do it in 30 seconds by checking the invitees’ calendars online. That’s nine and a half fewer minutes wasted on the stupid meeting, nine and a half minutes in which I have a chance to give something valuable back to the world.
Actually, this example is disingenuous. I had a meeting on Monday, and I won’t have another until next Monday. This is one thing that drew me to Microsoft: The company understands that we developers work better when we’re not being “randomized” all the time. But I think that this observation supports my belief anyway: Pragmatism in clearing away the small details helps enable idealism when considering the bigger picture. Considering such things, for example, as whether the use we’re making of a given computer justifies its lightbulb’s worth of power, and if not, what to do about it.
Thursday, 2 Nov 2000
SEATTLE, Wash.
Stayed late at work yesterday: My team was having a bug bash. We spent the evening looking for bugs in a twisted parody of a brainstorming session: Who can think up the most creative way to break the product? This one was pretty good. We found 65 bugs in about three and a half hours, and the whole thing wrapped up around 8:30. At which point I drove home. Alone.
I’m a sinner. I take the bus maybe one day a week; the days I don’t, I save myself morning and evening walks of about 10 blocks. I know five other people in my group alone who live near me and who also drive the 12 miles to and from work. It’s not a short bike ride from here in Seattle to Microsoft (in Redmond), but it’s definitely possible. There’s no justification for my ways, only excuses.
What I’m experiencing, I think, is flex-time’s unanticipated revenge. Microsoft doesn’t care when I’m at work, only that I’m able to get done what I need to get done during the time I choose to be in my office. This enlightened attitude — which I sometimes use to work compressed weeks — has two unfortunate side effects when it comes to my commute.
The first is that, like most of my fellow Seattleite Microserfs, I drive over to Redmond after the morning rush hour and back after the evening one. Because I have the luxury of driving on comparatively open roads, I don’t have to suffer for my automobile usage the way commuters with more proscribed schedules do. I’m a nearly pure free rider, so to speak. If I had to commute at rush hour, I’d be on the bus every day, so at least I could read during the trip.
The other side effect of a flexible schedule is that programmers tend to keep stereotypical programmer hours: Get in late, work for a while, stick around really late chas
ing down some annoying issue, stagger home, sleep in, and get in even later the next morning. Those weeks when I’ve lost discipline completely and work from noon (or later) until near midnight (or later), public transportation is just not an option, nor is carpooling much more realistic. And even when my schedule is comparatively under control, taking a cooperative form of transportation to work means committing to leaving work on schedule, too.
A lot of us here need to clean up our ways, basically by taking on a little more responsibility in outside-of-work matters. That’s not something that comes easily to many Softies, but there are encouraging signs. My neighbor in the next office lives in Seattle’s Capitol Hill neighborhood but bicycles to work with some regularity, and a great many people I know who live on the Eastside (nearer the Microsoft campus) bike in as their normal commute. The 263/266 has earned the nickname of the “geek bus” for the number of Microsoft employees who ride it (although, unfortunately, not enough to fill it up). In my old group, I came in one day and saw an EPA miles-per-gallon sticker on a coworker’s office door: “61 city, 70 highway.” That was how I met my first Honda Insight owner. He has since persuaded another member of that group to buy a Toyota Prius.
Lovely little Sparrow.
More dramatically, I was driving home one day a few months ago when I saw the strangest-looking vehicle I’d ever seen. Some research when I got home revealed that the mystery-mobile was a Corbin Sparrow, an electric car with a range of 30 to 60 miles, and which recharges from a standard 120-volt outlet. I wasn’t entirely surprised when I saw it parked in a Microsoft parking lot a few weeks later. Its owner (the first in Seattle) works in my division, a fact I learned when another curious soul sent an email to the entire division asking who owned the “amazingly cool electric car.” The owner reports many similar inquiries.
I guess this is one of the upsides of being part of a community of early-adopter technophiles: When new technology is green technology, there are people here willing to embrace it. As a company, Microsoft has an informal “version 3.0″ policy: When it commits to a new product, it plans to see that product through several versions. Even if it flops the first time out, Microsoft will give a product another chance and will stand by it until it sees the success the company thinks it deserves. I like to think that this same attitude of confident investment in the vision of a sustainable future extends to some of its employees’ attitudes about technology and the environment: We’ll put our money where our mouths are and stand up for the Right Thing until other folks see things the same way, too.
Tomorrow, the bus!
Friday, 3 Nov 2000
SEATTLE, Wash.
The results of the bug bash are in. Our lead developer has gone through and “triaged” the bugs we found yesterday. After culling out the duplicates and the ones that, on further reflection, aren’t bugs at all, he’s sorted them by their importance. Some of them we need to fix now, because they’re blocking people from using whole features of the product. Others, we should fix soon: Most of the crashes and other nasty things that detract from the user experience have wound up in this category. And the remainder, we’re going to fix later, as in either sometime next year or never. Welcome to software development, where the perfect is the enemy of the shippable. We’re going to ship with bugs; this is just the nature of software, and most of the development process consists of a carefully applied pragmatism about which bugs to fix.
How did I come to believe this? In younger days, I made fun of Microsoft and laughed at the bug tales. And now here I am, apologizing for the bugs in our software and everyone else’s. I guess the first reason is that any extended amount of time spent programming breeds a sharp cynicism about technology. I know what can go wrong with software: I’ve been there, made those mistakes myself, seen some incredibly smart and diligent people make them. It’s a minor miracle when your code runs, a major miracle when it does what you expect. It’s the marketers who talk about software revolutionizing the world; as a programmer, I tend to see it more as an issue of users taking the software, adapting to its quirks, working around the problems, using it in ways the designers never anticipated.
The best bug I fixed today took place when a DHTML behavior’s response to a notification caused another behavior to reentrantly destroy the first while another notification was pending. The details aren’t important, except in their sheer number: This was a problem caused by a proprietary Microsoft implementation of an industry-accepted response to the extensibility issues caused by the limitations of a standardized syntax for manipulating the strange structures required by HTML as it evolved during the early growth of the web. My daily routine consists of figuring out which strange restrictions we need to live within, then figuring out creative ways to live within them and still get something done.
It’s a gigantic puzzle, and sometimes the pieces even fit together. Figuring out what’s going on in the interactions of a handful of components can be breathtaking. It’s beautiful in a Rube Goldberg kind of way, like abstract mathematics in drag. The really great programmers are the ones who can grasp the complicated virtual ecosystem of a program, who have an intuitive feel for the way it all hangs together and the effects of local changes on remote parts of the system, the ones for whom the program comes alive in the same messy and wonderful way we think of “real” living things.
And that’s the real reason I’m here and willing to live with bugs. Computers aren’t about to replace reality or supplant humanity, but neither are they purely tools for mundane goals. Used properly, technology has an influence on the way we lead our lives and think about the things we do.
Take this diary. I’ve had exchanges with half a dozen readers this week on issues ranging from SUV ownership among Microsoft employees to the Energy Star program, and I have an inbox full of other messages to respond to. And I’ve done all of this while working my normal job — indeed, that’s part of the point of this exercise. There’s nothing fundamentally new in the picture — job, public diary, conversations — but the elements are being recombined in a new, and I think exciting, way.
A friend at work recorded herself playing the piano a few weeks ago and sent me a link to the MP3s. I listen to them while coding. Within a couple days of the first article on the mere possibility of such schemes, thousands of people had pledged to swap their Gore and Nader votes to help out the candidates in the states where their votes would do the most good. If you need the complete text of New York State’s labor laws, they’re just a few clicks away.
I don’t think there’s very much that computers, taken alone, make possible. But there’s a lot that they make feasible, a lot of new possibilities opened up by reducing the obstacles between thought and action. Nothing’s guaranteed, and there’s a lot of work involved in appropriately exploring those possibilities. But still, having a few more options open can’t hurt.
