Learning from Giants #6
Learning from Giants #6
Database 101, Having impact through writing, Google API conventions, Shape Up, Figma's LiveGraph.
👋 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.
Things You Should Know About Databases
How much should you know about databases? Is mastering SQL enough? Does your company have a DBA that will magically optimize whatever you throw at them?
As an entry-level engineer, that may be work but won't scale. There are a few mental models you need to master to avoid most foot guns.
👆 The first obvious one is indexes.
"Indexes are a data structure that helps decrease the look-up time of requested data. Indexes achieve this with the additional costs of storage, memory, and keeping it up to date (slower writes), which allows us to skip the tedious task of checking every table row."
🌀 A more insidious one is transactions and their isolation levels. The I of ACID. It's probably the feature most engineers take for granted in databases.
"A transaction is a unit of work you want to treat as a single unit. Therefore, it has to either happen in full or not at all. [...] Isolation determines how a particular action is shown to other concurrent system users."
📗 Architecture notes' Thing You Should Know About Databases is a great resource to start building these mental models around databases. Mahdi Yusuf introduces indexes and transaction isolation levels without too much detail. With the number of new database systems rising in recent years, these are two questions you can ask your team when they suggest a new one.
PS: if that was too high-level for you, stay tuned, we will go deeper on both subjects in the future.
The Importance of Writing
What's your best tip to be more impactful at work?
Mine is writing more and better.
"Writing is a normalizing medium. No matter what you look like, how old you are, how you speak, or how confident you are, you can sit on your own and formulate your thoughts [...] An impactful message is an impactful message."
Writing helps in many ways, yet it takes effort to learn and improve.
"Firstly, the best way to get better at writing is just to write as much as you possibly can."
📗 James Stanier's The importance of writing is a pre-covid era post about the impact of writing at work. It will convince you of its usefulness if you're not already, but the article's value is in the actionable advice it contains. If you only have 2 minutes, skip to the five ways to practice being more impactful at work through your writing.
The one that particularly resonated for me is "Think through problems by writing them out". This practice has worked remarkably well for me during the past years.
"Writing is so powerful. Wield that power for your benefit."
Google API Conventions (A.I.Ps)
API design is an immutable, large-scale version of the famous computer science "naming things is hard" problem, with an extra layer of system design.
SOAP, REST, a lot of conventions were invented as a result.
But what always struck me is how these definitions diverged over time, to a point where these concepts don't mean much anymore in 2022.
What's left is philosophical differences. But philosophy won't build your API. It needs to be paired with strict, actionable rules and recommendations to make an impact.
That's why Google has A.I.P.s.
"AIP stands for API Improvement Proposal, which is a design document providing high-level, concise documentation for API development. They are to serve as the source of truth for API-related documentation at Google and the means by which API teams discuss and come to consensus on API guidance."
📗 Google's API Improvement Proposals are a gold mine of software engineering content. They cover every design document ever approved to solve common API problems. For every one of them, you will have a specific solution that works at Google's scale documented so that you can't really go wrong. Of course, Google's solutions are one amongst thousands, and there are many reasons to do things differently, but they're good patterns you should often consider.
Shape Up: Basecamp’s Product Method
Ever heard of product teams working in six-week cycles and wondered where the idea originated? Why not use scrum, or do quarterly objectives? Why not 5 or 7 weeks?
The answer is more often than not the same: Shape Up.
Six-week product development cycles are the most obvious sign that a team has adopted Shape Up in some capacity, but it is 1% of the method.
Shape Up results from a team of world-class people not giving out to any trend, starting from a clean slate and building product management processes iteratively.
"For one, we're not into waterfall or agile or scrum. For two, we don't line walls with Post-it notes. For three, we don't do daily stand ups, design sprints, development sprints, or anything remotely tied to a metaphor that includes being tired and worn out at the end. No backlogs, no Kanban, no velocity tracking, none of that."
📗 Basecamp's Shape Up sums up these 15 years of experimentation and learnings about moving fast with high standards and keeping a happy team. It contains a detailed view of Basecamp's unique product development process and facts the team learned along the way.
"This is the result. You can think of this as two books in one. First, it's a book of basic truths. I want it to give you better language to describe and deal with the risks, uncertainties, and challenges that come up whenever you do product development. Second, the book outlines the specific processes we're using to make meaningful progress on our products at our current scale."
And the best: the digital version is available for free.
If you're a product or engineering leader and haven't read Shape Up, this is one more reminder that you should :)
LiveGraph: Figma’s real-time graphQL data system
Abstracting away significant product problems with a system or library can 10x your product quality and engineering productivity.
👩🚀 A.K.A. the power of platform teams.
When prioritizing platform work, the best topics are often the closer to your core business and differentiation. The Figma team understands this better than anyone, as they built their products on rock-solid platform foundations, both on the frontend and backend.
Today's problem is a classic: real-time updates.
"For the infrastructure team, the question was: how do we empower our product engineers to build these real-time views easily, while abstracting away the complexity of pushing data back and forth?"
📗 Figma's GraphQL, meet LiveGraph: a real-time data system at scale introduces this shared library and infrastructure the team built as a real-time data-fetching layer on top of their Postgres database. LiveGraph solves many complex problems at once, some of which the article describes well.
Rudi Chen and Slava Kim: if you read this, we would love follow-up posts on LiveGraph! Here are a few ideas:
How does sharding work with subquery sharing?
How do the partial view updates work on the server and the client?
How does caching work?
What were the main learnings and updates of LiveGraph since 2021?
PS: The article also contains a great reflection around build vs. buy, which is rare enough to be noticed.