Burnout Chronicles III: Return to the Code

"These things are fun and fun is good" - Dr. Seuss

I think I completely lost my love for code about two years ago. This was actually the culmination of 3-4 years’ manager burnout which I had tried, and failed, to resolve by switching to an IC role at an exciting new startup. It should have been exactly what I needed - new problem space that I was passionate about, a break from management - but it wasn’t and I started my career pause one month after returning from maternity leave round #2. More on that here.

About a year (a year!) into my pause I finally noticed the burnout lifting. I started this substack around then and, a little while later, a small career coaching business. My previous love for code, however, was nowhere to be seen. This was really upsetting. I figured it was gone for good.

I was wrong. That part of my mind just needed a little longer to come back online than the rest of me did. In fact the reason so much time has passed between this post and my last one is that I’ve been enjoying coding so very much. I think there’s a lot out there about managers who miss writing code but struggle to get back into it. I don’t see much out there, though, about wanting to want to code. So today I take a break from the usual management/leadership stuff to talk about the road back to fun.

Why did it take so long?

I actually did try picking up a few open source tickets at the beginning of my career pause. I figured it would be fun again now that I wasn’t coding for work. The spark was gone, though. It just felt like an unnecessary chore and was not the way I wanted to spend the precious downtime I got from my baby’s naps. Back then I chalked all that up to the burnout but I think it was also because 1) I was trying to do it on my husband’s ancient MacBook Air which wasn’t really up to the task and 2) none of those tickets came with a compelling story to motivate me.

The CEO of Boom, Blake Scholl, pointed to lack of motivation as the cause of burnout for his team in a recent post. Scholl describes how he gave his employees a company vacation for a few weeks to rest and reconnect but that they were burnt out upon their return, hence the realization that they needed something new to motivate them. Giving them near term goal posts seems to have done the trick. He concludes that all burnout is due to lack of motivation and that the answer isn’t rest, it’s finding new motivation.

I don’t think I agree with this. My own burnout came from a mix of things and had been going on long enough to pound my brain to pulp. It took an embarrassing amount of time (rest) before I was ready to take an interest and feel motivated by anything more intellectually stimulating than Circle Time at our local library.

Going back to Scholl’s story, I suspect that meeting those two needs first (rest + family) allowed the lack of motivation to come to the surface. It’s also possible that a taste of having those needs met allowed the team to realize how tired they were and reminded them of what they were sacrificing. They needed a strong reason to go back to work full steam. Maybe Boom will eventually get to a point where a more sustainable pace is possible; it’s great when employees have inspiring goal posts as well as downtime and family connection.

Rant aside, once I had rebooted it was hard for me to get back into coding without the strong motivation provided by an excellent story.

This is the first one that brought me out of my non-coding haze:

Drug target discovery for prostate cancer

Austin Morrissey documented his first experience vibe coding a drug target discovery data pipeline for prostate cancer in “Cancer, Caffeine, And Claude: Vibecoding for New Therapeutic Targets”. This was back in March and it had been over a year since those two sad little open source tickets I’d attempted at the beginning of my career pause.

This project writeup was compelling for so many good reasons. He open-sourced the resulting repository and I submitted a very small and, honestly, not all that valuable PR. It felt great.

He has since rolled out a few more projects including this one. They are an example of some of the incredible things a person with deep subject matter expertise in their field of choice can now achieve in our new world.

A podcast episode and a bit of hand wringing over deep fakes

Some time after that Keith Cowing, an old friend, asked me if I’d like to record an episode about leadership with him on his podcast. It was an exciting opportunity but the acceleration of deepfakes and their ease of creation are scary to me; I wasn’t comfortable putting my voice out there on the internet. I really wanted to do the podcast, though, so I did some searching and found a paper entitled “AntiFake: Using Adversarial Audio to Prevent Unauthorized Speech Synthesis”.

The authors created a tool, AntiFake, that takes in a raw voice recording and then outputs a copy of that file with strategically placed background noise. When deepfake tools then attempt to generate novel audio based off that file the wrong voice comes out. The code is publicly available on Github.

I forked the repository and wrote some of the messiest python of my career to get their Ubuntu + GPU targeted code to run on my new computer, a MacBook Pro. This was a big improvement over the MacBook Air but it’s another hand-me-down, this time from 2019. That means no M3 chip, just traditional CPUs.

