Validating ONLY with tests is basically flying the plane on instrumentation, versus being able to look out the windshield. Flying visually and by muscle-memory is both more efficient and safer, in conjunction with instrumentation. You’re much less likely to hit a mountain by mistake.
When you’ve been coding for more than twenty years, it can be difficult to recapture beginner’s mind, and explain how to think like a programmer to someone who is new to it. I remember an incident in college, when I had been coding for a comparatively short time, that crystalized in my mind the thought process behind writing code—what you might call the programmer philosophy.
It’s the responsibility of an engineering team to do what’s right for the company, not to advocate for the system they own. Engineering teams need to be oriented around a mission not a system to avoid narrow-minded decision-making.
Do you have a team at your company called the Kafka Team, or the HBase Team, or the Docker Team? Hmm, you may have screwed up. Don’t worry, there’s time to fix this.
Years ago at Dropbox we started the Magic Pocket team to design and build the block storage system of the same name.
At Dropbox, we run more than 35,000 builds and millions of automated tests every day. With so many tests, a few are bound to fail non-deterministically or “flake.” Some new code submissions are bound to break the build, which prevents developers from cutting a new release. At this scale, it’s critical we minimize the manual intervention necessary to temporarily disable flaky tests, revert build-breaking commits, and notify test owners of these issues. We built a system called Athena to manage build health and automatically keep the build green.
What we used to do
To ensure basic correctness,
Ever since we launched Magic Pocket, our in-house multi-exabyte storage system, we’ve been continuously looking for opportunities to improve efficiency, while maintaining our high standards for reliability. Last year, we pushed the limits of storage density by being the first major tech company to adopt SMR storage. In this post, we’ll discuss another advance in storage technology at Dropbox: a new cold storage tier that’s optimized for less frequently accessed data. This storage runs on the same SMR disks as our more active data, and through the same internal network.
The Lifetime of a file
The access characteristics of a file at Dropbox varies heavily over time.
As we laid out in our blog post introducing DBXi, Dropbox is building features to help users stay focused on what matters. Searching through your content can be tedious, so we built content suggestions to make it easier to find the files you need, when you need them.
We’ve built this feature using modern machine learning (ML) techniques, but the process to get here started with a simple question: how do people find their files? What kinds of behavior patterns are most common? We hypothesized the following two categories would be most prevalent:
- Recent files: The files you need are often the ones you’ve been using most recently.
Team growth requires giving people room to make mistakes. Figuring out which mistakes are just “papercuts” and which are critical is one of the most difficult challenges in engineering leadership.
We’ve all seen “helicopter parents,” hovering over their kids to catch them at the slightest inclination they might fall. We swear we’d never do that, that we’d give our kids room to grow and learn from mistakes. Then we become tech leads and turn into the worst kind of “helicopter leaders.”
I was certainly guilty of micromanagement. It started with code reviews, commenting on every minor issue I could find.