Bryan Cantrill is a distinguished software engineer, dynamic speaker, and co-founder of Oxide Computer Company, renowned for his foundational work on DTrace and his outspoken perspectives on systems architecture. His core philosophy asserts that software is inherently a reflection of human values, intricately binding the technical rigors of observability and hardware co-design with the ethical duties of engineering leadership. The following insights encapsulate his convictions on building resilient systems, cultivating trust-driven organizational cultures, and confronting the multifaceted realities of modern software development.

Part 1: On Software as a Reflection of Values

  1. On Alignment: "The right language is the one whose values align with you and your project's goals." — Source: [CoRecursive]
  2. On Technical Debates: "Technical debates are usually misplaced because they ignore the underlying values of the technology." — Source: [Dev.to]
  3. On Platform Values: "While everyone wants approachability, rigor, debuggability, performance, and security, platforms must prioritize some over others when they come into conflict." — Source: [YouTube]
  4. On Principles vs. Values: "Principles are fundamental, universal truths like integrity and honesty, whereas values are malleable expressions of the relative importance of desirable attributes." — Source: [Speaker Deck]
  5. On Corporate Principles: "Corporate leadership principles often lack foundational principles like integrity and honesty, making them contradictory and easily used to justify almost any action." — Source: [Speaker Deck]
  6. On Intentionality: "Engineers must be explicit about what they value, recognize the trade-offs they are making, and ensure their work is grounded in immutable principles." — Source: [Speaker Deck]
  7. On True Principles: "True principles should be explicit to guide the better angels of our nature and prevent institutionalized hypocrisy." — Source: [Speaker Deck]
  8. On Values in Software Decisions: "When you are making a software decision, you should select values that align with the values that you have for that software. That's way more important than community size." — Source: [Dev.to]
  9. On Joyent vs. Node.js: "The friction between Joyent and the early Node.js community arose because Joyent valued rigor and debuggability, while Node prioritized approachability and velocity." — Source: [YouTube]
  10. On Recognizing Trade-offs: "Languages, operating systems, and communities have to make trade-offs and they do that based on their values." — Source: [CoRecursive]

Part 2: On Systems Programming and Rust

  1. On Rust's Revolution: "Rust is emphatically the biggest revolution in system software since C. It is a very, very, very big deal." — Source: [ScyllaDB]
  2. On Rust's Importance: "To me, it is the biggest development in the creation of system software in my career." — Source: [InfoQ]
  3. On Hardware Boundaries: "Rust is actually the first language since C to meaningfully exist at the boundary of hardware and software." — Source: [The New Stack]
  4. On Performance vs. Safety: "My naive Rust was ~32% faster than my carefully implemented C. This is a metric I'm more interested in: What's the average case here?" — Source: [The Observation Deck]
  5. On Data Structures: "In Rust, I get to use a B-Tree, because its safety and composability allow developers to use complex data structures that would be too gnarly to implement in C." — Source: [Reddit]
  6. On the no_std Environment: "no_std is really without precedent... You can put these tight Rust-based programs without a runtime in all sorts of interesting places in a memory-protected and safe way." — Source: [The New Stack]
  7. On System Reliability: "Bluespec is to SystemVerilog what Rust is to Assembly. It is a much higher-level way of thinking about the system, using types in the compiler to actually generate a reliable system." — Source: [ScyllaDB]
  8. On Rust's Values: "I am a vocal advocate for Rust because its core values—memory safety without sacrificing performance—align with my convictions for modern systems software." — Source: [Speaker Deck]
  9. On Surviving the Honeymoon: "Rust has proven to be a remarkably good fit for the entire Oxide stack, from low-level firmware to REST APIs." — Source: [The Observation Deck]
  10. On Rustafarian Zealotry: "Rust zealotry provides the unbridled enthusiasm necessary to build a new ecosystem, but it can become toxic when it leads to mindless groupthink." — Source: [Cantrill Archive]

