After leaving Google, many engineers miss the developer tools. Here's one ex-Googler's guide to navigating the dev tools landscape outside of Google, finding the ones that fill the gaps you're feeling, and introducing these to your new team.
Many years ago, I did a brief stint at Google. A lot has changed since then, but even that brief exposure to Google's internal tools left a lasting impression on me. In many ways, the dev tools inside Google are the most advanced in the world. Google has been a pioneer not only in scaling their own software systems but in figuring out how to build software effectively at scale. They've dealt with issues related to codebase volume, code discoverability, organizational knowledge sharing, and multi-service deployment at a level of sophistication that most other companies have not yet reached. (For reference, see Software Engineering at Google.)
In other ways, however, Google's internal tools are awfully limited. In particular, nearly all of them are tightly coupled with Google's internal environment. Unfortunately, that means you can't take them with you when you leave.
The Google diaspora has seeded so many other organizations with amazing talented people who bring lessons learned from working inside one of the world's leading technology organizations. But adapting to programming outside of Google can be tough, especially when you've come to rely on tools you no longer have at your disposal.
Over the years, I've learned from my own experience and the experience of lots of others who have left Google. Many of Sourcegraph's early customers began with an Xoogler missing code search after leaving Google. I worked closely with these people to understand the gap they were trying to fill, so that we could build Sourcegraph to meet their needs. Over time, patterns emerged in terms of how ex-Googlers sought to introduce new dev tools into their organizations, inspired by their experience with dev tools at Google. Some were successful and others were not.
I thought it would be helpful to write a guide to dev tools outside of Google for the ex-Googler, written with an eye toward pragmatism and practicality. No doubt many ex-Googlers wish they could simply clone the Google internal environment to their new company, but you can't boil the ocean. Here is my take on where you should start and a general path I think ex-Googlers can take to find the tools that will make them - and their new teams - as productive as possible
If you recently left Google to join another company, you probably have this overall sense of frustration that you're not as productive as you used to be. You feel you need to change something, but what is it? As a first step, you should think about what you do day to day and identify where the pain is coming from.
Both inside Google and out, the software development lifecycle looks something like this:
At every stage in this process, there is typically a tool that anchors the developer experience. Tools shape your work cycle and have an immense impact on your productivity.
To improve your productivity, you need to find better tools. There's a useful GitHub repository that identifies nearly every single tool inside Google and its closest comparables outside of Google: https://github.com/jhuangtw/xg2xg. This list is comprehensive, but a bit overwhelming. So where do you start?
In your first month, don't try to change anything. Just listen and learn the ropes.
As a new member of the team, you likely don't have the influence or authority to change all the tools your team uses. Moreover, you also lack knowledge- knowledge of how and why your new team behaves the way it does and why it uses its current set of tools. Simply copy-pasting Google internal tools is not necessarily going to work for your new team. So learn what is working for your new team along with what isn't.
I believe that code search is usually a great tool to start with. Yes, I am the cofounder of a code search company, so of course I would say that, but here are my reasons - if these don't resonate with you, then I recommend skipping to the next section!
If your new company has more than a few teams in the organization, you're likely dealing with more code that you can reasonably grok as an individual person. And even if you're working in a much smaller company, chances are you're pulling in a ton of open-source code through your dependencies. This is all code that you will need to dive into at some point, when building a new feature or tracing the source of some critical bug.
Given the scale of code that nearly every developer has to deal with these days, it's no wonder that the lack of code search can quickly slow your development velocity to a crawl.
When evaluating code search engines, there are a few things to consider:
Here are the common code search engines we've seen in use:
Another good early area to target is monitoring. Every engineer at some point has to deal with a production issue. Production is a very different place than development - you can't just set a breakpoint or add a printf and see the effect in seconds. Making updates to production is expensive along multiple dimensions: compute resources, developer time, and worst of all, pain to your users and customers.
Deployment has changed a lot in the past 5-10 years. Microservices, Kubernetes, moving to the Cloud - these are big shifts in how companies deploy software. Many companies have adopted these new paradigms and technologies, but they have not yet updated their monitoring infrastructure to make debugging in these new production environments easy.
Fortunately, there have been some great new open-source tools and companies in recent years that have vastly improved the state of monitoring and observability in the world outside of Google.
Monitoring is a bit trickier to introduce than code search, since it has to be integrated into the production environment. This often involves changing the deployment environment, which probably means persuading the team that controls the deployment environment. It may also entail adding instrumentation code, which involves submitting patches to the various teams that own the code being instrumented. However, it is still easy in the sense that introducing a new tool doesn't require anyone to change existing habits. People are free to use the new tool or not, which eliminates a strong source of objections when you're trying to get the tool first deployed.
Introducing code search and monitoring doesn't require asking anyone on the team to change existing workflows. Changing the code review tool, however, does.
Chances are that if you'd been at Google for awhile, the way that code review is done outside of Google has struck you as a little weird. GitHub Pull Requests is the most common code review tool, but ex-Googlers usually have a few complaints about it:
The closest thing to Critique you can get outside of Google is Gerrit. Gerrit began life as a fork of Rietveld, which itself was an open-source fork of Google's original code review tool, Mondrian. It should therefore feel very familiar, as it descends from a line of tools that were created to support the exact way that Google does code review.
Phabricator is another code review tool that ex-Googlers often prefer to GitHub Pull Requests. Phabricator began life as Facebook's internal code review tool and was subsequently open-sourced and released to the outside world. There's also a company behind it, Phacility, that offers hosted instances and support, in case you don't want to be on the hook for maintaining your own instance.
Another tool worth looking into is Reviewable, created by ex-Googler Piotr Kaminski. Unlike Gerrit or Phabricator, it is cloud-only, but may offer the code review experience that's closest to what is done inside Google today.
When selling the benefits of Gerrit, Phabricator, or Reviewable to the rest of your team, it's important to identify the existing pains the team is feeling with their existing code review tool. Here are how some common pain points are addressed by switching from a GitHub-Pull-Request-like tool to a Gerrit-like tool:
Gerrit, Phabricator, and Reviewable let you closely approximate the general review flow that you had inside of Google, but one thing that neither provides is code intelligence. If you're missing code intelligence in your current code review tool or find the GitHub PR code intelligence lacking, try the Sourcegraph browser extension. This connects to a Sourcegraph instance to provide tooltips, jump-to-def, and cross references during code review. It works with GitHub PRs, GitLab MRs, Phabricator, and Bitbucket Server. Support for Gerrit is on the way.
The most intractable part of the software development life cycle is often CI and the build system. This is because understanding the build often involves understanding every piece of the overall codebase in a fairly nuanced way. Speeding up the build is something that various people try to do over time, and so the build code accrues a growing set of hacks and optimizations until the point is reached where the number of people who actually understand enough about what is going on to make a change with zero negative consequences is very small.
In short, the build system is often a big giant hairball, and one that you should be wary of trying to disentangle before you pick off the lower hanging developer productivity fruit. It may be tempting to tackle this earlier, because Blaze was worlds better than what you're using now and Google has even helpfully open-sourced a derivative of Blaze called Bazel. But Bazel is not Blaze -for one, it lacks a massive distributed build cluster that comes free alongside it -and the world outside of Google is not Google.
Bazel is not a silver bullet. When Bazel was first released, many open-source projects in the Go community switched to using it in favor of the standard Go build tool. However, within a year, many of these switched back due to complexity of use, unfamiliarity in the rest of the Go community, and the fact that builds seemed to actually be slower with Bazel. Since then, there have been major improvements to Bazel's support for Go, but you need to rigorously evaluate what improvements you'll see if you switch over to it.
In order to do this rigorous evaluation, you'll want to have plenty of other great dev tools already in place. In particular, you'll want to have great code search, so you can actually dive into the build scripts in various parts of the codebase and understand their ins and outs. You'll also want to have a great code review tool in place, because changing the build system is going to be a complex change that requires approval from many different engineering teams.
Once you're ready to slay the dragon, you should understand there are a number of build tools in addition to Bazel that are designed to enable scalable builds in large codebases. These include:
There's also YourBase, which is not a build tool, but a CI service started by ex-Googler Yves Junqueira to bring super-fast and scalable builds to the world outside of Google, independent of what underlying build tool is used.
Google prioritizes developer experience and developer tools in a way unlike most other companies. Googlers and ex-Googlers have the benefit of firsthand experience of using first-class dev tools that add a huge amount of leverage to their natural talents and abilities.
One of your competitive advantages after leaving Google will be to apply these experiences to bring great new dev tools into your new organization to boost your own productivity and the productivity of your teammates. By using these tools to spread effective best practices for developing software at scale, you can bring one of Google's key competitive advantages - the effectiveness of its engineering organization - to your new company.
Building software at scale is hard. As everyone who has read The Mythical Man Month knows, you can't get better software just by hiring more engineers. You need better tools. Just as software is a multiplier for the productivity of end users, dev tools are a multiplier for the productivity of the people who build the software. So if you truly believe in your new company's mission, make it one of your priorities to use your special knowledge as an ex-Googler and bring them the best developer tools available.
Try out Sourcegraph. Get started searching your code by self-hosting Sourcegraph - free up to 10 users. Or try Sourcegraph Cloud to easily search public, open source code.
Please feel free to ask us questions either via posting on Twitter@sourcegraph or sending an email to [email protected].
Beyang Liu is the CTO and co-founder of Sourcegraph. Beyang studied Computer Science at Stanford, where he published research in probabilistic graphical models and computer vision at the Stanford AI Lab. You can chat with Beyang on Twitter @beyang or our community Discord.
With Sourcegraph, the code understanding platform for enterprise.
Schedule a demo