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
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.
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
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.