Google is famous for its perks, and rightfully so. They have the best perks of any place I’ve ever worked, even better than SGI in its heyday. It seems like Google really wants to eliminate anything that might distract people from doing great things.
It’s also possible that they just want to be nice to their employees, and I found an argument for that: heated toilet seats.
While I haven’t done a rigorous statistical analysis to determine distribution, almost all of the toilets at the Googleplex that I have sampled are high-tech megafunction toilets: the kind that can spray your privates clean and then blow them dry.
The first time I walked into a stall, I rolled my eyes at how over-the-top the toilet was. I mean, how necessary is it to have megafunction toilets?
Then I sat down and discovered the seat was heated, and to my surprise, I found that I had a very visceral response. It was comforting. I suspect that the seat is set to body temperature, and I bet that I have very strong associations of comfort attached to body heat on my butt. I wanted to just sit on that nice warm seat for hours. This argues against the perks being there to improve productivity.
I haven’t tried the toilets’ wash and dry cycle yet — I’m afraid to. After all, I do need to get some work done.
I have such a sense of liberation! I have no homework tonight that I should be working on!
I guess I’ve been kind of busy for the past three years — first Jim was in school, then I was taking prerequisites, then we were moving, then I was looking after my mother, then I was studying studying studying, then we were moving, then I was getting settled at my summer job… and now I have no homework! It’s wonderful!
I forgot to mention last night — of course it would be great to allow people to share to-do items, in much the same way that people can share calendars with Gmail. For example, it would be great to be able to put “buy new laptop for Ducky” on my husband’s to-do list.
Last term, I wrote a to-do list manager in Scheme for a class project. I have been frustrated with all the to-do list managers out in the world, so I finally wrote my own.
(OSAF‘s Chandler might have some of the features that I want, but it’s heavierweight than I need and isn’t really ready for prime time yet.)
The problem with most electronic to-do list managers is that they accumulate way too much stuff. I write down all the things I need to do, and then I am overwhelmed by the volume of tasks. Tasks that aren’t important or urgent or that I can’t work on right now end up getting in the way of seeing what I need to do right now.
I want to record that I need to take the car in for servicing in about three months, but I don’t want to see it until about three months from now. I want to write down that I need to paint the house, buy paint, buy rollers, and move furniture, but I don’t need to see the “move furniture” task until after I’ve bought the paint and rollers.
In my to-do list manager, tasks are presented in a hierarchical structure, and I gave myself three different methods for hiding things:
- Hide completed tasks
- Hide supertasks (i.e. those that I can’t start on until some other task is finished)
- Hide deferred tasks (until some later date (specified on a per-task basis))
(I of course also have the option to show completed tasks, show deferred tasks, or show supertasks.)
If I hide completed, deferred, and supertasks, then what is left are the things that I can work on right now.
Note that there is no option to mark supertasks “done”. My Scheme version also doesn’t let you defer tasks with dependencies, but I haven’t decided if I am going to keep that or not.
I had thought that it would be nice to have separate importance and urgency fields, as those really are different things. Answering a ringing phone is very urgent but probably not very important (voicemail will pick it up); writing a will is very important but (hopefully!) not very urgent.
It turned out, however, that I didn’t really miss having distinct urgency and importance fields; if an item wasn’t urgent, I just deferred it. Presto, out of sight, out of mind.
One thing that I hadn’t originally planned on, but which I did and liked, was to change the color of tasks based on how important they were rated. Very important tasks were deep blue, and as the tasks got less important, they got more and more washed out (less saturatated).
My Scheme version has a text box on the main page for quickly creating new tasks, but there was a cruical flaw: no way to specify which task was the parent task. I thought about showing an arbitrary number next to each task in the list of tasks, and using that to specify the parent, but that didn’t seem appropriate. Really what you need to be able to do is drag-and-drop tasks to different places in the list.
One thing that I thought of doing but didn’t get around to was to be able to expand/collapse branches of the tree. Thus if I just don’t feel like working on upgrading the family IT infrastructure today, I can collapse that task (and all its subtasks) down to one line.
I’ve started porting my to-do list manager, making it an AJAX application so that I can host it on my site at Dreamhost, but I’m not going to finish before I start at Google, alas.
Someday I’d like to integrate it with a calendar. (The Google calendar has an API; maybe I could connect to the calendar.) Someday I’d like to add optional at-location and with-person fields, so that I could ask what tasks I can do at e.g. the hardware store (like “buy paint”), or with e.g. Jim. But that will probably have to wait until after the summer is over.
On Monday and Tuesday, my husband, my mother, and I drove from Bellingham, WA to Oakland, CA. Mom was going down for a party and was interested in more drivers; Jim and I were interested in cargo space in her minivan, as we are moving to California for the summer. (I have a summer job at Google that, incidentally, I am hugely excited about.)
It was interesting how we didn’t talk much. Partly we were tired. Mom wasn’t feeling well. I was tired from final project frenzy, packing our stuff, and then helping Mom pack the next day. Jim was tired from packing and packing.
Partly it was hard to hold a conversation. The fan and/or air conditioner was blasting most of the way — it was quite a warm day. Add in that Mom is hard of hearing, and three-way conversations were tough.
And with Jim and I, we just didn’t have much to talk about. We’ve been together for ten years, had just spent three days near each other practically 24 hrs/day, and there are only so many observations one can make about how the terrain changes from forest to savannah to scruff while going from British Columbia through Oregon to California.
I used to worry about running out of things to say to Jim, but it was okay not talking. It wasn’t that we were avoiding talking to each other — we weren’t mad at each other. We weren’t frustrated at trying to find common ground or common interest. Rather, we are so much a part of each other’s lives, so intimately tangled that there just aren’t that many things that the other doesn’t already know about.
About the only thing we did talk about at length was Webfoot Maps. Because I’m going to Google this summer, I can’t work on my maps. Google owns my brain this summer.
I’m fine with trading working on my maps for working at Google. However, I get approached once or twice a month by people who want me to make a Google Maps mashup for them. Given that my husband is pretty unscheduled so far this summer, it seems like it would be useful if I could do a mind-meld with him so that he can help these people with their maps.
Thus I’ll be working at Google and Jim will be doing Google mashups. Avoiding the conflict-of-interest will be annoying.
I am not worried that we’ll be able to do it, however. This is the husband that I made sign an NDA before I would tell him what I did at Interval Research, after all. Two weeks after the Google Calendar showed up in my Google Trusted Tester account, I finally mentioned to Jim, “it’s too bad that you’re not in the Google Trusted Tester program, because there’s something that I’ve been testing for two weeks that I think you’d really like.” He responded, “I am in the Google Trusted Tester program. You mean you’ve been testing GCal too?
So I’m sure we can keep a wall between our work, it’ll just mean we’ll have to find other things to talk about.
I am imagining a world with consumer-level grid computing. For example, imagine a maps server where in order to look at a map of Fargo, ND, you have to also serve those maps to other people who want to see Fargo, ND.
BitTorrent has shown that people are willing to exchange some of their resources for something that they value. BitTorrent uses bandwidth resources and not compute resources, but I don’t see why you couldn’t set up an application that used some compute resources as well.
I think of this not just because I’m working on a class assignment on grid computing, but also because I have a resource-pig of an application, namely my thematic maps of U.S. Census Bureau information.
While I haven’t had a lot of time to devote to improving the performance, I figure that my server can only handle about 2000 users per day. (I’m only getting about 100 users per day, but flatter myself by believing that when the world discovers the maps, it will shoot up.)
My husband observes that rendering Wikipedia pages into HTML is another data- and compute-intensive job that could be distributed. What if looking at at some Wikipedia pages meant that you downloaded the raw format, rendered the page as HTML, and then served the HTML to other people who wanted to see it?
It might not be practical for Wikipedia: suppose I want to read about geoducks, and Bob is serving that Wikipedia page. Wikipedia has to send me enough information for me to find Bob. It might be that the ratio between the amount of work Wikipedia saves by having Bob serve it just isn’t worth the extra overhead to run a distributed application
Another possibility would be render farms for amateur animated movies. The more cycles you donate, the more frames you render, and the more of the film you get to see!
I have to believe that someday we will see distributed consumer applications that use both computing and bandwidth resources.