Three Quotes from Early GitHubbers
A few things have stuck with me from my time at GitHub. I learned a lot from a lot of smart people there, but for today I just want to chat about three quotes.
Code
We can make good tests run fast but we can’t make fast tests be good. — Ryan Tomayko, GitHub’s internal testing docs
This line jumped out at me when I first read it, and I’ve thought back on it a lot since.
Tests are funny things. It feels like writing normal application code, but it’s not. Not really. A lot of the time I’ll catch myself refactoring test setups, making weird optimizations, sometimes even metaprogramming dynamic tests… but at the end of the day it usually doesn’t matter. What matters is having explicit tests that make it easy for you to understand both 1) what is failing, and 2) how you can fix it quickly.
The test suite GitHub runs is extremely large, but there’s a continuing effort towards parallelizing it and throwing it at beefier and beefier machines as the bottom line allows it. The result is a suite that runs in minutes, not hours.
In a more general sense, though, I think back on this when I want a quick affirmation of what programming really is all about: get it working, and then make it faster later.
Writing
I really like the draft that you wrote. Now remove half of the words. — Kyle Neath, pretty much all the time
In the earlier days, GitHub’s culture used to be emphasize “if you built it, you should also ship it”. Meaning if you built or helped out on a particular new feature, you get to (and should) write the announcement post. We’d then toss these drafts around internally quite a bit, get a lot of opinions on word choice and how it felt, and then post the draft.
Kyle would pretty much always tell me I wrote too much. Without fail, remove half the words tended to be the ideal editing approach to take.
Less is more. Shoving everything into a blog post — or a proposal to your team, or a sprint retrospective, or really any prose you write professionally — means you take the emphasis away from the things that are really important and focus the reader’s attention on less important aspects.
Readers should never have to wade through a lengthy blog post and wonder what the top three most important aspects of the product launch was.
Roles
Yeah, I mean we’re behind you here, so if this isn’t working out anymore, let’s try you somewhere else. — PJ Hyett, during my first burnout (paraphrased)
My first year and a half or so at GitHub was basically starting and running GitHub Enterprise. For about a year or so, I was really the only one working on it, so I wore all of the hats: engineer, support, sales, ops, design, product. I had help from the rest of the company, but we were only 10-20 people, and everyone was pretty heads-down on their own work.
Wearing all those hats by yourself, plus focusing on a business that’s not known for its agility and novelty — enterprise software sales — definitely is a recipe for trouble. At a certain point I just hated my job, even though I loved working for GitHub.
I got drinks with PJ one day, told him I wanted out from the enterprise world, and he was like yeah sure, I definitely get it, let’s figure something out. There were logistics to sort, people to hire, but it was pretty straightforward agreement.
I bring this up now because I don’t think it had to have gone that way. He rightfully could have said “ah bummer, well sorry dude, catch you later”; my skillset was pretty replaceable, and there was a huge need for bringing more people onto the Enterprise team, not reducing it.
Investing more in the person than the role is more important now than ever, because this industry really fucking sucks at figuring out how to support their employees’ mental health.
Sometimes roles change, sometimes people change, and I think it makes a lot of sense to initially try pivoting someone into a new role. Replacing people is hard and expensive.
Anyway, those are three quotes I still think about from time to time.