On Engineering Excellence

When I joined Delphix three and a half years ago, I came to build something great. Not just a product, or a business, but a team and culture that represented the best of engineering.

When I joined Delphix three and a half years ago, I came to build something great. Not just a product, or a business, but a team and culture that represented the best of engineering. As VP of Engineering, I was entrusted to guide the evolution of that culture, and build something at scale that I could be proud of.

Yesterday, I was discussing the Delphix engineering zeitgeist with some colleagues. While we often talk about the qualities of a holistic engineer, this time we were focused on the technical deliverables: what differentiates the output of good engineering? We discussed lots of ideas, including thoroughness, contextual relevance, attention to detail, and follow through.

But distilling it down to its essence, I arrived at: As an engineer, what you produce belongs not to you, but to everyone.

Whether it is code, comments, architecture, bugs, or reviews, as an engineer you are contributing to a collective knowledge base that enables others to drive impact broader than you yourself can achieve. Only by owning your work with integrity can you hope to empower others and build something truly great.


Code is the shared expression of product implementation. Successful code invites others to understand, contribute to, and evolve the concepts you bring into being. Bad code erects barriers that promote isolation and inhibit innovation.

  • Comments are not for your sake. It is important that anyone who finds themselves in your code understand not just what it does, but why it exists, and how it connects to the rest of the system.
  • Style matters. Enforcement is not intended to suppress your individuality, but rather to create a common medium that makes it easy for everyone to travel across different domains of code. Style guidelines smooth those transitions while allowing for individual expression.
  • Don't be too clever. As Brian Kernighan said, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." This is even more important when you consider that the person debugging your code, or simply trying to understand it, is unlikely to be you.
  • Beware of novelty. It is important that the code be able to evolve and adopt new design patterns, architecture, and languages that improve efficiency and maintainability; but the bar should be high. Your new library, language, or trick of the month makes it hard for others to understand what could be readily conveyed with something familiar.


Bugs are a shared repository of ideas past and present that can evolve asynchronously from code. When someone traces your code change back to a bug, it opens a new opportunity to teach them about how it was discovered, why it is important to fix, and how it is connected to customers and other bugs. The quality of this information connects directly to the success of your peers and the product.

  • You can't predict the future. A commit message is a static, immutable expression of your intent at the time you integrated the code. Every commit should be associated with a bug (or "change request") that can evolve across the entire product lifecycle, like connecting to future regressions or customer cases.
  • What is obvious to you may not be to others. It can be tempting to use bugs like personal reminders, where you can read the synopsis with no description, and immediately connect it to something familiar. Just because something is obvious to you, don't assume others will understand why it is important or all the moving pieces.
  • Information empowers others. This may be providing detailed instructions to reproduce the problem for the initial evaluator, articulating all the threads of investigation you pursued before handing off to someone else, or detailing an evaluation for someone in the future to understand why the approach was taken and the broader impact. Your goal is to arm the next person with the context they need to be successful.


Code reviews are an opportunity to leverage the wisdom and expertise of your peers, while serving as a record of your thought process and ensuing discussions. Quality review preparation and interactions make your reviewers more effective and drives greater value from the process. This in turn builds a higher quality product and stronger team.

  • Prepare. Anticipate questions and provide context so they don't need to be asked. Code review is a poor place to discuss large scale design - if there are major ideas introduced, validate direction with experts ahead of review.
  • Test. A thorough description of your testing demonstrates depth of thought and thoroughness of approach. Even when new tests or manual testing is not required, explaining why that is the case builds confidence in your work.
  • Be respectful. If someone asks a question, assume they have a good reason. Don't be dismissive - do your research and respond with respect and clarity.
  • Take it offline. Whatever written form your code review process takes, there are times when a simple in-person discussion or whiteboard session can resolve an issue more efficiently.

At Delphix, we live and breathe the ideal of collective ownership, and it is one of the cornerstones of our culture. The best engineers at Delphix are successful not because of what they themselves can achieve, but because of what they enable others to achieve.