Learning from Giants #17
Learning from Giants #17
Learn about CORS, Common data store types, Observability at Netflix, The product opportunity solution tree, and Management models for web performance.
👋 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.
How to Win at CORS
You're not a software engineer if you have never struggled with CORS.
First, a little history. Why did browser standards add CORS?
"Browsers have been able to include images from other sites for almost 30 years. You don't need the other site's permission to do this, you can just do it."
"When you request other-site content using one of the methods above, it sends along the credentials for the other-site. And over the years that's created a colossal sackload of security issues."
"It's become pretty clear that the above was a mistake in the design of the web [...]. Meanwhile, we've spent the last few decades patching things up as best we can."
It's a whack-a-mole security situation for browsers. Hence the very confusing Cross-Origin Resource Sharing implementation.
"Unfortunately there's no easy rule for what does and doesn't require CORS. [...] The best way to figure it out is to try it and look at network DevTools."
📗 Jake Archibald's How to win at CORS explains how CORS came to be and then is an organized brain dump on the topic by someone who knows more about browsers than most engineers. The author has also built a very useful CORS Playground that readers can use to apply their new CORS knowledge. Credentials, preflight requests, resource annotations, conditional headers, etc. There's a lot to learn about CORS.
Five Common Data Stores and When to Use Them
If you are new to software or product management, the term "database" is probably synonymous with relational database, like MySQL or Postgres. But relational databases are just a specific subset of data stores.
"A relational database, or RDB, is a database which uses a relational model of data. Data is organized into tables. Each row in the table has its own unique key, also called a primary key. A row in another table might reference this table's ID, thus creating a relationship between the two tables."
But then your data team introduces you to BigQuery / Snowflake / Redshift, and calls it a database too. That's starting to get confusing, but you feel like you only have part of the picture.
And you're right! There are many different types of data storage systems. While most attempts at categorizing them failed, they'll be good enough for an introduction.
📗 Toria Gibbs' Five Common Data Stores and When to Use Them on the Shopify engineering blog is a very high-level overview of the most popular types of data storage systems. It's aimed at early software or data engineers and people with tech-related jobs like product management. A good introduction if you have never had any!
Solving Mysteries Faster With Observability at Netflix
Observability is often the tool engineers miss the most when leaving BigTech for smaller companies. And while many off-the-shelf tools exist, it's also an area where large companies tend to end up building rather than buying.
That's what Netflix did with Edgar.
"[Edgar's] goal is to act as a concierge of troubleshooting — Edgar should quickly be able to guide users to an understanding of an issue, as well usher them to the next location, where they can remedy the problem."
The more complex a system gets, the more troubleshooting becomes a pain for teams. Add to the hundreds of micro-services the fact that dozens of different teams own them, and you've got a problem to solve.
"Searching for key evidence becomes like digging for a needle in a group of haystacks."
So how does Edgar solve that problem? With a product approach to problem-solving. The tools are always the same: tracing, logs, and metrics, but the way Edgar leverages them makes it interesting:
Edgar is a distributed tracing system at its core, with intelligent ways to attach metadata to traces, like logs and service health metrics.
Edgar's foundational principle is not to drop any "interesting" request. It does do random sampling like most systems but instead tries to do intelligent filtering.
Edgar's value prop is around the troubleshooting use-case, to show everything an engineer needs to troubleshoot on a single trace details page, rather than having to open dozens of dashboards.
📗 Netflix's Edgar: Solving Mysteries Faster with Observability details how the team built Edgar, a self-service distributed systems troubleshooting tool. As always, the devil is in the details and the value in documenting decisions and trade-offs. The article does that, and more.
Make Product Discovery work explicit with the Opportunity Solution Tree
Product Discovery has one big problem: people can't help jumping to solutions. Even when extensive user research is done, the next step is often about solutions.
"It’s easy for teams to work along both dimensions of product discovery—working to understand their customer’s context and iteratively testing their ideas—but that doesn’t mean they know how to connect the two sets of activities."
The solution is to take a step back and reframe the problem, then use research to define opportunities and ideas to solve them. But how do we ensure we consistently do that? Teresa Torres says it's almost impossible without a mental representation of these discovery steps. So she set out to build one.
"Better mental representations set experts apart from novices." Anders Ericsson
So Teresa designed the Opportunity Solution Tree framework.
"[The Opportunity Solution Tree] is a simple way of visually representing how you plan to reach a desired outcome. It helps you to make your implicit assumptions explicit."
📗 Teresa Torres' Why This Opportunity Solution Tree is Changing the Way Product Teams Work is a foundational read for all Product people. The author describes the framework she has built from her extensive experience coaching hundreds of product teams. They then give advice on building the different sections and examples of real-world usage.
A Management Maturity Model for (Web) Performance
"(Web) Performance is rarely the single determinant of product success, but it can be the margin of victory."
Said differently: excellent web performance won't make you win, but poor performance will make you lose. But can we blame it on the engineers?
"Nobody goes to work to tank the product, lose revenue, or create problems for others down the line. And engineers are trained to value performance and quality. The engineering mindset is de facto optimising. What separates firefighting teams from those that have achieved self-actualised [performance] execution is not engineering will; it's context, space, and support."
Bad Web Performance is often a Management Problem.
As a senior manager, the road to performance optimization is a growth process you must take yourself and your team through—a mindset, almost cultural shift. And if you don't, poor web performance can also degrade into poor overall performance.
"Senior management sending mixed signals about the value of performance is the fastest way to degrade a team's ability to execute. The second-fastest is to use blame and recrimination."
📗 Alex Russel's A Management Maturity Model is a very dense manager's guide to Web Performance management. It takes the reader through the different team maturity models in dealing with performance: from Level 0, ignorance, to level 1, firefighting, up to level 5, institutionalized performance management.