Part 3: On Tooling, Debugging, and Observability

  1. On Developing Debuggers: "The best time to develop a debugger is when debugging!" — Source: [Simon Willison's Blog]
  2. On Toolmaking: "Tools are the things we build that we don't ship—but that very much affect the artifact that we develop." — Source: [Simon Willison's Blog]
  3. On Who Should Build Tools: "In my experience, tooling should be built by those using it." — Source: [Simon Willison's Blog]
  4. On Observability vs. Logging: "Observability answers questions the developer never thought to ask. The difference is the difference between a searchlight and the sun." — Source: [Dev.to]
  5. On Logging's Limitations: "Logging records what the developer anticipated might go wrong." — Source: [Dev.to]
  6. On Running `strace`: "Running `strace` on a production web server is rather like performing surgery whilst repeatedly switching off the lights." — Source: [Dev.to]
  7. On Safe Tooling: "If you run a tool and the system dies as a result, you will never be allowed to run that tool again. DTrace needs to be done completely safely." — Source: [YouTube]
  8. On DTrace Philosophy: "DTrace does not require you to predict your questions in advance. You do not instrument your code for DTrace." — Source: [Dev.to]
  9. On Asking the System: "DTrace isn't just a tool; it's a philosophy of asking the system what it is doing rather than guessing." — Source: [Code Arcana]
  10. On Understanding: "If we can't explain how something works, we probably don't understand it ourselves." — Source: [YouTube]

Part 4: On Leadership Without Management

  1. On Middle Management: "Traditional middle management can act as a toxin or cancer in engineering organizations." — Source: [YouTube]
  2. On Trust: "Binding a team with mutual trust—this is not just everything, it's the only thing." — Source: [YouTube]
  3. On Competence: "That projection of competence into the future is trust." — Source: [YouTube]
  4. On Micromanagement: "When a person signs up to do a job, you should in turn trust that person to accomplish it. You wouldn't break it down into little pieces and make the task small, easy, and dull." — Source: [YouTube]
  5. On Earned Leadership: "Leadership should be earned through technical excellence and mentorship rather than hierarchical authority." — Source: [YouTube]
  6. On Bad Management: "All the unhappiest moments basically all rhyme with one another... where the people who were responsible for execution knew the right thing that needed to happen, and bad management was preventing it from happening." — Source: [Software Misadventures]
  7. On Compensation: "Compensation isn't merely about the currency we redeem in exchange for our labors, but rather it's a proxy for how we're valued in a larger organization." — Source: [Business Insider]
  8. On Transparency: "You’ve got to love the bad news. Everyone should want the bad news first... it’s essential that we have the bad news and that you’re transparent about it." — Source: [YouTube]
  9. On Organizational Principles: "Organizational principles dictate the behavior and ethics of the engineers within them." — Source: [RedMonk]
  10. On the N+1 Problem: "The 'N+1 shithead problem' degrades a company's culture by hiring people who don't share its core values." — Source: [YouTube]

Part 5: On the Ethics and Impact of Software

  1. On Andreessen's Corollary: "Software's contact with our broader world is bringing with it novel ethical dilemmas for those who endeavor to build it." — Source: [Craft Conference]
  2. On Societal Impact: "What is right for software is not necessarily right for society." — Source: [Packt]
  3. On Engineering Ethics: "More than ever, we software engineers are likely to find ourselves in new frontiers with respect to society, the law or our own moral compass." — Source: [Craft Conference]
  4. On Shipping with Bugs: "Why all the emphasis on shipping software on time and error-free? That's really hard to do, and it's not unethical to ship with bugs." — Source: [YouTube]
  5. On Arbiters of Ethics: "Because software is integrated into every facet of human existence, software engineers are effectively becoming the world's ethical arbiters." — Source: [Craft Conference]
  6. On Rigid Codes: "The original 1997 ACM Code of Ethics was too algorithmic and focused on impossible standards, making engineers unethical by default." — Source: [YouTube]
  7. On Principles-Based Ethics: "The 2018 update to the ACM Code of Ethics is better for being principles-based, focusing on avoiding harm rather than just technical specifications." — Source: [YouTube]
  8. On Should vs. Can: "We must move away from asking 'can we build it?' to asking 'should we build it?'" — Source: [Packt]
  9. On Grey Areas: "Ethical dilemmas in software are often grey areas where different values, like safety versus cost, conflict." — Source: [Packt]
  10. On Open Discussion: "Organizations must create cultures where engineers can openly discuss ethical concerns without fear of retribution." — Source: [Packt]

Part 6: On Building Hardware and Oxide

  1. On the Cloud Computer: "We started Oxide Computer Company with the vision of reimagining the computer server, codesigning hardware and software to develop integrated, rack-scale systems." — Source: [Greybeards on Storage]
  2. On Building What You Need: "When you’re building a tool that you yourself need, you are tautologically building something that someone wants." — Source: [The New Stack]
  3. On System Integrity: "People who are really serious about software should make their own hardware to ensure total system integrity." — Source: [YouTube]
  4. On Hardware/Software Co-design: "Developing our own hardware and software made everything easier for us and our customers." — Source: [Greybeards on Storage]
  5. On Burying the BIOS: "I have come to bury the BIOS, not to open it... an entire city has been constructed and plowed under during boot, and that operating system can actually see the artifacts of that." — Source: [YouTube]
  6. On System Management Mode: "For us, SMM is empty... if we enter system management mode, we panic the system." — Source: [YouTube]
  7. On Power Efficiency: "If you get a rack of commodity servers, 30% of your power is going just to run the fans. That’s truly criminal." — Source: [Insights From Analytics]
  8. On Naming Oxide: "Oxide is very much named because of what we saw happening with Rust... we wanted to have a tip of the hat in the name." — Source: [InfoQ]
  9. On Disrupting Vendors: "I don't think Dell's interested in us... we are so disruptive that being acquired by them has never been the strategy." — Source: [YouTube]

Part 7: On Language Trade-offs (C, C++, Go, Node.js)

  1. On C++ Complexity: "C++ is a language that is designed to be difficult to use correctly and easy to use incorrectly." — Source: [YouTube]
  2. On a Bad Relationship: "Suffice it to say that I was in a bad relationship with C++." — Source: [ScyllaDB]
  3. On Go's Design: "Go is a language that was designed by people who don't like computers." — Source: [YouTube]
  4. On Go and Debugging: "Go threw away 30 years of systems knowledge by making it difficult to use external debuggers like DTrace or gdb effectively." — Source: [YouTube]
  5. On Node.js: "Node.js was a beautiful confluence of the asynchronous power of JavaScript, the V8 engine, and Unix APIs." — Source: [Conversations Network]
  6. On Event-Driven Apps: "For event-driven applications, the effort in C/C++ is brutal by comparison to replacing it with Node.js." — Source: [YouTube]
  7. On Hype: "Don't listen to the hype... just code, baby!" — Source: [YouTube]
  8. On the End of C/C++: "Rust has finally provided a way to move past the memory-safety issues of C and the complexity of C++." — Source: [ScyllaDB]

Part 8: On the Craft and Culture of Engineering

  1. On Oral Tradition: "Software engineering is a craft passed down through stories, demos, and oral literature rather than just formal documentation." — Source: [YouTube]
  2. On Preserving Intent: "Understanding the intent of the original programmer is crucial for future generations, and storytelling is the primary mechanism for preserving that intent." — Source: [YouTube]
  3. On Unsolved Problems: "Please never tell a young person that these systems problems are solved because they're not... This stuff is never done." — Source: [YouTube]
  4. On LLMs and Laziness: "The problem is that LLMs inherently lack the virtue of laziness. Work costs nothing to an LLM." — Source: [Spicy Takes]
  5. On Human Laziness: "Human laziness is essential because it forces us to develop crisp abstractions to avoid wasting our finite time on future maintenance." — Source: [Simon Willison's Blog]
  6. On LLM Garbage: "LLMs do not feel a need to optimize for their own (or anyone's) future time, and will happily dump more and more onto a layercake of garbage." — Source: [Spicy Takes]
  7. On Seeing Software: "Software is unique... one of the most immediate manifestations of this is we can't see software." — Source: [YouTube]
  8. On Open Source Communities: "The Open Source model is valuable not just for its utility, but for the way it fosters communities around shared values and transparency." — Source: [The Observation Deck]