Photo: Flickr / Marcin Wichary
We’ve done our best to distill down his most salient points about being a Google engineer — and the counter-arguments from others.
It’s worth noting that Tipping was only at Google for about six months. But much of what he is saying does jive with what we hear from current and former Googlers.
You can read and contribute to the source code of just about every project at Google right now.
If you have spare time, you can make a contribution to a project you're interested in -- like Android -- that you aren't necessarily assigned to.
Because the culture is so open, and because anyone can access the code, engineers don't have a big reason to write excellent code.
Engineers at Google don't have sufficient ownership of their own code, Tipping said. The code still works, but it isn't as good as it could be.
Google does employ some of the best engineers, after all.
When Google has to solve a hard problem, it solves it with a smart approach, rather than a brute force approach.
Most of the engineering effort at Google is spent on 'superficial implementation,' Tipping said.
There wasn't much inclination toward solving fundamental problems -- like some of the important open questions in computer science research.
There's 'rigorous' unit testing and attention to 'low-level' code quality.
That means the code that is closest to the machine processing (that everything is built on top of) faces a lot of scrutiny before being pushed as an update. This ensures the process runs smoothly.
Low-level code faces a lot of scrutiny, but the same isn't as true for high-level coding.
Coding standards and reviews don't always catch problems and mistakes in high-level coding.
Google employs some very good programmers, but it also employs a few less-than-stellar programmers.
If you're one of the good ones, more employees and superiors will pay attention to what you're doing.
There are different kinds of programming -- functional programing and combinatory programming, for example -- that evaluate processes with different computational approaches. Some processes are more efficient at solving certain problems than others.
Most Googlers don't want to change their process though -- they'll hack together something that will solve a problem in their preferred approach/language instead of experimenting with a new approach.
The counter-argument to this is that Googlers don't want to spend time learning a new approach -- they just want to build.
Without being able to efficiently check in and check out code, most engineers would be frustrated and spend a lot of time waiting for their code and testing it -- not building and experimenting.
Luckily, Google has some of the best infrastructure in Silicon Valley -- so you can spin up servers easily and spend more time working on interesting problems.
The overhead of getting a task done was usually dictated by how complicated an API -- which lets you access data from a different application, like Google Maps -- was.
Most of the internal APIs at Google were much too complex, Tipping said.
When something needs to get done for a product at Google, it's prioritised. The order in which things gets done is efficient enough, Tipping said.
That means that the managerial structure of Google appears to be well-built.
Google has a lot of internally-built programming languages like Dart and Go.
Unfortunately, they don't solve any significant problems -- not even those coming up internally at Google. They don't solve open, fundamental problems in computer language research.
Any Google engineer has access to Google's servers and can spin up as much computing power as he or she needs to test something.
That's useful when you have a test program that isn't necessarily built efficiently, but you want to see if it works. You can also stress-test programs easily with a lot of computing power.
There's a 'pathological' love for Java, a specific kind of programming language, over other programming languages. Java is considered 'good enough' by Google employees for most problems, Tipping said.
But 'Java is, by many standards, not a powerful language and not something that makes sense as a mandate for solid, experienced developers,' he said.
Another Googler in a Hacker News thread said this was due to a network effect -- most programmers use Java, so that's how you get the most feedback.
Google employees are said to be given 20 per cent of their time to focus on personal projects. That can range from learning a new language to starting a new project.
Tipping spent his time learning machine learning, he said.
Tipping's own open source projects took a long time to finish, he said. Here's his whole experience:
'Technically, Google owns everything you write while you work there, even if it's on your own time and with your own equipment. However, they have a committee that reviews things you write and assigns copyright to you provided that they don't conflict with something Google is working on. My experiences working with this committee were completely positive, but there was often a two-month lag before I got an official reply from them. This uncertainty bothered me a lot, since I wasn't sure whether my project could be legally released as open source.'
It's still quite good for a 30,000 person company, Tipping said.
If you put together a clever hack to fix something, you're going to be rewarded and people will respect you.
This sort of goes with the whole 'be good and people will respect you' vibe at Google.
That being said, a lot of time is spent on bug fixes and superficial updates, he said. Less time is spent on fundamental problems and solutions to those problems.
Code was often needlessly complicated, he said. 'Gratuitous boilerplate and complexity were widely accepted,' he said.