“My bad opinions”

2020/04/21

Coding for Fun

Before COVID-19 came and cancelled all the conferences we had lined up, I had started working on a talk on our collective tendencies as software developers to end up doing work and automation that ultimately demands more effort and time from us than if we had done nothing, or something much simpler.

Of course, in writing my talk and with the pures irony available to me, I ended up drifting aside and instead started programming my own slideshow software. I have my reasons—not very good reasons, but reasons nonetheless—for writing it, but regardless of what they are, I don't encourage anyone to actually use it, and I'll explain why in this meandering post, where I do a kind of personal retrospective of my last few years of maintaining OSS software.

Being Tired

Over the last few years, I've done a lot of open source work. Mostly library work, and Rebar3, which became the de-facto Erlang build tool. I also did a lot of community work as well: talks, helping set up the Erlang Ecosystem Foundation, writing books, recording videos, participating to podcasts, offering support for the open source libraries, and co-organizing a conference. I've kept doing this while working 40 hour weeks, sometimes while wearing a pager. I nearly burned out. I don't believe I actually burned out; what I had was nothing compared to folks I know who actually did, but I was clearly headed that way.

To some extent, part of the problem is that as I got more involved into all kinds of things, I also kept amassing more and more responsibilities that I'd take seriously. And while it's rewarding to do work that people appreciate, doing it well ends up taking a similar amount of effort and attention to detail as you would at work, with a full time job. Another thing is that over time, by virtue of being a remote worker who participates in a lot of community activities, my personal and professional lives get tangled; if I mess up in hobbies—or general online stuff—it may end up impacting my professional life as well. The end result is a rather exhausting pattern where work is work, and then hobbies are also work, and there's limited time for the rest.

And so for maybe two years or so, I kept doing a lot of that hobby work, even though I took limited satisfaction in it. I worked on things that I didn't feel like working on, because it felt like I should, that it was the proper thing to do. This kind of drive has historically been good to me; it's the kind of stuff that makes me finish writing a book, digging deeper in research, that made me professionally push myself further. But the more time I spent doing it, the more it felt like a chore.

I eventually found about the concepts of obsessive and harmonious passions. I'm obviously not trained in pyschology (nor any other humanities' fantastic field of studies), but this dual model was a very interesting way to frame things. I read some of the research form Vallerand and regardless of how much information I can safely extract and apply from these, it became more or less clear to me that a lot of hobby work I do with programming became more deeply entangled with my identity than I thought. I'd feel guilt not doing the work that had brought me so much—mostly my career and a bunch of self-worth—and I was in a pattern of moving towards less and less sustainable ways of spending my energy.

Around that time there were other things going on as well, but a lot of it ended up apparently being related to this tiredness and the way I'd apply pressure on myself.

Projects Done for Other People

Another thing that I think became a factor is that a lot of the hobby work I do with programming turns out to be useful for people other than myself. I'm at a place in my life and my career where I understand the cost of code and software, and the maintenance of it (hence my talk hinted at in the intro). If I can think of something I could write software for, I sit down and think of ways to restructure things so I don't actually need the software for it. It's great.

But all my coding work, whether done professionally or in my free time, is for things I don't personally need or use much. I've never been a user of the software I worked on in my career. Most of my open-source libraries have been developed for things that have to do with larger-scale systems that I don't write for myself. I code less than I used to professionally (with the years I'm turning more useful in sharing experience and improving others than working on code myself, apparently). Rebar3 is a thing I use everywhere, but at this point most of the feature work for it is done for other people's needs, and if most of my free time work is on Rebar3, then my main use of Rebar3 is to maintain Rebar3! Clearly I could get rid of all that software at once, and focus on more important things.

