Things I've Learned At Google, Part Two

I've spent the past 19 months working as a software engineer at Google. They have adopted a lot of great practices, some completely their own, and I certainly learned a lot from working them. I thought I would share some of the particular insights I had while working there.

This first post was about software engineering. This post is more about general workplace practices.

If you want to have the best software engineers, then hire smart people and treat them well.

I've worked at places in the past where they are good at hiring smart people, but then tend to treat them poorly. Then, they wonder why the leave in droves for companies, like Google, who aren't afraid to buy you a nice chair and keyboard.

If you want to have great employees, then you have to treat them like it.

Open source licensing is important.

Open source code is a lot harder than you'd think, and even the most competent software engineers will sometimes try to get away with not following the rules. The license implications in things like the GPL and AGPL are serious business. Before using any code that touches GPL or AGPL (or other similar licenses), educate yourself well on them, or designate someone at your company to be the open source czar to make sure you aren't messing this stuff up. It's not really hard or anything: it's just a little tedious, and incredibly important.

Shoes are optional.

I worked at mostly "business casual" places prior to Google, but Google goes straight for "casual", bordering on "who cares". And for all that, I never noticed it as a problem. Unless you are violating the health code, do what makes you productive and happy. (For instance, I am more productive when not wearing shoes, but wearing pants (or at least a kilt). YMMV.)

Working from home can be fine.

Personally, I work better in an office. But, my Google office is about 1 or 1.5 hours away. After a few weeks, I figured out a system where I could be very productive working from home — certainly efficient enough so that there is a net gain in productivity due to commuting time. So, I spent a lot of time at Google working from home, and did quite well. (Early on, I spent a lot more time in the office, as I was still bright-eyed and bushy-tailed and was still trying to understand all of Google's inner workings, and this required being able to communicate with my coworkers more.)

Don't be a gatekeeper unless it is really important.

As organizations grow, certain groups start to feel important, entitled, or some other emotion, and begin injecting themselves into every process in the business. Some of these are really important, like privacy and security. For instance, a lot of managers believe that they are not doing anything unless they change something, and so they sometimes like to start sticking themselves in processes they don't belong in.

My favorite instance of this at Google is that one of founders has to approve the application package of every single new hire (at least, for software engineers). Even though hiring is important, I am a little doubtful that his review does anything other than make him feel better.

Becasue of gatekeepers, you can end up with a giant checklist of people who have too much of a say in your project because someone in the past didn't have due diligence. This can really eat at the velocity of your project, especially small projects (where a just a few people have to deal with all of the gatekeeprs), and definitely at the morale of the team.

Google is large, and is brimming with gatekeepers. Which I find interesting, because Google has a really neat system for getting rid of gatekeepers: readability.

Let me explain readability. If you are new to Google or new to a programming language, most of your first code needs to be reviewed by an expert in that field — a Java expert for example, who can say that your Java code meets all of the standard guidelines to maintainability, readability, and general sanity. After a while, you will become recognized as an expert as well (through a formal process), and you won't need to have this be part of every review anymore.

Perhaps a solution to gatekeeping would be to have more readability-like things: if you've launched a few projects that tackled certain thorny areas very well, then maybe you now have "readability" in those areas, and we can trust you a little bit more, and remove some bureaucracy from your plate. It's an idea at least. But the moral of the story is: don't insert yourself into the bureaucracy and become part of the problem unless there is no other choice.

Gatekeepers are a symptom of trust and communication mismanagement. When your product is ready for launch or has made some significant progress, all of a sudden, a bunch of gatekeepers (like your senior managers) take an interest in your project. Some of them will have looked at your project in its early phases to greenlight the concept, but to many of them, they may not have ever heard of you before. And, especially at the very highest levels, they only have 1 bit of communication down to you: launch or cancel.

This low-bandwidth communication is bad, especially if they see problems with your product or direction, and unfortunately, you may have just wasted a lot of effort (perhaps months or years of engineering) on something that is going in the scrap pile. This is perhaps avoidable by trusting the management below you to make the right decision early on. A senior manager having so much drastic control over a project sends a mixed message about trust.

Writing is still incredibly important.

Don't get me wrong, I understood this pretty well before. But even at Google, writing is still important. For one thing, any large company probably has a convoluted promotion process, and Google's, while leaner than some, still requires a lot of paperwork. Paperwork means writing, and if you can't communicate effectively about your own accomplishments, then you are just not going to get promoted, at Google or anywhere.

I've seen people time and time again tell me that "they just aren't good at writing about themselves" — this has been nonsense every time. They were fine at writing about themselves, they just didn't like to. In which case, too bad: if you want to get promoted, then just do it.

If you don't write about it, it didn't happen.

Kids aren't nearly as good at computers as I thought they were.

While not strictly workplace-related, this is something fun I learned at Google.

While working from Google, I was often the token Google engineer that was paraded around for local high schoolers that we would do some outreach for. I would answer questions from "how does search work?" to "do they really let you drink at work?". It was rewarding and I really enjoyed talking with them.

However, they were all just terrible at technology, despite all that "kids these days" should be masters of all computers, cell phones, and whatnot. They should be tumblring circles around my desktop-loving self when it comes to, well, everything, but I'm pretty sure most of them couldn't program a VCR, or whatever the modern equivalent to that is. (For my younger readers, programming a VCR is perhaps the second most trivial "techie" thing to do in my generation, only slightly above having an alarm clock with the time set correctly (rather than blinking 12:00)).

I'm sure I learned more at Google, but those are perhaps some of the important things I felt I learned while working there.

I can't wait to see what I learn at my next job. :)