Lessons from Mitchell Hashimoto

Mitchell Hashimoto is the co-founder of HashiCorp, known for creating tools like Vagrant, Terraform, and Vault.

On Building and Managing Large Technical Projects

On Maintaining Momentum: "I've learned that when I break down my large tasks in chunks that result in seeing tangible forward progress, I tend to finish my work and retain my excitement throughout the project." [1]
The Power of a Demo: "People are all motivated and driven in different ways, so this may not work for you, but as a broad generalization I've not found an engineer who doesn't get excited by a good demo. And the goal is to always give yourself a good demo." [1]
The Goal is to Finish: "This blog post is aimed at people who want to finish projects more or simply want to learn how I strive to finish projects more." [1]
Seeing Real Results: "A method that works really well for me is to continuously see real results and to order my work based on that." [1]
Avoiding Burnout: "I'm one of those people that if I don't see progress on what I'm working on I get burnt out or burnt out is the worst case but I get just really demotivated quickly." [2]
The Joy of Shipping: "I think once I reached that point where I shipped software I realized that the joy and and excitement that comes from seeing others use your software and solve their problems as well is sort of what pushes me to complete a project towards the end." [2]
Structure for Large Projects: To avoid demotivation or burnout on large projects, structure the work to have visible and tangible progress. [3]
Shoot for a Demoable Outcome: When working on large technical projects, aim for something that can be demonstrated. This helps limit the scope and makes progress visible. [2]

On "As Code" and Infrastructure

The Meaning of "As Code": "I've always personally defined the 'as code' suffix in 'X as Code' to mean 'a system of principles or rules'. This is in contrast to the popular interpretation of 'as code' to mean 'as programming.'" [4]
The Intent of "As Code": "My intent with 'X as Code' was always to get knowledge out of people's heads and into a more inscribed system. Once inscribed, knowledge and process can be shared, versioned, iterated upon, etc." [4]
Codification is Not Just Programming: "The relation to programming is that codified knowledge tends to also be computer-readable and comes with the full benefits of that (e.g. automation, validation, etc). However, I don't believe that implies that all the requirements of modern programming should be applied to 'as code' systems." [4]
Workflows Over Technologies: "If you aim at workflows first, you could often create software that could span multiple paradigm shifts." [5]
The Problem with Manual Processes: The problem with manual processes for infrastructure is that they are not repeatable, they are error-prone, and they don't scale.
Infrastructure as a Solvable Problem: Hashimoto saw the complexities of infrastructure management not as a given, but as a problem that could be solved through software. [6]

On Open Source

Learning Through Open Source: "I was really only able to start getting involved and learning to code because of open source." [7][8]
The Non-Coding Side of Open Source: The success of Vagrant "taught me a lot about community: the non-coding side of open-source. I had to learn about the challenges of building a community, the challenges of bringing on contributors, governance—those sorts of things." [7]
Monetization Strategy: When building an open-source company, it's important to think about the monetization strategy early on. [9]
Technical Philanthropy: On his new project, Ghostty, he describes his motivation as a form of "technical philanthropy." [10]

On Career, Leadership, and Company Culture

Solving Your Own Problems: "The most successful founders don't usually chase startup ideas. Instead, they're pulled toward problems they can't ignore." [11]
From Founder to IC: Hashimoto transitioned from CEO to CTO, and eventually back to an individual contributor (IC) role, driven by his passion for coding. [12]
On Hiring a CEO: He has spoken about the tough decisions he faced, including hiring an external CEO for HashiCorp. [11]
The A.P.P.L.E. Framework: He uses the "A.P.P.L.E." framework (Acknowledge, Probe, Present, Listen, Empathize) for diffusing tense situations and handling criticism. [3]
Defining Company Culture: He emphasizes the importance of deliberately defining and building company culture, especially in a remote-first environment. [13]
Remote Work Culture: Building a successful remote work culture requires deliberate decisions and fostering practices like "chat literacy." [13]
The Value of Humility: When interviewing candidates, he looks for humility. [13]
Pragmatism as a Core Principle: "Pragmatism is the understanding that everything I said before is a set of ideals... but if it's just simply not the right pragmatic solution then we need to be able to be understanding enough to re-evaluate." [5]
The Importance of Alignment in Startups: "When you're less than 50 people... you can really get everyone completely aligned on one mindset." [13]
Don't Be a CTO Who Produces Technical Debt: "I didn't want to be that CTO that just produced technical debt." [2][3]
Passion in Hiring: "Passion and hiring—why obsession with a topic often leads to the best hires." [10]

On Learning and Personal Growth

Learn by Building: "My general advice to people is build things." [2]
The Power of Specific Questions: "You could tell the difference between someone who's like learning something and on the path to learning something versus like trying to find the quick way out because the people finding a quick way out ask you these very vague large questions and the people that are actually learning had ask you more specific Nuance questions." [2]
Learning Multiple Languages: "I think all of us in here would agree that there's value in learning many different programming languages even if you work every day with only a single one learning multiple different languages tends to make you a better programmer." [14]
How He Learned to Code: He taught himself to code by reading computer books at a bookstore (without buying them) and by downloading and reading open-source code. [7][8]
Continuous Learning: His work on a terminal emulator (Ghostty) was initially a project to learn new things like GPU programming and the Zig language. [9][15]
Human Experience as the Goal: "We only exist to strive for happiness in our experiences... that's my day-to-day sort of mantra." [10]
Optimizing for Happiness: "Whatever I I sort of look back and I'm like what made me less happy what made me more happy and just keep optimizing for the branch that makes you more happy." [10]
Family as a New Normal: "I feel like my primary day-to-day job is just being a dad." [10]

On Technology and the Future

The Future of the Terminal: On his work with Ghostty, he believes there is still a lot of room for innovation in terminal emulators. [16]
AI as an Essential Tool: He considers AI tooling essential for developers. [10]
The Importance of Usability in Security: "One of my views on security is I feel like usability is often like more important than getting all the security principles right." [13]
The Relative Complexity of Vault: While acknowledging Vault's complexity, he argues it's a significant improvement over what existed before. [13]
Choosing Zig over Rust: He chose Zig for his terminal project because he finds it "really fun really enjoyable" and likes that it's a "very linear" language where he has a good sense of how it will transform into machine code. [9]
The Value of Native-Feeling Apps: He believes native-feeling applications are essential for a good developer experience. [15]
Testing the Untestable: "The truth however is usually this can't be tested yet. or re or replace yet with easily." [14]
Reality is Messy in Testing: "Most tests really don't come down to that simple run a thing get an output... they have side effects or there's a complex state of the world that needs to be created in order to even run it in the first place." [14]
The Tao of HashiCorp: The guiding principles for HashiCorp's product design, emphasizing workflows, pragmatism, and simplicity. [5]
On the Longevity of Problems: "Most problems don't disappear... there's a big group of problems which stay the same." [5]
The Challenge of Immutability: "Not everything we do is immutable immutability introduces a number of challenges and immutability is not always practical." [5]
Solving Real Problems: "I don't know where that comes from, but we try to solve real problems, I guess is how I put it." [6]
The Accidental Entrepreneur: "I got into it by accident, I'm sure a lot of people say that. I started building open source software, build some software called Vagrant got reasonably popular. I did not build it for enterprises." [6]

Learn more:

Lessons from Mitchell Hashimoto

On Building and Managing Large Technical Projects

On "As Code" and Infrastructure

On Open Source

On Career, Leadership, and Company Culture

On Learning and Personal Growth

On Technology and the Future

Written by Antoine Buteau

Lessons from Alexandr Wang

Lessons from Paul Graham