We get much appreciated thanks, but then you go online, and you also get the expected complaints: the documentation is never friendly enough, the code base "is really terrible, a lump of technical debt" (I agree, it's just not fun to hear it out loud), it's too slow, too unscalable, too confusing, we're doing it wrong, "is the person who designed this stupid?" (maybe! some of it is ours, some of it is stuff we kept from previous tools to avoid breakage!). In fact, all the work we do is more traditionally included in Erlang tooling, which is most often described as "not as good as Elixir's (or some other language), but catching up."

It just gets hard to find fun and distraction in what is essentially doing work for other people, for free, while being told it's often just not very good. It'd be easier for me (and Tristan) to just break everyone's builds and release more backwards-incompatible versions with new requirements that makes our codebase nicer by forcing everyone else to do the heavy lifting of adjusting their projects to ours rather than the opposite (the complexity and work has to exist somewhere). We could keep the focus on small projects in a shape we like and tell everyone else to figure it out on their own. Make the argument that "future users could be more numerous than current users so we'll optimize for them."

It would be less challenging, possibly more fun, but not necessarily something we think would line up well with the ethics we have. If you invite people to use your things and line up a community around it, you do owe them something. They don't own you, they don't own your time, but by the act of migrating and adopting what you offer, they accept for everyone to be in it together. I ended up wanting to scale time back to focus on the biggest (or personally fun) issues, while still providing enough oversight to prevent staggeringly higher debt. Self preservation gains importance with time.

Doing Things for Fun

One thing I noticed over the last few years of tiredness and juggling projects done for other people is that I no longer had that drive to just experiment with things, dig in and learn, do write-once projects that I had fun with for a while and then could forget. Everything I'd publish online had to be something I felt could be in a usable state by random people, well-tested, usable, and that I'd be ready to support. I think I tried to extend the professionalism I try to display at work back into my hobbies. Something similar to the old Mark Stivers cartoon. It felt weird that something I spent the larger part of a decade enjoying was suddenly exhausting me so much, and I felt lost.

I looked for other hobbies, revived some older ones (hello bass playing), re-centered a few things in my life (remote work and virtual hobbies make for an easy way to miss the important people directly around me!), started accepting that time spent resting and not being productive or actively learning is a good investment.

After a few months of taking things easier, my energy and drive came back, almost out of nowhere. I did the advent of code on video around the holidays, and enjoyed myself for a few weeks. Then I stopped when I no longer had fun. A few weeks later I started the compiler refactoring work in Rebar3, setting aside a few hours every week or two to do it (its complexity needed enough attention that it's not useful to do it half an hour at a time). And then I took more breaks.

My talk deadline started coming through, and I had to do a bit more research on footguns and system effects of software. I started drafting my talk in text over my VPS, on my phone, on a bus. And I started wondering if it wouldn't be a lot nicer to have my slideshow software accepting that? Yes it would be nicer! And there are people out there who have written tools that do that. But I always had more gripes with slideshow software. I wanted something that could do the following:

As far as I know, nothing handles this stuff all at once. So I did the fun thing: I set up to figure it out. I picked the tool I wanted (Erlang) to learn to do things I'd never done before (a Desktop GUI app), and it went fine.

So far I've hit a bunch of these objectives. I haven't tested it on Windows yet, I got a few compatibilities issues between OSX and Linux, I haven't checked how portable it is (I'm sure it's doable if I ever feel like building enough custom Erlang distributions to figure out the static linking required), It doesn't execute code, but the rest is there. I got some weird ass issues still, but who cares, it's my software and I can live with it and fix it if I ever feel like doing so.

The main thing, though, is that I had fun doing it, and I didn't feel any form of guilt when I took a break from it. I tried it live for the first time in a zoom meeting over our engineering department and it went okay (see the zoom issue of not picking up changes on a window that isn't the active one when broadcasting only to that window). I've learned new things about doing GUI stuff, and it should improve my own personal workflow when working on presentations! I didn't give much of a shit about having the cleanest code even though I still tried fancy-ass per-slide FSM-based work to deal with memory allocation and deallocation of Wx resources. There are almost no tests other than the shit I knew would annoy me if I were to test it by hand. I don't care, I had fun.

preview slide from the slider software demo

It's part of why I'm writing this today. This blog post isn't meant to be a big learning experience. I felt like writing. I wanted to talk about maintaining code, and the fun new project I had on the side. That's it. And in doing things I found fun, I probably learned more than by just doing things I felt I had to. Turns out that when you learn whatever you feel like learning and you’re having fun, you might learn more than if you’re trying to make an investment out of it.

So if you ever end up looking at my slideshow software and going "oh that sounds good, I'll use that," do remember that I'm doing this with the explicit notion that I don't want either of us to owe anything to each other. I'll be delighted if you contribute things you find useful or fix a few of the things I fucked up. If there's anything else going on? You're on your own, buddy. Maybe you should have used something off the shelf, or written your own.

The license says the software is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, and I mean it this time.