It was extremely frustrating and then just as satisfying to get it to work. Unfortunately the resulting code has just sat there and moldered since then. The background noise on the outputted audio is distracting and there’s no real-time functionality so I ended up using Voicemod for the podcast instead¹. It was still tremendously satisfying to hack around, though, and the podcast was a lot of fun.

I was finally back in the groove. It was time to pick out my first greenfield project.

Some closure with ERCOT

It took a while to find the next thing. I was starting to feel like the fun I’d had coding had been a fluke and I was returning to some sad, non coding baseline when this post by Dave Friedman popped up in my Substack feed. It explores the impact that AI data centers will have on ERCOT, Texas’ electric grid operator.

ERCOT! Right, that thing! I had had one heck of a time querying ERCOT’s ancient SOAP API for price data at my last job. Python had very limited support for SOAP and I don’t think I’d interacted with a WSDL file since college. I had found a memo at some point indicating that ERCOT was working on a REST API rollout but the timeline was far out. We got it all working with SOAP and it was an absolute pain.

Friedman’s post reminded me of all this and so I went back to see if they’d ever updated the API. Lo and behold, it’s all now publicly available via REST! They even have an active developer forum! I spun up the tiniest toy client ever just to celebrate and to give myself some closure here.

The ERCOT toy client quickly lost its shine, though. This is due, in part, to a lack of inspiration. I had access to data but I didn’t know what to do with it once I had it.

If you are an ERCOT wonk and have a project in mind, let me know.

The Tempest Weather Station

It was time to find the next thing. API clients are like potato chips - you don’t stop at one - and so I pawed around for another. At first I considered the smart thermostat in our house. There’s a REST API for that, too, but I would have had to sign a contract stating that I was a business leveraging the API for commercial purposes. This isn’t true so that was out.

I then remembered that we had bought a toy a couple years ago: our very own weather station:

This adorable little thing is powered by solar panels and sits on top of our fence post while it collects all kinds of data about our backyard’s local weather. There is then a second device, a hub, which connects to the station via bluetooth and then pushes data to a web server over our wifi every minute. That data is available on the Tempest mobile app as well as their web portal.

I wondered if Tempest exposed an API and they do! It’s documented with up-to-date onboarding steps and they, too, have a small but active developer forum.

So I built another little toy client and successfully queried the weather station only to realize the data I got back was 2 years old. The poor thing was long dead.

Our hub gazes mournfully at its lost friend.

The people who work at Tempest support are very nice and they sent us a replacement. I followed the instructions to get it set up and I was in business. I started out with their REST API but they expose a web socket, too. We got hit by a sizable storm last weekend and my little program logged dozens of lightning strikes:

According to the documentation, the array associated with “evt” represents timestamp, distance (km), and “energy”. “Energy” has no units and no one on the forum knows what that 1 at the end means. I *think* negative values for energy represent negative strikes but the documentation is quiet on this point.

I’m thinking of playing with Swift next to build a tiny iOS app but have discovered what many already know which is that programming with Xcode is painful. Please reach out or comment if you know a better way or if you have any favorite Xcode configuration tips.

Conclusion

In writing this post I am reminded of the advice a past CTO gave us every Hackathon eve: if you learned something then you’ve already won.

I haven’t created or done anything novel. Previously this would have served as an unacknowledged mental blocker; I couldn’t get myself to start a side project years ago because I couldn’t think of anything to do that hadn’t been done before. I couldn’t justify the lift. Removing that obstacle has been great. It’s also worth pointing out that coding has been my hobby this time around as opposed to my job so it’s all play; it’s basically been a hackathon for an hour or two every day while both kids are in school or in the quiet moments between their bedtimes and mine.

If you find yourself in the same boat, wanting to want to code again, then I hope some of the stuff in this post is relevant. Use decent hardware, find a story that piques your interest, and don’t block yourself with the assumption that you have to create something new or valuable to justify the time spent; it’s enough to learn and play or, as Dr. Seuss reminds my preschooler most nights: “these things are fun, and fun is good.”²

Read next

If you found this post interesting then please check out:

1. I would like to take this opportunity to point out what an incredibly kind and understanding person Keith is.

2. One Fish, Two Fish, Red Fish, Blue Fish