Someone asked me recently to share some previous work I had done. As I looked back at my personal history, and reflected on what I’ve done successfully, it was clear to me that I’m definitely working on things I’m meant to be working on. Automation has been my passion since the very beginning.
I started programming because I wanted to cheat Neopets. I played Neopets daily, and I was frustrated that I would do the same things daily for hours for the same measly amount of Neopoints (the virtual currency used by Neopets). I learned Visual Basic with the goal of writing a program to do these tasks for me. I succeeded at this, and was soon making my measly amount of Neopoints without any human interaction.
I found more things to automate, realizing that computers can do tasks much more efficiently than humans, thus unlocking opportunities that didn’t exist before. I was soon able to generate millions of Neopoints every hour from arbitraging Neopian markets. On average, someone making a few thousand an hour would be impressive, so I was doing quite well, virtually. At this point, I wasn’t particularly interested in Neopets anymore. The automation had taken hold within me, and I was just seeing how far I could push it.
After becoming bored of Neopets, my interest turned to seeing if I could automate things to make real money. I began writing Windows applications that faked ad clicks, played online games that paid real money, etc. This proved to be very lucrative, though the legal notices my parents received quickly ended this phase of my life. Despite the negative outcome, I loved making computers do things for me that were previously manual tasks.
As I began college, I noticed that the poor technical design of the registration system made it incredibly difficult to get the set of classes I wanted. I developed automated registration software that would detect open slots in the full courses, and notify me via text message. While my friends were spending hours every day refreshing course schedules hoping to get into a full class, I was just waiting for a text message. And I always got into the classes, because a human refreshing a browser can’t beat my software that was checking thousands of times per hour. Automation wins again.
Then, in my third year of college, I built Vagrant. The idea that I could automate the actual creation and control of virtual machines struck me in a way I can’t describe. Once the idea hit, I was obsessed. I had to see what I could do, what boundaries I could push, what opportunities existed. The success of Vagrant is proof that automation in this space vastly improved the working lives of many people.
After college, I spent two years working at Kiip. At Kiip, I automated their entire infrastructure. At one point, I accidentally locked myself out of our entire production cluster (whoops, never made that mistake again). I rebuilt the entire production cluster from scratch in less than 30 minutes, and switched to the new cluster with no perceivable downtime. The production cluster was over 50 machines. My obsession with automation reached a point where if I had to do anything twice, I would write a program to do it for me.
Recently, I started HashiCorp. And while it isn’t publicly clear what I’m up to yet, and I’m not quite ready to talk about everything I’m up to, you can be sure of one thing: I’m busy automating. More specifically, I’m developing software to automate everything, and giving it to you.
This should come as no surprise. Automation defines who I am, and always has.
Vagrant 1.1+ no longer supports RubyGems as an installation method. Instead, you must install Vagrant 1.1+ using pre-made packages or installers. For folks used to the gem-based installation, this has caused a mixture of confusion and disdain. In this post, I enumerate my reasons for abandoning RubyGems, and why it is better for the Vagrant community long-term.
I initially released Vagrant as a RubyGem over 3 years ago. Vagrant is written in Ruby, and at the time I was already comfortable with making RubyGems, so I decided it was a natural distribution mechanism.
I don’t regret this decision for a moment. The Ruby community is very open to cutting edge technologies, and I think that distributing as a RubyGem improved my initial adoption of the project.
Since then, however, I’ve grown and learned that RubyGems is no longer the best choice, for many reasons.
In this post, I’m going to explain why installers make life better for Vagrant users. In a future post, I’ll explain how installers affect plugin developers and that ecosystem.
Non-Rubyists
Since the initial release of Vagrant in 2010, Vagrant has grown to be used by hundreds of companies and thousands of people. While I don’t have hard numbers to back this up, a majority of the Vagrant users I meet are not Ruby developers.
Prior to making installers, the top complaint I would receive about Vagrant was about RubyGems. As a Ruby person myself, I always considered RubyGems to be simple. But for anyone outside the Ruby community, I learned that the burden of having to learn RubyGems, install Ruby, and so on was a high enough barrier to entry that many people didn’t even try to install Vagrant.
On the other hand, packages that bundle all of Vagrant’s dependencies (including Ruby), make installing Vagrant extremely simple.
Bugs
Vagrant has a lot of external dependencies: Ruby, RubyGems, OpenSSL, zlib, JSON, and more. With the RubyGems approach, users were left to manually install these dependencies, either from source or their package manager of choice.
Given this flexibility, I was unable to test Vagrant in every conceivable environment. I knew Vagrant worked on my system with my installed versions of dependencies, but didn’t know if it would work in every system.
Because of this, it was common to receive bugs where Vagrant was used with dependencies that were too old, had bugs, or were simply broken due to permission errors and so on.
I don’t care whether this is perceived as my fault or the user’s fault. I don’t blame users for not installing proper versions, especially if they just installed what their package repository had.
However, it is a huge problem when Vagrant crashes due to a broken environment, and then people perceive this as an instability in Vagrant itself, when 9 times out of 10, it was due to a misconfigured environment.
With installers, I am able to ship Vagrant with all the dependencies it needs, and promise the user that Vagrant will work with those dependencies. This is especially helpful in Windows environments.
Flexibility
Because I strictly control the environment, I’m able to improve and fine tune the dependencies Vagrant relies on.
In Vagrant 1.1, I replaced the old, slow pure-Ruby tar library i was using with libarchive, a high performance, stable, and flexible application and library written in C. libarchive is now shipped with every Vagrant installer, so users don’t have to install another dependency, and don’t really need to care Vagrant is using it.
In Vagrant 1.2, I replaced the downloader from using pure-Ruby HTTP to using cURL. This is much faster and supports many more network protocols, such as FTP. Every installer will ship with cURL pre-installed within it. Again, users don’t need to care.
In the future, I’ll be replacing the pure-Ruby SSH library with a more stable, well maintained SSH library written in C. Once again, users don’t need to care, but they’ll notice that SSH becomes more stable.
With all of these changes, I’m able to make significant dependency changes without the user noticing. In fact, all the user notices is that the Vagrant experience just got a lot better. Things got faster, things don’t crash, and Vagrant supports more features.
Overall, Vagrant got a lot better because I was able to make changes I couldn’t safely make by distributing via RubyGems.
No, not the company or the fruit. APPLE is an acronym ingrained into every Apple store employee before they ever even step on the retail floor. And it has continued to guide me ever since.
APPLE:
Approach customers with a personalized warm welcome
Probe politely to understand all the customer’s needs
Present a solution for the customer to take home today
Listen for and resolve any issues or concerns
End with a fond farewell and an invitation to return
To date, I’ve had three successful side projects. I attribute a large portion of each of their successes to APPLE.
My first successful side project turned into a healthy passive income business which I later sold to self-fund HashiCorp. The second side project was Vagrant, a popular tool used by thousands of companies and also now my full time job. The third project, IRCRelay, was a weekend project I worked on with Jack Pearkes over the course of two months. It launched in November 2012, and was profitable in less than 6 weeks.
While much more than just APPLE is required to be successful, I can confidently say that without APPLE, each of the aforementioned projects would have failed.
When doing anything, there is nothing more important than being respectful to your customer or user. Take the time to be welcoming, polite, and attentive. Present a real solution to their problem. Invite them back if they need anything more. Maybe they’ll help you by continuing to support your work, but maybe they won’t. It doesn’t matter. All that matters is being a good, caring person.
As a single concrete example, let’s look at a real email conversation from IRCRelay support, anonymized to protect the customer’s identity. An IRCRelay user, Brian, sends this email only 20 minutes after signing up:
Brian writes:
My username is “brian” please cancel my account.
At this point I could’ve quickly responded to Brian, pointing out we have a “cancel my account” link directly on the page shown after logging in. Similarly, when someone comes into an Apple store wanting a MacBook, the specialist could easily just point to the MacBooks and say “there they are.” They don’t do this. Likewise, instead of pointing to the “cancel my account” link, I responded:
Mitchell writes:
Brian,
Of course! I went ahead and deleted your account. Just so you’re comfortable, I want to remind you that you won’t be billed.
Also, thanks for giving IRCRelay a try, we really appreciate it. Do you mind sharing why you were unhappy with the service?
Approach and Probe. Brian responds:
Brian writes:
Thanks! I appreciate that being so easy. I had trouble with my IRC nickname. Whenever I connected it would be “brian_” instead of “brian.” Initially, I was already connected to IRC from my old client, so I disconnected. But the nick wouldn’t change itself back to “brian.” Contacting help is a bit too much trouble, so I just gave up.
I respond, Presenting a solution:
Mitchell writes:
Brian,
We just deployed a change to our system so that it automatically tries to regain your desired nickname if it wasn’t able to upon connection. This will avoid this issue for all future users. Thanks so much for pointing it out.
If you ever feel like giving IRCRelay another try, I’d be happy to give you an extra month free on top of the 30 day trial, as thanks for pointing out this issue. And please don’t hesitate to contact me directly should you need any more help.
It is important to note here that when working at an Apple store, a solution isn’t just something that solves the customer’s problem, it is the solution that solves the customer’s problem best.
I could’ve easily responded to Brian by educating him on how he could’ve used the /nick command to change his nick. Or I could’ve just offered to fix this for his specific IRCRelay account. Instead, the best solution was clearly to implement and deploy a system to automatically avoid the issue altogether.
The solution took extra time and effort, and maybe Brian won’t even sign up again. But it doesn’t matter. It was the right thing to do, and I genuinely do care about making the experience the best it can be for every customer.
At the end of the email, I End with a fond farewell, and invite Brian to contact me again if he needs anything. Brian has not yet signed up again, but I’m confident he will.
The “new normal” is what I’ve named a phenomenon I’ve seen multiple times in my life. It’s an event where your perception of normality is changed by the people surrounding you. Consequently, your ambitions and chance of achieving those ambitions change as well. Actively seeking a new normal can steer you in a direction you never thought you’d take.
Looking back, four critical events of acquiring a “new normal” define my life today. They can be summed up as: serendipity, opportunity, choice, and confidence.
Surprisingly, I’ve found that many of my friends appear to be following a similar pattern, even in non-technical fields. Contemplating these moments of achieving a “new normal” is a fun thought experiment to see how you’ve grown and steer where you’re going next.
Event One: Serendipity
My first critical new normal happened when I was 12 years old. I participated in an online BBS dedicated to writing cheat programs for a popular web-based game. I would spend two to four hours per day after school on this BBS, socializing with a group of people that spent their free time finding ways to exploit web games and writing simple Windows programs to automate these exploits.
By the age of 14, I started a business with a friend from this BBS – that I had never met in person – creating web game cheats and selling them to people for $25/month. I made over $400 per month as a freshman in high school, felt fabulously wealthy, and continued this until I received a cease and desist order from a few companies and was forced to shut down (mostly at the insistence of my confused parents).
None of my real life friends understood what I was doing, and my parents were concerned that I was acting abnormally. I had unintentionally changed my perception of normality to spending every waking moment (that my parents let me or didn’t know about) honing my programming skills in order to cheat video games. After all, that’s what all my internet friends were doing. It was normal!
Event Two: Opportunity
By the time I was 18, my normal was set: I was programming every single day, spending a majority of my time with open source, and blogging about anything and everything. I even submitted a detailed proposal to PHP’s Zend Framework at night while on vacation in Tokyo. I knew I had found a passion.
My activity in the PHP community and popularity of my now defunct PHP blog (which at its peak had over 10,000 subscribers) helped lead to my first opportunity: a short two sentence email asking if I wanted a job as a Ruby on Rails programmer.
After a few weeks of talking back and forth, I got the job. This company specialized in building MVPs for new tech startups. This was my introduction to the world of startups. I worked as a developer for this consultancy at at least four different tech startups a year, helping build their MVPs.
I started building more and more web applications targeted at consumers rather than simply building cool technical projects or working purely on open source. My normal shifted again: Build useful web applications for people, ship fast, and charge for it. I fell in love with startups.
Event Three: Choice
Closing in now on graduating college, I knew I had to move to San Francisco and work for a startup. This was a fundamental shift in how I previously reached a new normal. Instead of waiting for things to happen, I chose to take the initiative and move to a new city where I had no friends in order to surround myself with what I wanted to become.
Coincidentally, through the same friend I started the web game cheating business with, I met Brian Wong in 2010 and became the first hired engineer for Kiip. I moved to San Francisco in 2011.
At Kiip, I had courtside seats watching Brian raise funding. I was able to meet venture capitalists and founders of dozens of companies through social events. I met young successes, up-and-comers, and industry veterans. Each showed me a piece of what defines San Francisco tech.
Normality had changed again, this time by choosing who I surrounded myself with. It was normal to relentlessly follow your passion. It was normal to believe that you could chase big dreams at unsurmountable odds and succeed. It was normal to start a company, at any age.
Event Four: Confidence
In mid-2012, after working at Kiip for just over two years, I made the decision to leave and start my own company: HashiCorp.
This was never part of any plan. I thought I’d be at Kiip for at least four years and I thought Vagrant would forever remain an obscure side project. Instead, the rapid increase in popularity of Vagrant, the pressure from companies for certain features and support, and my desire to work on it more hours of the day pushed me to make a change.
I was told many times before that I should start my own business working on Vagrant. But it wasn’t until my perception of normality changed from my choice to move to San Francisco that I was able to gain the confidence to really take the leap.
And this is where I sit today. I believe I am on the cusp of another change in normality. I do not know when that will be or how my behavior will change, but I’m excited to look back and see how my decisions and ambitions are steered because of it.