Once a Maintainer: Michael Grosser
On building software with an opinion
Welcome to Once a Maintainer, where each week we interview an open source maintainer and tell their story.
This week we’re talking to Michael Grosser, Engineering Group Tech Lead at Zendesk and creator of multiple ruby gems, including single_cov, parallel, kennel, and ruco. We talked with Michael about moving from animation to programming, reading code you thought was dead, and building opinionated software.
Once a Maintainer is written by the team at Infield, an app that helps engineering teams track and plan their dependency upgrades.
How did you get into programming?
I basically started with programming because my mom, she had like an old PC workstation she got from work. There was nothing you could do with it, it was like a typewriter - it didn't have programs or anything. We were searching around for what we could do with it, it looked kind of fun. Then we found there’s a program you can type up yourself and then you kind of figure out how it works and it's like, “Oh, I can change this to that” and there's something else and something else.
That’s how it started. Then we also had some stuff in school where it was like, oh, you could do programming as a course and some scripting in games. I wrote a script to turn your gun up and then turn it down 5 degrees to offset the recoil in the game. It was very exploitable and it always goaded you into taking one step more, one step more. It got more complex and more complex and it kind of turned me into a programmer, chasing this next thing.
There were other people doing scripting and it was always very simple. It was just like, oh, if I press a button, then it shoots this gun and then switches to the next gun. And I was like, well if you can do this, then you can also do that. So I made it so that if you hold the button, it switches to this gun, and it shoots as long as you hold. And then if you let go, it takes your other gun. As far as I know, I was the only one in this game doing really crazy stuff with it. Other people had like 10 lines of scripts for just like, oh, I need my health pack on this key or something. But I had like hundreds and hundreds of lines of stuff. That game was Enemy Territory Fortress. It was good fun.
And when you graduated high school, did you go straight into computer science?
I was scared of computer science because it was like hardware, math, and it seemed all complicated. So I went into something called Media Informatics, which they kind of sold us as a little bit of programming, a little bit of animation - videos and stuff. I was like, oh, this is perfect, I'll just take that. And then I started hating the animation stuff because it was so cumbersome. So I ended up doing the programming and kind of wiggled my way into software engineering.
I started with websites, some CSS, JavaScript, so it was a mix of media and informatics, fonts and stuff. Then I started a company that did complete websites, we did front end and backend, and I got deeper into infrastructure stuff. Then I went to this e-commerce site, it was like an Etsy clone. They were very frugal but also very fun. Their traffic was very spiky. They did these TV commercials for certain products and it was like, you have a million visitors in 20 seconds when the TV commercial runs and if the site goes down 50% of the people are just gone and it's super bad for branding. 99.9% of the users would be new users. Crazy. We did some fun things, and after I left they ran out of money and I thought OK, my code is dead. But some years went by and like five years later someone came back and asked about my code. They were like, “We have questions. Why did you write this?” So it’s always a good reminder to leave hints for yourself. You never know.
How did you find your way into open source?
I actually started super early with open source, even on my first job, and it was mostly just out of frustration. Something didn’t work and it was like OK, find the repo, make a PR, fix it, run a fork, stuff like that. At my first company we built these website experiences for people and some of the things were were basically like, take an open source doohickey and customize it so it works for them. I think I over-shared a little bit in the beginning, mostly because I knew that if I leave it in this company it's just gonna die. This is a nice trick that I figured out, so let’s share it.
Then a lot of my bigger projects came from thinking that everyone’s doing it wrong, this is bullshit, I’m just going to do it right. For example, with single_cov, I was just frustrated with the fact that you write some code, and then you wait for your coverage report, you send it to this other thing, and then your coverage report tells you it's X percent and then you have to click through some UI and do stuff. But what I want is just to run your test and it fails. This line is not covered, go fix it. Simple things like that where it's just like, the workflow feels wrong. Just make it fail locally. Done.
So single_cov was building a tool for yourself where you had a strong opinion about how you wanted the workflow to be. What about the parallel gem? It’s a small bundle of code, but it’s used by so many companies now.
Parallel also started with a frustration. You want to fork something and then you have to pipe it back and there were a bunch of tutorials on how to do this. Then you have 10-20 lines of ugly code in your file, and there’s this edge case and that edge case. I think there were a few things that did this multiple processing thing, but concurrency in ruby didn’t exist yet and they were all super complicated. I just wanted a simple gem to fork something and get it back. So it started from that. Then it was “oh, this doesn’t work with queues, and it doesn’t work with fibers” so it’s built up over time, but it’s still in a manageable state. I still like it as a tiny little library that does one thing right.
The fibers thing is interesting because that’s a situation where the Ruby language has evolved since you first wrote the gem - it’s way more sophisticated around concurrency and parallel threading, all these things have been built into it that didn’t exist when you started. What’s it been like managing your gem as the language changed?
A bunch of things were driven by pull requests, like it doesn’t work on Ruby 2.5, then 2.7, etc. So “it doesn’t work on X” - let’s update it.
Often it’s just me saying, “Oh, there’s this new feature it doesn’t work on, let’s get it to work with that.” And Rubocop has been really good at getting people to try new things.
And then once every few years I just read through the code and think, why is this so janky? This doesn’t make sense, that doesn’t make sense. And then it’s like oh, you meant to do XYZ. If you look at the code again you can just delete everything and simplify. Or there’s a newer, nicer way of dong something, so let’s make it work that way.
I noticed you’ve had a lot of community contributors to parallel - does anything stick in your mind as an awesome contribution to something that you ran?
There isn’t one person that did one amazing thing but parallel tests is a good example, where people just came and said, “Here, this is Gherkin support or Cucumber support” - major chunks of functionality. I wouldn’t have the expertise or willingness to invest my time to do that. And I’m not going to make well educated decisions on how this is supposed to work. So it’s really nice to have champions for certain large areas.
What are some other open source packages that you like?
I checked through what I use a lot:
I like bump, which is a super tiny gem that just upgrades your gem versions, but it’s pretty clean and saves me a bunch of work.
I’m using mocha a lot for stubbing in a mini test codebase. It works fine, has one or two gaps where they do multithreading.
I use web_font a bunch, it’s just very nice - you just block everything and it’s all the syntax you could possibly want, super user friendly.
Another nice library is gutentag, which is a tagging library. A bunch of tagging libraries are Rails-based and they do a bunch of ugly stuff under the hood. I was building some website and was trying to do some tagging and this was the only one that did it right.
Rubocop is on my love-hate list because Rubocop is so complicated. It has so many options. There are some things that Rubocop doesn’t do perfectly, but I understand it’s really hard. It prevents so much maintenance and I don’t have to go into PRs and say don’t do it that way, do it this way.
I also have minitest and RSpec. I like how simple minitest is, but it doesn’t come with wheels. It’s just like, drag this container behind you. You need wheels, right? That’s why I built maxitest, which is minitest but with all the obvious things you need, like red and green output for your tests.
Who’s someone you think is doing really interesting work?
On the Ruby side of things I would definitely list tenderlove for just doing interesting things and going very deep into ugly places, but also having fun with it.
I also noted down eileencodes who did the multi-database stuff. I can appreciate it’s so hard, it’s so annoying, everyone has different opinions on how databases should be sharded and replicated, managing different connections, sending the reads here and the writes there, and she actually went and said you know, “We’re going to fix this.” We’re going to put it into the core library. That was the main problem of this database landscape, is collecting all this knowledge and making a base layer that at least kind of works for everybody. That’s a really good achievement. It’s like herding cats and I don’t fancy doing that.
And rafaelfranca - he’s always available, he’s everywhere. Every time I did a Rails PR, somehow he was there. One of my biggest frustrations is just nobody being available - nobody really knows, nobody really cares, the PR just sits there. So it’s really good to just have someone active and facilitating. That’s what I’m trying to do at my company. Trying to move people forward.
How can we get more people into open source?
The easiest thing is to just say “Hey, PR appreciated” if it’s a relatively simple thing. Ideally people will say I want to contribute to open source, what can I do? And if you have a bit of a to-do list you can leave issues open and mark them as easy for beginners. If someone comes in and just wants to touch the code, they can say OK, I have an hour, I can do this. They can just get something done, push it.
Otherwise, if someone opens an issue and it’s kind of trivial, I will try to say “Oh you can just change this” and kind of trick them into making a PR. It’s about not frustrating people. If they made the PR but Rubocop failed, or there’s a small syntax thing, sometimes I’ll just merge it, fix it up myself, and push the change. So they have a nice smooth experience of getting something merged and they didn’t have to go back and forth over several days.
Are you an open source maintainer? Reach out at hello@infield.ai.
To share this post, hit the button below.