Kyle is a Software Engineer at Dropbox. He’s currently working in the Core Sync area in charge of the Dropbox Sync Engine and other related components. He was previously the tech lead of the Build Infrastructure team, the tech lead of the Android team at Dropbox, and a senior engineer at Google.

Kyle has been thinking about developer productivity for a while, and his tenure at Dropbox (~9 years) gives him a unique insight into the origins and consequences of some large technical decisions, the value of code review, and making developers more effective in general.

Listen on Apple Podcasts or Spotify.

Subscribe now

Share Software at Scale

We discussed technical migrations, test quarantine, the purpose of code review, multi-round code reviews, the popularity and community of Rust, the properties of Go, good software design, the design of the Dropbox sync engine, the role of a tech lead, and deciding between staying an IC vs. going into management.

Highlights

2:20 - Build Infrastructure at Dropbox. Dropbox has an in house CI Server that was written by David Cramer (CTO of Sentry). Dropbox’s internal CI Server might have been the first user of Sentry. How Bazel came about at Dropbox.

5:40 - Bazel might have been an overcorrection at Dropbox. The danger of copying Google for internal tools.

8:23 - The precision of Bazel and infrastructural investments to keep it running. Moving things into the Bazel world could be challenging.

17:30 - How should a decision maker decide between investing in a customized but potentially superior developer experience, vs sticking with open source tools or external best practices? For example: Git vs. Mercurial

24:00 - Enforcing the right amount of “best practices” on the rest of engineering.

26:30 - One way to think about developer tools in your organization.

33:40 - The issues you run into if you apply a systems engineering mindset to developer tools, compared to a product development mindset.

37:42 - What test quarantine is, and why an engineering organization needs it.

47:40 - Viewpoints on code review and how they’ve evolved over time. The consequences of not catching a bug in code review.

56:20 - Maintaining the reliability of applications that are being deployed on millions of desktop hosts and Android devices. User reports were often wrong.

62:30 - Being a long time language nerd, and the code design of a complex sync engine. Not using standard library hashmaps due to non determinism.

77:50 - A discussion on Golang.

88:00 - Contrasting Golang and Rust. Diffused benefits vs. specific benefits.

96:50 - Being a good tech lead, and deciding between staying an individual contributor, vs. going into management. Being smart vs. being obsessive as a reason for success in software, compared to other things. The difficulty of being a Tech Lead Manager (TLM).

Episode source