Learning from Giants #27
Learning from Giants #27
Product management Mental Models, Dropbox's massively scalable transactional data store, Investing in internal documentation, and Mutex by analogy.
👋 Hi, this is Mathias with your weekly drop of the 1% best, most actionable, and timeless resources to grow as an engineering or product leader. Handpicked from the best authors and companies.
Did a friend send this to you? Subscribe to get these weekly drops directly in your inbox. Read the archive for even more great content. Also: I share these articles daily on LinkedIn.
Product Management Mental Models for Everyone
"We should ship the 20% product that solves 80% of the problem."
Pareto Principle, ROI, Diminishing returns. We all overuse a few prominent mental models. Yet there is a risk to applying them uniformly to all decisions.
"You shouldn't rely on one or even a few mental models, you should instead be continuously building a latticework of mental models that you can draw from to make better decisions."
Sounds like you? Read on...
📗 Brandon Chu's Product Management Mental Models for Everyone describes and illustrates a dozen mental models sorted into three categories. I picked a few less obvious ones to help materialize learnings from situations you probably already experienced.
1. Figuring out Where to Invest
▶︎ "Time Horizon". Align your team around the time horizon you're optimizing for. It could dramatically change your strategy.
2. Designing and Scoping
▶︎ "Confidence determines Speed vs. Quality". If you're unsure about how big of a problem you're solving or how good of a solution you have, ship as early as possible.
3. Building & Iterating
▶︎ "Version two is a lie". Don't discard important features on the simple fact that they will ship in "V2". Recognize that v2 may never ship or be delayed a lot, so anything you ship must be a viable solution.
Panda: Dropbox’s massively scalable transactional key-value store
Distributed system nerd alert
"Dropbox operates two large-scale metadata storage systems powered by sharded MySQL. One is the Filesystem which contains metadata related to files and folders. The other is Edgestore, which powers all other internal and external Dropbox services."
Both use cases have grown significantly with the company's growth and were close to hitting irreversible limits. The team needed a new backend for these transactional stores, at a scale that very few companies ever reach for transactional workloads.
After evaluating some best-in-class systems like FoundationDB, Vitess, and CockroachDB, they decided none matched the transactional guarantees and Dropbox's scale.
So they set out to build Panda, their homegrown answer to the transactional storage problem.
▶︎ "Panda is a distributed, ordered key-value store. It transparently splits the key space into ranges and distributes ranges among storage nodes. It uses a two-phase commit and hybrid-logical clocks to provide global ACID transactions."
Leaving architecture aside, an interesting choice from the team was only to allow simple key/value operations and reduce the interface surface considerably. In particular, they didn't include JOINs and other operators with hard-to-anticipate system load impact.
▶︎ "One infrastructure principle at Dropbox is that if a developer writes a bad query that takes down the database, this is the database's fault, not the developer's fault."
📗 Dropbox's Panda, a scalable key-value store goes beyond describing yet another distributed ordered key-value store. It gives valuable insight into trade-offs, design principles, and learnings from this highly complex project.
Investing in Internal Documentation: A Brick-by-Brick Guide for Startups
Documentation always gets pushed to the back burner in a rush to build and ship features.
"Mission-critical knowledge trapped in an early hire’s head is an all-too-common problem that startup engineering orgs know well. But investing in internal documentation is often a chicken-and-egg scenario."
It's a problem that plagues startups of all sizes, and one that David Nunez, an early docs leader for companies like Stripe, Uber, and Salesforce, has seen repeated time and time again.
Nunez's approach to docs, as outlined in his book "Docs for Developers," is about building a culture of documentation from the ground up, with a focus on clear, practical guidance and follow-through. It's not just about writing things down but about creating a system that ensures documentation is an integral part of the process.
"Step 1: Start With A Cultural Shift."
"Step 2: Get Started Paying Down Your Docs Debt With A Mvp Approach."
"Step 3: Stop The Random Acts Of Documentation And Get Organized."
"Step 4: Bring Docs Into The Dev Cycle — Don’t Wait For Code-Complete."
📗 David Nunez's Investing in Internal Documentation: A Brick-by-Brick Guide for Startups is a must-read for any software engineering leader looking to improve their team's documentation practices and drive success within their organization. Don't let mission-critical knowledge get trapped in an early hire's head - start building a culture of documentation today!
What is Mutex
A Mutex is like a café restroom.
▶︎ "We want only one process (a person) to be in the critical section (a restroom) while using the shared resource (a toilet)."
Sometimes a good analogy is clearer than a thousand words on a Wikipedia page. And you can take the best ones quite far.
▶︎ "Reentrant mutex? Like a fitting room in which you leave your things."
▶︎ "Reader-writer mutex? A display with the cafe menu."
📗 Yan Babitski's What is Mutex introduces Mutex and its most common variants using real-world analogies that makes the concept as simple as it really is. You'll see that Mutex ("mutual-exclusion") is not that complex, yet it's an essential synchronization primitive.
🎅 Merry Christmas!