The 20% BoF session at CFP last night was fun.

The most interesting thing for me was the questions about how 20% time works.  Hopefully I can repeat some of them and the answers here. 

How will this scale as Google gets bigger? I don't know.  What I've seen of Google management is that they are committed to keeping the same atmosphere as the company grows.  As problems crop up (and I'm sure they will) I'm sure that Google will look for "non-traditional" solutions.

How do you track this?  What if someone is spending 30% of their time on a side project? There isn't really official tracking of this sort of thing.  It really comes down to trust of the employee.  At the end of the day (or year) you have to list what you've accomplished for your review.  If you've wasted your time then you have nothing to talk about on your review.  Keep in mind that failures aren't the same as doing nothing -- valuable knowledge is gained.

How do you make sure that people are using the time wisely?  How does this relate to the goals of the division/group/etc? Well -- that is just it -- you don't know if the time is being used wisely.  You want the engineer to do what he/she thinks is the next big thing, not what management thinks.  Most people want to do the next cool think that will fire people up both inside and outside the company and may end up making Google money.  If you think that the best way for you to add value with your 20% time is to slack off and do nothing than that really speaks for itself.

What is the goal for this?  Isn't this just a morale booster? For some people I'm sure that this is just a morale booster.  My impression, from the short time I've been at Google, is that 20% time is more than that.  Most people want to add value by doing stuff that is far easier to do inside someplace like Google than anywhere else.  My feeling is that I want to use the time wisely to add value in new and unexpected ways for the company.  There is a pretty fluid path for these projects, if they show promise, to get funded with full time engineers.  That path is critical if a 20% project ends up being super successful.

Where do you find 20% to spare? I can't cut 20% of my features or slip my project by 20%.  I think that there is more time then you think.  If you do "research" in  a lightweight way like this perhaps you can take the time elsewhere.  Also keep in mind that happy engineers are more productive engineers.  And stop going to so many meetings -- and if you do have meetings, don't allow people to sit in the back and read their email.

What about using 20% time as a reward for exceptional performers?  What about taking away 20% time for those who don't use it wisely? I'm not a huge fan of these ideas for a couple of reasons.  First, some of the best ideas come from people who are looking at something with fresh eyes.  If we make it a reward it may be too late to capture that.  As for punishing people, I would think that this would have a chilling affect.  We want people to try wacky things that no one else has thought of.  Having some missteps is bound to happen and we don't want people to be afraid to experiment.

Why 20%?  Why not 50%? or 10%? I'm not sure.  My guess is that either someone took it out of thin air or some math PhD at Google has a proof somewhere.  If anyone reads this and knows I'd love to here the answer.

[Added in response to comment from Jack Krupansky]
How do you allocate the time?  Is it one day a week?  1.6 hours a day? 2 weeks a year and a weekend a month? From what I've seen so far, it is up to the engineer to figure this out.  People can save it up and use it a month at a time if they like.  My personal strategy is to spend some a week or two really getting some momentum behind something and then switching to a more integrated schedule.  As project hit shipping mode and such these things may take a back seat while the time accrues.  Keep in mind that no one is watching over your shoulder with a stopwatch.
[End addition]

One thing that I want to emphasize (and it came up multiple times last night) is that a lot of this comes down to trust.  One of the big parts of the secret sauce here is that Google really trusts its engineers and, from what I've seen, the engineers live up to those expectations.

I'm going to be part of the "20% Time" at the 15th Annual Conference on Computers, Freedom and Privacy tonight.  It is going to be tonight at 9pm at the Seattle Westin in the Olympic room on the second floor. 

It looks like a good group.  Dare is going to be there.  I look forward to talking with him and others about 20% time and my experiences at Google so far.  If you want to get started, check out my original post on the subject and Dare's response.

Wow -- Slashdot again.  That is always fun.  I'm always amazed at the flow and I love the influx of comments both on Slashdot itself and on my blog.

One comment was from "Dave B" asking me to elaborate on some theories as to why C++ hasn't developed the same set of libraries that other environments such as Perl, Python, Java, C#, etc. have.  Here are a bunch of ideas.  I have no empirical data but just gut feeling.

First off, we must examine the philosophy behind different environments.  I may be making broad generalizations here, but stay with me:

• Java and the CLR (C#, VB.Net): "Make the easy things easy and make the hard things possible."  These environments try to avoid the inherit complexity that C++ has.
• Python and Perl (and perhaps others that I have no experience with): "Make my life easier -- I don't want to spend more time writing this fast and dirty script than I have to".  Above all else users here prize being able to get something useful done now.
• C++:  "Give me all of the fundamental tools and building blocks and I'll do it myself."  Power trumps all.  Templates and the way that people use them are a great example of this.
• (I'm sure that there are more categories for things like Lisp and Smalltalk.  Filling out that part of the list is left as an exercise to the reader)

With this difference in philosophy it is no wonder that there is such - ahem - diversity in the C++ library space.  Here are some more thoughts.

1. There *are* good sets of libraries out there for doing stuff.  One example would be boost.  These have limited uptake I think for a couple of reasons.  First, downloading and building these is a pain.  They don't already come with your compiler.  Second, these libraries are either laser focused on a specific area (libtiff?) or are more collections/algorithms base.  Boost, for example, doesn't include an easy interface for dealing with zip files or for writing a single threaded select loop based network server.
2. The C++ standards process is slow and ponderous.  While there are downsides to these environments being controlled by a single entity or a focused group, but the end result is much faster advancement of the language/runtime/environment.
3. There are so many ways to do things in C++ that invariably arguments come up over how to do something. Even within one company, people can't agree.  For some reason C++ programmers seem to be more stubborn on a lot of these points.  The result is that everyone just writes their own thing.
4. It is way to easy to write super hard to use APIs in C++.  Templates make this problem worse.  If you do this stuff day in and day out you get to know it and it makes sense to you, but most C++ libraries are hard to use on a casual basis.  I think that there is a disease where people think that it is their obligation to use templates in as confusing a way as possible.  Any time a class has a templated base class, you are going to go right over the head of 95% of the developers out there.
5. Opinions are divided around RTTI and exceptions.  Code written to deal with exceptions doesn't interop well with code that turns exceptions off.  Almost no one turns on RTTI.  In any case, the result is that these are walls to reusing code.  If you don't use exceptions you have to come up with your own error code space or use platform concepts like HRESULTs.
6. Everyone likes to replace their allocator but there is no standard way to do that for various libraries.  If library lets your replace the allocator it is usually something that has to be done on a library by library basis.  So many problems would be solved if the CRT and language had a way to do global hooking of the malloc/free and new/delete at the link level.
7. DLLs, shared libraries, compiler differences, differing STL support all make it harder to do things in a standard way.
8. Windows doesn't have a good standard build system.  The upshot is that libraries are only on Unix or the Windows build is cobbled together.  Environments like Cygwin are really poor compromises.  It would be better for everyone if the unix make/configure systems would be updated to work natively on Windows also. It isn't like Windows can change anytime soon without breaking the world.  The MS compilers are now free -- the make system is really the only missing part now.
9. Each codebase has its own way for deciding how header files are included.  Figuring stuff like that out is just a headache.
10. Lots and lots of different string types.

Does this hurt C++?  Probably not -- it is just targeted at a different audience.  When you need the power you need the power.  If you have to hunt around for example code or a helper library and somehow jam it in to your build system and project then that is the price for playing the game.

Just some random thoughts on a Saturday morning...

Tony posts some comments about 20% time at Google and how it might not work at other companies like MS.  Scoble responds based on how he *thinks* 20% time works.  In the comments Tony backs down because he doesn't have specific knowledge of how things work at Microsoft.  I'd like to add some more comments to this conversation.

The Google model of development is more than just information sharing and the ability to switch projects.  Here are the important points as I've seen.

1. There is, by and large, only one code base at Google.  This has many advantages.  Most obvious is that it is really easy to look at and contribute to code in other projects without having to talk to anyone, get special permissions or fill out forms in triplicate.  That is just the tip of the iceberg, though.  Having one codebase means that there is a very high degree of code sharing.  Need to base 64 encode/decode something?  No problem, there is a standard Google routine for that.  Found a bug?  Just fix it and check it in after getting it code reviewed by a documented owner.  One of the reasons that environments like Perl, Python, C#, Java, etc. flourish is that they have large and well through out libraries of useful code.  For a variety of reasons, C++ has never had this.  (I could theorize but that would be off topic.)  Google has solved this problem by building up a large library of well documented and easy to integrate code.  This not only lowers the bar for new projects but makes it easy to switch projects as you don't have to learn new conventions.
2. Switching teams at Google is a very fluid process.  An engineer can be 40% on one project, 40% on something completely different and 20% on his or her own thing.  That mix can be adjusted as project requirements change.  Switching groups should also not have an affect on your annual review score because of arbitrary team politics.   Joining a new group is more about find a good mutual fit then going through HR and a formal interview loop.  When there is an important project that needs to be staffed the groups and execs will evangelize that need and someone who is interested is bound to step up.  If it is critical to the business and no one is stepping up (I don't know if this has occurred or not) then I imagine it would go come down to a personal appeal by the management team.
3. The intranet in Google is super transparent.  Teams are actively encouraged to share the most intimate details of their projects with the rest of the company.  This happens through tech talks, design docs, lunch table conversations, etc.  When two teams are doing similar things, people start with the assumption that they must have their reasons and that the situation will be worked out in time.  There isn't a huge push to over optimize and have only one solution for each problem.  This means that there isn't an adversarial relationship between teams that can lead to long standing animosities and information hiding.
4. There is a big difference between pet projects being permitted and being encouraged.  At Google it is actively encouraged for engineers to do a 20% project.  This isn't a matter of doing something in your spare time, but more of actively making time for it.  Heck, I don't have a good 20% project yet and I need one.  If I don't come up with something I'm sure it could negatively impact my review.
5. The intrapersonal environment at Google is very energizing. When someone comes up with a new idea, the most common response is excitement and a brainstorming session.  Politics and who owns what area rarely enter into it.  I don't think that I've seen anyone really raise their voice and get into a huge knockdown drag out fight since coming to Google.

Can 20% time work at other companies? I'm sure that there are going to be others that try.  However, I think that it is important to realize that it is a result of an environment and philosophy to development more than a cause.  I don't think that it is something that can be imposed in an independent way.

I'd like to stress that these comments are my own and aren't any sort of official word from Google.  Please don't draw any grand conclusions of corporate strategy and such.

A while ago I needed to do some stuff in Photoshop that wasn't easy to do from the interface.  I decided to automate it from C#.

John Deurbrouck just sent me a link to a page where he has decoded some more of the wacky photoshop ScriptListener output.  He even has a routine to drive PS to convert a RAW image.

Check it out here and contact John if you are interested in moving the knowledge in this area forward. 

Very cool, John!

I have this urge to go retro, switch back to film and dig out my darkroom stuff.  I think the real motivation is to buy an outrageously expensive Leica customized with my engraved signature on it.  Try it out for yourself here.  My camera came out to $4020.  I assume shipping is extra.  I know that a lens is.  "Add to my cart."

[From Mike Johnston's column over at the LL]

Okay -- when people ask me to update in my comments it has probably been too long. I don't have anything super pithy to say, so I guess I'll just use the shotgun approach:

• Everything is going good with the baby.  Rachel is starting to get big!  We are reading to her every night and trying to get our lives in order so that we are ready.  We are almost through "The Witch and the Wardrobe." We've been reading a chapter each night.  After we are done we will continue reading the rest of the Narnia stories out loud to each other and the baby.  I know she can't understand what is going on but I want her to know my voice.
• We went to Chicago last weekend.  My Sister threw Rachel a baby shower at the Ritz-Carlton downtown.  The service in the garden was wonderful.  My sister's two girls had an especially great time.
• I've been buying some cool stuff.  The first is my terabyte array for my main computer.  I ended up with five 300GB SATA drives in a cage running software RAID 5.  That comes out to ~1.2TB after you factor out the redundency.  I didn't get a dedicated machine to keep costs down.  I can always do that later and move the drives over.  Everything has been running like a champ.
• Also to prepare I picked up a Canon SD300.  This is an update to our aging S100 (the original digital Elph) point and shoot.  It is amazing how much these things have improved.  I loved the S100 but the SD300 is so much better.  My favorite feature is that it can do 640x480x30fps movies until the card is full.  For short clips there is no reason to get a video camera.  I also ordered a 1GB SD card but those are apparently sold out everywhere.
• I'm thinking about getting a new car as the baby approaches.  I want to take a serious look at the Honda Element.  Having an interior made of rubber that you can hose down sound like a good idea with kids. Plus, it is only $21k completely decked out.
• Between Rachel and me, we've recently read the entire Raymond Chandler catalog.  I love his writing.  You can just feel vintage LA ooze from the pages.
• I haven't been taking many photos lately.  I have some more stuff from the Arizona trip that I should post.  I haven't put up any of my slot canyon photos yet. 
• Work has been going great.  I still can't talk about what I'm working on but I really feel like I've made it over the hump of moving to a new environment and I'm starting to be really productive.  The contrast between Google and Microsoft couldn't be greater (at least from an engineer's point of view).  No meetings and few politics means that I spend much more time coding.  I've written more code so far at Google than I have in the last year at MS.  (That really isn't apples to apples as I spent most of my time in the last year at MS writing specs.)  I totally feel like I'm in the loop on my project without having to play political games.  I guess that is what happens on smaller teams.
• I'd love to have some intelligent comment on the whole AutoLink/SmartTags thing as I've been around for both.  However, I just don't see a clear cut answer here, unlike some. 
• Finally, Numa Numa.

That's it for now.

I'm not sure who these guys are, but this sure is funny: http://www.gizoogle.com/.

Congrats to the Picasa guys on shipping v2!  I know that they've been working super hard to get this out the door.

If you do anything with photos and haven't had a chance to play with Picasa, you really owe it to yourself to check it out.

Here is a photo that I didn't take:

Good news!  We are having a baby.  My wife is pregnant. I know that people usually say "we are pregnant" but she is the one that went through the nausea and has to deal with carrying the baby around for 9 months.

The ultrasound from this morning looks good.  It is still pretty early yet (she is 17 weeks along -- due date is June 21st) but the ultrasound tech said that it looked like our baby is a girl.

Now I have to figure out how to be a father!