Learning from Giants #65
A first look at React Server Components, Golden Rules for Organizational Structure, a survey of Analytics Databases, and a fantastic re-post: the Linear Method.
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. Guaranteed 100% GPT-free content.
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.
Making sense of React Server Components
React Server Components are the most confusing React update in many years. Thankfully, you will likely use them through a framework like Next.js that abstracts away complexity and will never have to deal with them directly. Yet RSCs are such a paradigm shift that learning about them is helpful.
The main problem
Server-side rendering is everywhere now. Its initial idea was to simulate a client environment on the server to render a first HTML page and display it to the user while the large Javascript bundle is loading.
As the SSR frameworks expanded, developers started asking to customize that initial HTML page and fill it with user data to make it more relevant.
"In order for this to work, we'd need to be able to give React a chunk of code that it runs exclusively on the server, to do the database query. But that hasn't been an option with React… even with Server Side Rendering, all of our components render on both the server and the client."
The solution: React Server Components
React Server Components solve that problem: they're guaranteed to only run on the server and won't be part of the browser Javascript bundle. The other components are called Client Components.
"Server Components never re-render. They run once on the server to generate the UI. The rendered value is sent to the client and locked in place."
This paradigm has significant consequences on what RSCs can and cannot do:
RSCs cannot hold mutable state.
RSCs cannot receive props from Client Components. Thus, they cannot be imported by Client Components. If they are, React automatically turns them into Client Components.
All components are considered React Server Components unless specified.
"One of the biggest "ah-ha" moments I had with React Server Components was the realization that this new paradigm is all about creating client boundaries."
Indeed, because of the propagation of the "Client-ness" in the import tree, boundaries and structure define what will be interactive and what will render only once on the server.
📗 Josh Comeau's Making Sense of React Server Components is an excellent introduction to RSCs. Josh uses his creativity and React and animation skills to describe how they work in detail. While you will probably only use them through frameworks, the article details weird but logical design decisions that, once understood, will save you hours of madness.
Golden Rules for Organizational Structure
Your 200-person org doesn't need VPs, Directors AND managers. Here's how to fix it.
From ~100 FTEs up to thousands, it's a good practice for every tech organization to reflect on its structure. A periodic audit of the overall organization design can help uncover and fix flaws. What exactly should you look for?
Joshua Burgin has spent most of his 30-year career as a tech executive and gives Golden rules and numbers for organizational design.
"The guidance principles are divided into the following areas: Span of control, Layers, PM to Engineering Ratios, Engineering Seniority Proportions"
Span of control
"This refers to the number of direct reports that a manager oversees and/or manages within an organization.
Managers should oversee 6 to 10 reports. [...] Directors, VPs & above are capable of managing 8-12 reports
No one with a Management title (including Directors and VPs) with less than 5 direct reports."
Senior ICs can also report to VPs or Director, which the author recommends, through this principle:
"Managers, Directors, and VPs should ideally be at the same or higher level as the ICs they oversee."
Layers
"In organizational design, "layers" refer to the hierarchical levels or depth within a company's structure."
It's no secret that organizations should be kept as flat as possible.
"The median gap between the lowest level ICs and VPs should be 2 layers of management (IC → Manager/Director → VP should be the norm)
The maximum gap between the lowest level ICs and VPs should not exceed 3 managers."
Engineering ratios
These are the rules that apply the earliest in a company's lifespan.
First, you should keep the feature teams vs. common services (sometimes called platform) teams ratio between 70/30 (usual) and 90/10 (high-performing orgs).
Second, you should balance seniority inside the organization and its teams.
"Aim for 30% of your org junior/entry level. You can have a little less or more, but not more than 40%.
40-50% of your org should be mid-career level."
20% of your org should be the senior-most ICs in technical leadership (typically "Senior Staff" and "Principal Engineers")."
📗
's Golden Rules for Organizational Structure gives reference numbers to design healthy organizations. Beyond people ratios, he also mentions that every organization is different and may warrant breaking these rules as long as the organization's design is intentional and continuously questioned.
A shallow survey of OLAP and HTAP query engines
Snowflake, ClickHouse, DuckDB, Velox... Are the hundreds of OLAP query engines really different?
As it turns out, many converge to similar designs over time. Yet studying these differences is a fantastic learning opportunity. Let's look at the main attributes:
Data layout
All systems seem to agree on the PAX layout (Partition Attributes Across) to store data. The idea is that rows are grouped together, and then the values are grouped by column within each row group. The main differences lie in the size of these partitions, usually in the hundreds of Mb range.
"For hot data we still see PAX-like layouts, but with much smaller row groups because we want entire query pipelines (see below) to fit in cpu cache."
Compression
The main question is generic vs. specialized compression. The issue with generic compression is that it usually requires unpacking an entire compressed block when reading random values. However, since compression significantly cuts storage and bandwidth costs, it's an acceptable trade-off.
"For cold data most systems apply both one or more specialized algorithms and then some generic algorithm afterwards."
Vectorized vs pipelined queries
Vectorized query execution processes multiple data elements (as a vector) in a single instruction, improving computational efficiency by reducing instruction overhead.
Pipelined query execution splits a query into stages, allowing different stages to work concurrently on different parts of the data.
"The pure OLAP systems generally use entirely vectorized style."
📗 Jamie Brandon's A shallow survey of OLAP and HTAP query engines is an exploratory article into the design and trade-offs that characterize these systems. As it opens more doors than it closes, the article is an excellent entry point into the deep domain of query engine optimization.
Top 0.1% re-post: The Linear Method
Standing on the Shoulders of Giants is nearing two years, and 300 articles have been shared. Some articles are one in a thousand and deserve more than one post. Every week, I’ll re-post one of these fantastic pieces of knowledge. Starting with the Linear method, as my thoughts go to the Linear team that has had a bad database outage last week and has lived through what I imagine wasn’t their best week.
Successful products have "on-point" operating systems. And when they share them, it's an incredible learning opportunity. As an individual, there are plenty of ideas to bring to your team. As a founder, you can compare your processes against the best!
The Linear Method collects the aspirations and operating cadence of the team and how they continuously roadmap and build. It’s down to earth, opinionated, but also built on the principle that rules are guidelines, not laws.
Overflowing inboxes are a good sign unless they're bug reports. Don’t worry too much about organizing all the [user] feedback. Collect it and use it as a research library when developing new features.
At Linear, we don’t write user stories and think they’re an anti-pattern in product development. We write short and simple issues that describe the task in plain language instead.
📗 Linear's The Linear Method describes the foundational principles the Linear team used to create such a successful product. I found every section truly enlightening and helpful as a product leader. It takes a deep understanding to clearly lay out these principles with no jargon and short sentences.