I have a DIARY.md for logging progress at the gym. It's a long file, partly because I've been consistently going since late 2018. For that, I pat myself on the shoulder. It's also long, because I early on decided to build a web app for logging my sessions. While at it, I figured I'd take on the challenge to build a UI framework.
Choosing problem
From the get-go, I knew I'd end up with a ton of problems to solve. I was, and am fine with that. What I've done miserably wrong is to not turn back, and start solving one problem at the time. I could've solved data storage for my sessions. That would be an isolated problem. I could've opted for static HTML pages. That would suffice for complete user flows. Here I am, 1.5 years later, still committing training logs to a Markdown file. Point being, even with opportunities for self-improvement, problems shouldn’t be conflated into unnecessary complexity.
Project fatigue
Every software undertaking comes with constraints. Likely, these constraints exist to not over-consume scarce resources. Time being one of them, which is of particular importance in side-projects. I'm balancing side-project efforts with family time or sleep. If I overstep, I hurt my family and/or myself. Clear checkpoints are an energy source. Once I reach one, I can enjoy the result. Too vague goals opens up for ineffective drifting. Drifting is mentally taxing for me, sometimes enough to negatively affect the constraints I move within. When I'm out of bounds, I drain myself for unclear reasons. Here my interest starts to fade. I stagnate and I tire.
Stop-and-go
I'm driven by learning. In this, I have one side of me that is keen on experimenting to understand topics at depth. I also have an impatient side, which constantly has me looking for new input. Both of these tend to barge in when I myself is the sole stakeholder. When I let any of these traits take too much mental space, I often find myself doing something unplanned. Over time, I've tried to find patterns to look out for, to manage myself. The success rate of steering myself back on track is varied, but I'm getting better at it. Key for me is to stop starting new things.
Make it work, make it better
I tend to overthink things. Thinking alone doesn't result in any code. On the contrary, it opens up a Pandora's Box of possible solutions. Possibilities, by definition are things that may happen. Better are solutions in the hands of users. Interactions enable feedback. In this case, for my own benefit. In my training, I have a range of about 10 exercises. To list these, I do not need a unidirectional data flow architecture. Yet, it's that architectural problem space I keep finding myself in. In part the reason is interest, but the main offender is probably procrastination. At the point where a hack enables shipping, that is what I should choose. Code is meant to be run and used. Naive implementations pave the way for better things. The learning opportunity I’ve enabled for myself should be scoped as improvements, not a requirement.
Focus on outcome
I strive to be deliberate in the choices I make. If I’m not deliberate, I’m annoyed with myself. That’s why this side project has become something of a thorn in my side. At work I’m outcome focused. I have colleagues for whom pragmatism comes naturally, who are a great inspiration for me. They complement my weaker sides. We prioritize usefulness. I cannot even recall when I last could guilt my work I for taking me off balance. I’ve noticed this makes me feel better overall.
As usefulness is what makes me tick, the next time I feel an urge for reusability, it’s a hardcoding I’ll type.