An Ode to Unfinished Projects: Learning to Love “Bad Code”
Focus Timer is an amazing timer that helps you focus when it’s toughest. Unlike most focus timers, it learns how you’re doing and adjusts based on it. If you’ve had a bad day it might ask you to focus for five minutes increments, then gently encourage you to focus more over time. At least, that was the plan. Instead, after working on it for a bit, I have one big unfinished mess that I somehow still use every day, and I've learned to love it.
I’ve been using timers to help focus for many years. Some call it the Pomodoro Technique, but that’s trademarked. The standard is to set a timer for 20 minutes and work. Then set a timer for 10 minutes and take a break. The problem for me is I sometimes couldn’t focus for 20 minutes because it was Monday or something.
I was always fiddling with the time. I thought I’d build a timer app that would have adjusting the time as a core feature. After each focus interval it would ask how you felt and then adjust the time based on it. If you were having trouble focusing it would lower the time. If you seemed to be doing OK it would slowly raise the time. It would also warn you if you focused too much because I have ADHD and hyperfocus is a real danger. I opened my fave design tool, Assembly, and designed a flow and user interface. It had circus animals because, um, Assembly has a cool circus sticker pack. I was so excited!
It went well at first. I showcased it at Glitch Appy Hour, a weekly Glitch event where we talk about cool apps we’re building. Then I hit a major slog, I made a key mistake which was I made the code total garbage. I thought more about what circus animals would be in the timer than how to organize my code. I’d wanted to experiment with writing plain "Vanilla" Javascript rather than a framework. I hit upon a key reason people use frameworks: they encourage you to organize code and use design patterns.
Faced with the prospect of rewriting from scratch or fixing a bug in unreadable code, I suddenly realized I had other interests. Like researching the best cat litter. Or playing “Fire Emblem: Three Houses” five times. I was afraid of opening the code because it would force me to think about what I’d done.
In tech, there is a stigma against “bad code.” It goes way back to popular 2000s blogs like “Coding Horror.” The idea is that some people write bad code, and by and large they should just give up. Job interviews are very focused on finding out if the candidate writes the dreaded “bad code.”
The problem is if you code, bad code is inevitable. But the stigma makes it hard to admit or even ask about. I remember asking about something on Stack Overflow once and getting “why would you even do that” as an answer. One time I wrote an article some dude didn't like and he went through my code to prove I wasn't even a "real coder."
I used to feel bad about all my unfinished code projects and “bad code” on Glitch and Github, to the point where I've thought about hiding or deleting it. Over the past year, I’ve realized that living with and learning from unfinished code is a valuable experience. Stigma against “bad code” is bad for coding culture, and I should extend that compassion to myself. April Wensel of Compassionate Coding says "Burnout, anxiety, and depression are real problems facing our industry, and negative self-talk contributes to these problems."
What I’d built still worked even with bugs galore. It was better than what I’d been using before. About a year later, I’m still using it every day. When I’m learning new things at work I think how they might apply to improving it. Maybe I’ll never finish it, but I learned a valuable lesson.
I’m still pretty ashamed to post this app. Just warning you it’s not really clear how to use it and it breaks nearly every day. The code will probably give you a headache, but maybe you can learn from it too, and reframe unfinished projects or less than optimal code as “bad” and think of them as just part of the process.