Let’s start by clarifying what I mean by the question.

---

I’m resurrecting a years-old nearly-finished blog post draft here. What’s funny to me is the time period when I wrote it. I was working for an utter car-crash of a company, one that I am absolutely certain in retrospect existed only to raise money serially and keep its founder’s friends employed. Any time the product looked like it might ship, they pivoted. (I do not care about this. It’s on the VC who falls for it, IMO.)

O Silly Valley, how silly you are.

I was fairly miserable in the brief time I worked there. This side project was a light in the darkness at the time, and apparently I wrote about it.

---

Last month, over the course of two weekends, I designed, implemented, and shipped a little command-line tool. What this tool does is not particularly important, except to note that it solved a problem I had repeatedly encountered while working on some internal tools for my job. I understood the problem domain well, and it was indeed an irritating problem, and solving it will make my next set of shell scripts easier to deal with. Also I was somewhat annoyed that I’d just spent a month writing tools in bash¹ and not in Rust, a language I had wanted to be using. I scratched two itches at once by writing this tool in Rust. I went some extra miles with this one: I wrote tests. I wrote docs. I wrote examples. I automated its release process. I published it on crates.io, something I rarely bother to do with my Rust projects. And then I learned how to create a homebrew tap so I could make pre-built executables available to people who don’t have Rust installed.

I do not expect anyone but myself to use this tool, so all of this work was “wasted work”, in some sense. If I’d done all this in my workplace and then had it all thrown away, I’d have felt discouraged. But here, in a side project, it was pure fun. It was fun to read the documentation for libraries I ended up not using. It was fun to install tools that were vaguely related and try them out.

It was fun to write some code, realize it was all wrong, and rewrite it again more tightly. And then to go back to it again later and tighten it some more. To write comments noting that something I’d written wasn’t great and I’d get back to it. Maybe.

It was fun to polish it all up and finish it. It was fun to hit a level of completeness that I am rarely able to reach in my employment, even when I’m the person running a team and encouraging polish and completeness.

Why was this entire process so much more fun than anything I experience during normal day jobs? ²

I let myself blurt out some answers to that one here:

• It scratched my itch, not somebody else’s.
• I knew what I was building and why.
• I knew who I was building it for.
• I didn’t have to deal with bike-shedding and what-about-ery from people second-guessing design decisions.
• There was nobody else’s taste to consider as I designed.
• I was free to make decisions; no need to socialize them and deal with disagreement.
• I could explore the problem space freely. Dead ends were fine.
• There was no time pressure.
• My work sessions weren’t interrupted by context-switching into different work. (They were interrupted by non-work concerns, like feeding hungry cats.)
• The requirements didn’t change unexpectedly.
• When the project goals did shift, the entire team of one understood why and were aligned with the need to change.
• There was no scope creep. When an acquaintance suggested an interesting possible feature, I was free to reject the feature.
• I could pursue my own standards for quality.
• How often do I have time in a paid job to write second and third drafts of code? But that’s when code (and prose writing) starts to get good.

There’s lots of overlap in those, but I’ll let them stand without editing because the repetition helps the themes emerge. None of those themes are surprising to me, by the way, and I suspect they’re mostly not surprising to you.

Why, I ask myself, is work almost never this fun? Should work be this fun? Is it possible, even?

Motivations

A while ago I watched a video with some very cool illustrations for a TED-talk-ish lecture by Dan Pink: The surprising truth about what motivates us. It’s only about 10 minutes long. Don’t let the TED-talk-ness stop you; go watch it.

You back? Cool. Let’s talk about that lecture. Now, there are things in I would argue with–twelve years on I’m a lot more cynical about open source than Pink was then–but that’s not the heart of his point. The heart of his is point is what motivates humans to do complex tasks:

• autonomy
• mastery
• purpose

I note, in retrospect, that all three of those needs show up in my blurts about reasons why this project was more fun than a lot of work I’ve done for pay. I’m going to use them to give structure to the rest of this discussion. How did my personal project provide them? How does work not? Can work provide them?

Autonomy

Autonomy is somewhat at odds with the need for coordination and cooperation that dominates engineering in workplaces.

When I mention “what-about-ery”, what I mean is objections from somebody whose values are different from mine. Or who is thinking about edge cases I’m not. Maybe they’re right and maybe they’re not; the values misalignment means our calls about what to do are different. Maybe we both put effort into resolving it and both come out feeling okay. That’s more energy invested than I would invest in considering and then rejecting an idea in a solo project. “Maybe I should do this,” I think, then “nah, not right now.” Energy investment over.

