Refinding the fun

I’m not entirely sure when it happened. If it was slow, or all at once. If there was a specific trigger, or if, in the way of many long relationships, the small annoyances added up to a big problem. Either way, it was time to face the horrible truth: I no longer loved, or even really enjoyed, programming.

The problem(s)

Don’t get me wrong, I still very much cared about programming, even as I became more and more reluctant to code. I wanted it to be the best it could be, wanted to encourage others to love it for all its wonders and frustrations, wanted to see it do all the amazing things I knew it could do. But for myself, I’d rather be in the shadows, helping the team on the product side. I grew quickly into helping with Product Management, helping bridge the communication gap between development and business. Important work, sure, but the problem remained.

I, a software developer, had little interest in developing software.

I suspect the real issue — an issue I doubt I’m the only person to have faced — is that I never actually recovered from a period of extreme burnout I had a few years ago. While I was able to switch jobs and get into companies with better cultural fits, I was still churning out code. Day after day. Sprint after sprint.

Burnout recovery is surprisingly difficult. While vacations can provide the rest needed to prevent burnout in the first place, I’ve found they don’t do much when the person is already burnt. Instead, it’s more likely that the vacation isn’t restful at all because there’s a layer of guilt and shame under it. Guilt that you’re leaving your team one person down. Shame that you can’t power through like you feel you should.

The opportunity

Thanks to an extraordinary bit of luck, two things happened back to back that gave me the real time I needed. First was that I had a baby. I do not recommend trying this as a burnout cure (infants aren’t known to be restful), but it did have the effect of ending my time with a client. I quite liked working with that team, so I doubt the engagement would have ended otherwise.

The second thing was that I didn’t have a client to come back to. We at Test Double refer to this as “Bench Time,” which I suspect is a baseball metaphor. I very suddenly had a couple of weeks of work with no expectations or specific demands on my time. I went out of my way to help out other people, wrote about how much I love pictures, and updated all the many things that needed updates. And then… I had time.

I’ve never been particularly good at sitting still, so I started to think about what problems I could maybe solve. While I was on parental leave, I had an idea for a period tracker that looked like an ice cream tracker. With no other directions, I decided to take the plunge and try out app development for the first time since college.

The process

I actually started to build the application in Kotlin, but I realized quickly that that was a mistake. While I have some Java experience, I’m more comfortable in JavaScript. I also didn’t want to be locked in to only Android, and wanted a simpler development environment for something I knew I wouldn’t have a ton of time to work on or support after this little two-week window.

I scrapped my first attempt after about a day and started fresh. I did a bit more research and went with React Native, since it let me develop for both mobile OSs simultaneously. I picked out Realm for a local database solution based on its small footprint, speed, and excellent documentation. I also used Expo based on the recommendation in the React Native docs, which made developing for two environments a cinch.

After that, it was pretty breezy for a bit! I’m not going to go into the initial setup or anything (all three of those projects have truly excellent guides). I didn’t follow all my normal practices — automated tests were few and far between, I didn’t pay any attention to branching or keeping features contained. I did exactly as much splitting things out as I needed for my own convenience, and I didn’t think about future state at all.

Coding simplified. Coding like a kid figuring out their first game mod. Coding with joy and discovery and as little toil as possible.

I focused on the fun. Built something for me that I thought the world could use. Played and experimented. Followed Ms. Frizzle’s eternally relevant advice: Took chances, made mistakes, and got messy.

That said, some issues did pop up.

WHYYYYYYYYY

The most frustrating problem I ran into only happened on older Android versions (SDK 30 and older). The first time I added a new item to my list, the application would crash. This only happened on the first add, and only on some versions of Android, which meant I had to wipe and reinstall the application on an older emulation every single time I wanted to test the issue (ugh).

Luckily, I’m the type of person who finds impossible, difficult to recreate, and generally weird bugs interesting. Like hummingbird moths!

See if you can spot the problem:

<View>
  <View>
    <Pressable onPress={onToggleStatus}>
      <MaterialIcons
        size={30}
        name="icecream"
        color={icecream.isBlackCherry ? colors.primaryDark : colors.black}
      />
    </Pressable>
    <View>
      <Text>{icecream.description}</Text>
    </View>
    <Pressable onPress={onDelete}>
      <Text>Delete</Text>
    </Pressable>
  </View>
  <View>
    <Text>
      {icecream.startDate.toDateString()} to {icecream.endDate.toDateString()}
    </Text>
  </View>
</View>

I honestly never figured out a root cause, but for some reason using toDateString() in the individual item View crashed the app with a completely useless error message. I ended up changing that line to just say how many days the event lasted, because I couldn’t figure out why it would happen or a way to fix it.

The more frustrating problem I ran into was caused by a lack of consistency in the React/React Native community.

I found out that Google has free high-quality machine translations available for a bunch of different languages, including French, Spanish, and Chinese. Since I made the application quite small, I decided to localize the application in the languages they let me use (as well as American – I took out the “u” in flavour just for y’all!). This was a bit time consuming but went pretty well! Until I formatted the dates, that is. All my date strings were off by a month, but the calendars were correct. I was flummoxed.

I didn’t realize the problem until I looked at the language files in the i18n repository. It turned out that there is a null value at the beginning of their month arrays so they could nicely use an enum for month names. Unfortunately, I had set my language JSONs to match what I needed for the react-native-calendar — no leading null.

I was able to fix this easily enough by adding the nulls i18n needed and stripping them back out when adding the locales to my calendar view, but I’m still annoyed they’re different at all.

Unstructured play

There has been more and more advocacy about increasing the amount of unstructured play children do. Unstructured play is how a lot of people learn — it’s how I learn. The past two weeks, I was able to play while programming in a way I haven’t had access to in years. This was the fastest I’ve ever ramped up in a new ecosystem, and I was enjoying every minute of it (yes, even the annoying bug parts).

This entire experience has led me to a new idea. We talk about burnout a lot as developers. I certainly don’t have a cure, or know what will help everyone, but my proposal to engineering team leaders is this: If at all possible, give your developers two weeks of unstructured play time.

Here’s how I would envision this type of initiative:

• For two weeks, the dev is not allowed to work on anything related to their regular job
• They can still be available for the rare meetings and emergencies, but nothing else
• This isn’t time off, and any paid time off they have can’t be affected by this
• They should share what they did at the end in some way (small demo, lightning talk, etcetera)

I would never have done this level of experimentation without the time from work. It would be impossible outside of my regular hours — I have kids and a violin and a finite amount of sitting at a desk I’m physically capable of. I also couldn’t do it in the 4 hours per week dedicated to growth — it’s too small a chunk to really dive in to something new.

Having this unexpected opportunity has been wonderful, and I’m very grateful the stars aligned to let me play.

For those who are curious, you can find what I built on the Google Play Store.