Collaboration

Subpage of SWE for Pros

Sophisticated software systems under the hood

The Core Idea: Software is a Social Activity

In a small project, you are the architect, the developer, and the user. In a Big Tech company, you are a node in a human network.

System Design isn’t just about drawing boxes and arrows; it’s about Consensus. How do you convince 50 other engineers that your way of storing user data is the best? You do it through Design Docs and ADRs. The goal is to make the “invisible” visible—to document the why so that three years from now, when you’ve left the company, the next person knows exactly why you didn’t use a SQL database.

Real-World Example: Amazon’s “Two-Pizza Teams”

Jeff Bezos famously said that if a team can’t be fed with two pizzas, it’s too big. This isn’t about food; it’s about Communication Overhead. As teams grow, the number of “lines of communication” grows exponentially. Small, autonomous teams that “own” their services (DevOps) are the secret to Amazon’s speed.


🛠 Platforms & Tools

  • Mermaid.js / Lucidchart: Tools for drawing architecture diagrams. If you can’t draw it, you don’t understand it.
  • Notion / GitHub Wiki: The “Source of Truth” for your team’s knowledge.
  • Jira / Linear: Tools for tracking what everyone is doing. In large projects, “Who is working on the payment bug?” is a harder question to answer than “How do I fix the payment bug?”

💻 Code to Explore: The “Documented” Project

kubernetes/enhancements

This isn’t code—it’s the KEPs (Kubernetes Enhancement Proposals). * What to look for: * The Structure: Look at a single KEP. Notice how it has “Motivation,” “User Stories,” “Design Details,” and “Graduation Criteria.” * The Discussion: Look at the “Pull Request” comments for a KEP. This is how world-class engineers argue and reach consensus.

rust-lang/rfcs

The Rust language is built entirely through collaboration. * What to look for: The “Alternatives Considered” section. This is the most important part of any design document. It shows that you’ve thought about other ways to solve the problem and have a reason for your choice.


📚 Deep Dive Resources

🎥 Watch: “The Mythical Man-Month” (Summaries)

  • YouTube Link
  • How to use it: This is the most famous book on software management. It explains why “adding more people to a late project makes it later.” It’s essential for understanding why Big Tech companies are structured the way they are.

📝 Read: “How to Write a Technical Design Doc”

  • Technical Blog
  • How to use it: Use this as a template for your next project. Even if it’s a small project, try writing a 1-page design doc before you start coding. It forces you to find the “Hard Parts” early.

💡 The Big Idea to Take Away

The best code in the world is useless if no one knows it exists or how to use it. Communication is a technical skill. In Big Tech, your career is often defined more by your design docs and your ability to mentor others than by the number of lines of code you write.

/ Continue

Follow the technical trail.

Use the dense notes as the source material, then move through the guided route, writing, or project proof when you want a cleaner entry point.