My Time at Pusher

This summer I’ve been working at Pusher (“powering realtime with spit and glue”, as my mug says). When I’m not interning, I’m doing a Ph.D in testing concurrent programs at the University of York, so it was a bit of a change. Not many people arrange a nice relaxing break by getting a full-time job, but the academic machine is a strange place to be a cog.

The main project I’ve been working on is a distributed message bus written in Go using Raft consensus, which is hoped to replace the current Redis-based system (and is now deployed on one production cluster!).

It’s a bit different to what I expected. When I had my interview a few months before, the plan was to work on testing the current Haskell-based replacement system. Unfortunately, that had to be scrapped due to garbage collection performance (read about that in this great blog post).

So, we switched to Go.

Go

I’d never written any Go before June, now I’ve written maybe 30,000 lines across four projects (three work, one personal). Not all that is live, bits of it have since been modified by myself or others, but it’s still a substantial amount to write. I now consider myself intermediate at Go.

Go is a bit of a polarising language. It’s very simple and easy to pick up (for evidence, see my summer), there’s not a lot to the language. I won’t get too much into whether it’s a good language. Go is very good at what it does, which is being a simple tool allowing you to write fast code without too much effort. On the other hand, I think some decisions made in its design actively hinder, if not prevent, writing verifiably correct code and make it easier than necessary to slip up.

I had the opportunity to go to GolangUK, and there were some really interesting talks. When the videos are up, I particularly recommend Static Deadlock Detection for Go by Nicholas Ng, and What is a container, really? Let’s write one in Go from scratch by Liz Rice. The former is quite close to my research (although taking a different approach: static analysis rather than testing), and I’ll be keeping an eye on further developments; the latter was really interesting because containers never seem to be explained well, and seeing one live-coded in about 50 lines really helped me understand what they actually are.

Distributed systems

In addition to never having written any Go before starting at Pusher, I’d never programmed a distributed system either. Fortunately, the Raft paper is very approachable for beginners, and the library we were using quite clear. It was definitely a new paradigm to get used to, although I think I would have found it much harder than I did if I were less familiar with concurrency. There were definitely a few things which tripped me up, but on the whole it was alright.

As I plan to look at testing distributed systems for the next stage of my research, it was great to get some actual hands-on experience. My simplified for-research mental model of a distributed system didn’t change, but it was nice to get some confirmation that it wasn’t way off-target.

Other things I liked

• I made meaningful contributions to meaningful projects.
  Anecdotally, it seems that in a lot of places which take interns there are specific “intern tasks”, which are far simpler than “real tasks” which the actual employees work on. But I felt that everything I worked on was useful and something which actually needed doing.
  The main project I was working on is closed-source, but another which came out of it is now public.
• People worked normal hours.
  It seems that there’s an expectation of doing lots of overtime in tech. At Pusher, the hours were flexible, people tended to arrive around 09:00 and leave a little after 17:00. Far from the 60+ hour week horror stories I have heard.
• London is surprisingly nice to live in.
  I thought I would dislike it, but there’s a lot to do. Lots of museums and parks and, if you like swing dancing, there are classes and socials every day. But, as they say, with great power comes great responsibility. It’s easy to spend a lot (particularly in the many book shops).
• I helped start a Haskell meetup.
  Having previously ran a failed Haskell meetup in York, I was impressed with how easy it was to start one in London. In York I almost had to beg people to show up, but there are just so many people in London we actually had to limit attendance! There have been four events so far, and hopefully it won’t just fizzle out without me (and if you’re a Haskeller in London, offer to run a session).
• Lots of snacks in the office.
  Salted almonds are really nice, get some if you see them.
• Lemon, the office corgi.
  
  

If you have any comments or questions, feel free to send me an email or contact me on Twitter (@barrucadu).