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.

This is my first post to this blog in a long time, and it is with a fully new engine! zombiezen.com is now entirely hosted by Firebase Hosting and generated by Hugo.

When I first joined Tumblr, it was a very different blogging service than what it has grown into. And especially now that I am working in open source and wanting to post more regularly about more in-depth technical content, I want to have a platform that I can post to and not worry about my content going away. As such, I’ve also copied my content on Medium into this blog.

In this blog post, I’m to do a deep dive into the specific steps and tools that I used to achieve this new mindfulness. If you haven’t read my first blog post about Getting Things Done, you should take a look. I’m not recommending the tools here in any capacity other than from my own personal viewpoint: I’m not getting paid to promote these. I still recommend reading Getting Things Done by David Allen to understand the theory and reasoning for why to use particular tools, and adapt for your own circumstances.

It was a packed day: all meetings that required my attendance. The only breaks were for breakfast and lunch and a lone 30-minute break between other meetings. I had to meet with my remote manager, my new product manager, one of my team members, and customer liaisons for a new customer we were hoping to work with. On top of that, it was Agile sprint planning day — I had to run the task planning meeting and moderate two design discussion meetings. In between all that, I needed to write up my top accomplishments to my manager for performance review. The previous night, I realized that one of my mentoring meetings tomorrow didn’t have enough time to actually accomplish my mentee’s goals. All the while, a wave of emails and pings were crashing in. How was I going to get this all done?

I originally gave this as a talk at the Seattle Go Meetup on 2017-02-16 (video). The following is a refined version of the talk, not just a verbatim transcript, based on my speaker notes.

This report details an experience I had while writing an RPC system in Go. While Go’s standard I/O libraries make a great many things simple, I found cancellation to be more complex than I would have liked. Parts of this situation have improved in the last couple of Go releases (as I have noted below). I hope this positive trend continues in a way that allows the Go ecosystem to easily propagate cancellation, deadlines, and request values. My intent in this report — as well as the proposal I created back in May 2017 — is to give background and feedback to inform future design decisions. Suggestions for solutions welcome!

(Thanks to Ian Lance Taylor, Damien Neil, Cassandra Salisbury, and Andrew Bonventre for reviewing this report for accuracy and clarity.)

In April, I relaunched moviegolf.com, a website I’ve operated since 2009. Since this is one of the flashier programs I’ve written and certainly one of the longest-lasting, I wanted to recount its history. My style of programming has definitely shifted in the intervening years.

It’s long overdue, but… moviegolf.com is back and better than ever! Give it a try!

A quick recap of this saga: moviegolf.com is a website I created in high school to find the optimal path between two movies based on shared actors. However, in the years since, it has bit-rotted significantly. At the time, I used Freebase, which Google acquired for use in the Knowledge Graph, but shut down in 2015. Since then, the site has limped on, forever stuck with an outdated set of movies. moviegolf.com was in a deep coma with an uncertain future.

My goal in doing a rewrite was twofold: I wanted to have a Go service running in production that I understood intimately and I wanted to make the service more self-sustaining. I made an unsuccessful attempt to do this about five years ago. At the time, I was discouraged by App Engine limitations and the difficulty of acquiring data. Luckily, the data from Freebase lives on in Wikidata with a much better data crawling story, but the file formats and API are totally different. Getting the data automatically required a total rewrite of my lousy ~10 year old data ingestion pipeline. I took the opportunity to rewrite the search algorithm, storage backend, and UI while I was in there. I did scrap some features for the sake of time, but nothing that I felt was critical for the experience. I wanted to focus on the core “golf” experience. From start to finish, this took a little over a month of weekends and evenings. I’m planning on doing a write-up of the salient technical details soon, but in short: GCP rocks and simple components make for robust services.

Golf on!

Cyber security has become critical to ensuring public safety in the US. There’s an absence of good coherent information, and people are rightfully scared and confused. I’m drafting another article that explains cyber security principles in greater depth, but it’s not ready yet. Until then, I’ll get straight to the practical tips:

1. Encrypt your phone. Instructions from CNET. This protects someone from looking at your phone’s storage without knowing the passcode. If you only follow one step from this guide, follow this one.
2. Use Signal for communications. Messages and voice calls made through Signal are encrypted such that only the two devices communicating can read the messages. However, if you don’t encrypt your phone, then the messages can be compromised with physical access to the phone. Encrypt your phone!
3. If you think you are about to be detained by police, turn off your phone. Police can legally coerce you to touch the fingerprint scanner, but cannot legally make you divulge a passcode (source). By turning off your phone, your phone “forgets” the decryption key to the storage, thus requiring the passcode on boot. If you are participating in protests or other situations requiring elevated security, disable fingerprint scanning for sign-in.
4. Be cautious of apps you install and use a phone from a reputable manufacturer. I trust Apple and Google, but use your own discretion.

Beyond this, the usual security advice applies — don’t visit sites you don’t trust and use HTTPS where possible. Stay safe!