A rare post in English!
My friend Jarkko brought up the way we IT guys fall into the trap of building everything ourselves instead of using already existing software. After all, we like to create stuff with our computers, and it’s awesome! The act of writing software is almost like conjuring some arcane magic: out of thin air, we are able to summon a tasklist app, a video game, a fitness tracker…
Another post I read today was by Var Zero, who formulated some ideas about mindfulness when coding. When we’re mindful of the intent of our code, we will reduce the cognitive debt of the software we create. When we think about the why, and not only the what, and use that insight in the way we code, the intent of the code becomes clearer. The piece of software will be easier to understand in the future (usually by our future selves) and this will ease maintenance costs.
A similar mindfulness can be used one layer up in the abstraction tree. What kind of software do we actually need to write and when? Are there situations where new software is not needed?
Like Jarkko says, we need to be focused. Is the goal we’re aiming for the new app or the thing we are trying to measure with the app? Are we actually trying to enjoy the activity, or do we feel the need to solve a problem we have and somebody has solved before?
In our field, there’s the notion of the ”not invented here” syndrome, especiallly in big corporations. Development teams will create systems from scratch instead of installing an existing piece of open source software (or buying a commercial product). This is similar, but a bit different to the NIH in our own lives. We have an itch that we need to scratch, in our case the itch is the need to write new software, and it’s easy to find ways to scratch it when there’s a concrete goal in front of our eyes.
There are of course situations where you should write a new fitness app or todo list. Like many others have said before me, there’s always something that can be made differently from existing applications and an infinite list of things to learn from experimenting. A diverse software ecosystem is a healthy thing! However, we need to be mindful: the goal is then primarily to write software. To actually use the application is relegated to a second place in that situation.
Similarly, Mark Brooker wrote a few years ago about ”The Four Hobbies”. When having a hobby, we need to understand the way we approach it: do we like doing the activity itself, experiencing the kit needed for the activity, or do we enjoy most talking about those things?
We can transform those quadrants in three dimensions by adding a data collection layer into the mix. This doesn’t make it anymore about the hobby or the kit, but about the data that we can pull from the activity. Data can be pulled from the hobby itself or the kit, or from the discussions (if Reddit still had an open API). If the hobby is running, or like me, orienteering, there’s loads of data that can be tracked by any fitness tracker: location, speed, distance, heartbeat…
Having gotten used to have a simple open-source smartwatch on my wrist and logging my activities, I’ve had trouble adjusting on those days where I’ve forgotten the watch at home or when I’m unable for whatever reason to get a GPS signal. Have I even been running if I don’t have data to enter into Livelox, Strava or Control after the act? How can I learn from my orienteering mistakes if I’m unable to pinpoint them on my map?
And every time l remind myself: doing the thing is not measured by the act of logging it. The point is not to get data and analysing every minute detail of the activity. When I run and chase those control points, I’m enjoying just being in the forest, breathing the fresh air, getting excercice, working my brain to navigate the map and finding the controls.
And every time I’m passing by those juicy blueberries or huge chanterelles like today I’m kicking myself for not having any time to pick them up or bag to bring them home with me…