Dealing with disagreements is a normal part of group work. Disagreements are conflict, even if often only mild conflict, and they must be resolved. Resolution takes energy. Sometimes our colleagues are not great at negotiating disagreement; sometimes we’re the ones who aren’t great at it. Either way, in work contexts we must spend this time and energy, because if we do not resolve these conflicts, we as a team don’t commit fully to the decisions the team makes. (I gesture in the direction of The Five Dysfunctions of a Team.)

Nobody else’s taste: This one is interesting. I have some fairly strong preferences about naming things and how I want to write text that users read, and how I want to present data. I like a particular clean prose style (aside from the parentheticals). I often have to suppress that taste when working in groups. It is not helpful to fuss about variable names in pull request reviews, unless those names are very misleading. I’ll fuss about then if I’m pairing with you, then decline to die on that hill if you push back. This is good manners. But when I’m by myself, I can rename that variable just to see how the code reads, editing to my satisfaction. Or I can leave in that ridiculous joke that will make me laugh when I find the code again in a couple of years.

Autonomy is not fully at odds with the idea of working on teams. Aligned teams that are clear about their goals and the values they’re holding as they work toward their goals are not going to feel much tension here. The team might feel autonomy as a group and work together on making decisions. Or they might delegate well so that people can work on separate projects with the freedom to make decisions. But I think working in teams does requiring losing some autonomy. This is a tradeoff; it buys you the satisfaction of working on a larger project than you can do on your own.

Alignment

I noticed a couple of things there about changing requirements. I did change requirements for the tool midway through! A friend made a suggestion–how about json output? I thought about this and realized it would fit nicely into my goal of using toml-sourced data in shell scripts. Select complex data from a toml file, emit it as json, and pipe that into jq for further processing. I accepted the suggestion and added the feature. Doing that work made me think harder about what “emitting values in a form bash can consume immediately” meant, and the whole thing got a little better.

Aligning a team of one is a lot easier than aligning a team of five. Or a company of fifty.

Alignment is, however, critical for any group of people working on a software project together. (Probably any project, but software is the thing I’ve spent my life doing.) Leaders have to put in a lot of work here. Dicta from above don’t produce good results.

Mastery

My blurts above call out specifically that I learned to do some new things with this project.

I got to practice writing Rust instead of writing bash. Now, all the bash I’ve been writing for my day job has in fact made my bash a lot better. I have quoting bugs less often. But… that wasn’t what I wanted to get better at. It was the right choice for the problem in the moment.

Purpose

This is the scratching my own itch experience. I knew why I wanted it. I giggled my head off when I used the tool as part of its own release process. It was doing what it was supposed to do! I had succeeded! I had the tool I wanted!

That feeling of delight is something that’s kept me writing software despite all the nonsense in the industry itself, despite toxic work environments, despite bad project management, despite bad product design, despite sociopathic company founders, despite failures in the market. (That’s a litany of the worst of it; my career has mostly featured environments that were good, with the occasional awful standout.)

Of course it was fun!

I land on: of course it was fun! Of course revising it over the years since I wrote it was fun! I scratched my own itch. I have used it in every open-source project I’ve written since that moment. I made changes in the API and was happy about them. It’s useful to me. I don’t care if it’s useful to anybody else.

This is why I write software.

The first program I ever wrote was a D&D character generator, written in pen in a spiral bound notebook because I’d just read a BASIC manual but didn’t have a computer to run programs on. I was scratching my own itch about something I was having fun with at the time. When I finally got to type that program into an actual computer—a couple of years later, when my parents bought me an Apple ][+—watching it run was a delight. Years after that, when I was a somewhat older kid at a now-kinda-famous Silicon Valley startup, exercising code for my first feature there, I felt the same absurd joy. I sat there for half an hour, making the device do the thing I’d implemented over and over.

That was fun.

So why was writing this tool fun?

Because it was my work. Done for me. To my level of quality. Solving my problem. At my pace. And I got to giggle watching ti work.

Lesson

Are you not having fun? Okay. I get it. Work is a total drag. Maybe you should find another job? But if you can’t find your jouissance in your work-work, find it in your personal projects. Remind yourself why you write software. Go do something silly and useful only to you, and have fun. Find it on ths sly at work: do something that makes you happy in that work project. Revise the code to your satisfaction. Pause and look at the feature you just implemented and delight in how cool it is that you made something that didn’t exist before now “happen” in some virtual way.

Giggle at it.

1. bash is very good at orchestrating other command line tools and connecting output together in the famed unix pipelines. That’s what shell scripting languages are for! It’s a nightmare in many other ways. When’s the last time you messed up bash quoting? Exactly. It was, however, the right choice for the project in front of me; doing the work in any other tool would have been work work with a less-maintainable result. ↩

2. I’m not picking on my current day job here. I’m thinking of all of them across the years. ETA much later: lol. That day job was hilariously bad. ↩