Start Date: April 7
End Date: April 8
Blog Post
This will be my first failure of the month, and as much as I’d like to sweep it under the rug, that’s not what this month is for. The goal this time was to create a web application that would guide users through a breathing technique known as Square Breathing, which is said to have a calming and focusing effect. It would have had an interactive component aimed particularly at touch screens, in which the user would trace their finger (or cursor) along a square path within a moving visual indicator, ensuring their breathing remained in sync with the exercise.
Despite being forced to admit defeat (at least for now), I don’t think a project of this scope is beyond me. Rather, there were two main problems, each of which exacerbated the other.
The first problem is that Rule #3 of this month - don’t use a build tool more than once - is exceptionally cruel given my current skill level. It didn’t seem like a big deal last month - I figured it would mostly just prevent me from reusing the same boilerplate code for each project. But a development environment is a piece of software responsible for continuously solving about a dozen logistics problems all at once, and it’s easy to forget that when you’re using something as abstracted as Parcel.js.
My plan was to use Gulp to create a basic pipeline for processing source files into a deployable package, as well as enabling a few “basic” development features like live-reloading. I’ve used Gulp in the past, so I wasn’t expecting to run into much trouble with it. But I was probably on my seventh or eighth tab of documentation when I realized I didn’t know Gulp (or any similar system) well enough to sprint through ten configurations in one month.
The second problem might not have been so bad if I hadn’t already been so unsettled by the first. The spec called for a number of animations and effects on SVG elements, and also needed to track the user’s actions and settings via event listeners and a global state. That is, the application wasn’t so complex that I thought I needed a whole framework, but still complex enough that squishing everything into a single .js file would have been uncomfortable. Which is exactly what I was reduced to trying once I gave up on creating an environment.
Ultimately, this project was a failure in judgment on my part, but I think it was a useful failure. Rule #3 will become Suggestion #3 from now on. Being unable to put together a development environment on my own is a skill gap I can’t ignore, but that's a subject for next month. Right now I want to err on the side of completing projects, so I will make sure to use and appreciate the existing infrastructure allowing me to do that.
Remarks
You'll notice from the start and end dates of this project that I only spent one day trying to make this project work before giving up on it. This gave me an additional two days of "wiggle room" to complete the other projects. I didn't end up needing that extra time, but knowing it was there definitely helped keep me sane over the next few weeks, when everything started to go off the rails.
The blog post I wrote above is still a little hard to read, mostly because I still remember the frustration I felt writing it. But to my credit, this does seem to be the point where I realize my approach to tooling is flawed. I wasn't in a spot to carry that realization through into something useful at the time, but failing here allowed me to make some important realizations a little later on.