I’m proud to announce the first stable release of gg, my alternative Git command-line interface! This has been a release over two years in the making: I’ve battle-tested gg across many different workflows and projects. It’s saved me tons of time every day, and I hope it can save time for others too. Download the latest release and try it out for yourself!

I’m excited to announce that I am joining the engineering team at YourBase! YourBase’s flagship product is a build system that greatly improves the speed of software development with very little configuration. It brings me back to what I’m passionate about: improving how people work by making software simpler. It’s still early days, but I’m excited by the enthusiasm and the respectful, remote-first culture I’ve found at YourBase. I can’t wait to see what we build together!

Since I’ve started working at Clutter, I’ve grown to enjoy the Apollo React Client library. However, I’ve noticed that the client’s caching behavior can be difficult to understand and cause surprising issues, so I’ve decided to collect my findings into one easily digestible post. This post assumes a basic understanding of GraphQL.

I’m excited to share my hobby project from the last few months: a GraphQL server library for Go. While it doesn’t implement the whole spec and might not be ready for production, I think it’s in a useful enough state to share more broadly. I’ve tested this library out with some toy projects and the results have been promising: I’m able to quickly publish a Go struct as a GraphQL endpoint.

Check it out now by reading the docs and adding it to your project with:

go get zombiezen.com/go/graphql-server/graphql

It’s been a little over a year since I wrote about using Getting Things Done (GTD) to organize my life. I wanted to circle back about what worked well and what I learned over that time.

It’s always interesting to me to compare different approaches to solving the same problem. Git and Mercurial are two version control systems that came out at similar times, trying to address very similar requirements. Git came from a very low-level systems perspective, whereas Mercurial spent a lot of effort on its user experience. Despite what you might think, their data models are remarkably similar. It’s from this observation I started my side project — gg. I found myself greatly missing the experience of Mercurial, but I’ve resigned myself to the fact that Git is here to stay.

I came across a rather interesting challenge today while working on gg. I am trying to replicate the behavior of hg pull, and even though I’ve worked on gg for over a year now, I still haven’t reached a behavior that I’m satisfied with. I’ve finally realized why, and it boils down to a very subtle difference in the data models of the two systems.

July 19, 2019 will be my last day at Google. I will have worked at Google for 6 years, 3 months, and 11 days (even longer since I was an intern). After a few weeks hiatus, I will be joining Clutter to work on their storage and logistics services.

Frequently when people discuss what is a “good” Go library, they usually use terms like “idiomatic” or “the Go way”. These terms are imprecise and make it difficult to discuss the merits of different API designs. I recently re-read Don Norman’s The Design of Everyday Things and realized that the same principles of design discussed in the book can be used to evaluate the design of APIs.

When I was mentoring a FIRST robotics team, the fundamental revelation I had was seeing how the robot the team built became a part of our identities. When we won a match, it was validation. When we lost a match, it was a reflection of our failures. Being a mentor gave me a level of detachment, but the students working on the robot did not have that luxury. For many, this was their outlet they took pride in. And losing gave that wretched inner voice (the voice of the bullying they had endured) hold to beat them down.

When I started working in the software industry, I soon came to realize that we are not that different (myself included). Even the terminology — team — evokes tribalism. Pitching a design to your team and having it fall flat feels much the same as losing. But often in industry, you don’t have the safety net of a mentor. You either have your previous experiences or you don’t. And there’s the pressure of financial stability. Fundamentally, this adds stress and hampers creativity. (Also open office plans, but I digress.) To me, that’s why I prioritize supporting my team above all else. The easy thing is to be critical of others; the right thing is to find how you can help them succeed. Creating something worthwhile usually requires vulnerability. Don’t exploit that: see it for the gift it is.

(Originally from a Twitter thread.)

As I’m shutting down my Tumblr, I took one last look through all my fandom blog posts. Not even my most wholesome fandom posts are safe from Tumblr’s new content policy. Good riddance.