💾 Archived View for ebc.li › posts › scratching-my-own-itch.gmi captured on 2022-01-08 at 13:51:04. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
2020-11-24
Chatting with a few friends online, I made an offhand remark about how "I only program to solve problems nowadays". Thinking back about it, I realized this might be a double-edged sword. Why?
There are only a finite amount of problems I have that can be solved with code. And only a finite subset of those problems are ones that I am aware of, and "had enough" to pursue trying to solve them.
Currently, I don't have (or at least can't recall off the top of my head) any problems I can solve via programming, which means I don't need to write more code, which is why I am writing this instead.
It really is. If I know how to solve the problem, and am willing to start working on the solution, most of the time I won't stop until I get something that works well enough.
If I don't see the value of the "thing" myself, I generally don't bother with it.
If I'm fixing a bug / adding a new feature to an existing code base, I need to use the same language and tools as the original project. Even if I don't know how to deal with them, my only incentive is to solve that specific problem, so there is no reason to learn more than necessary to get in, do the change, and get out. (Which depending on the change is a really tiny piece of work)
Did I have to learn about Android application development to add a few new switches to an existing application? No, I grep'd my way across the settings pages to find something similar, and copy-pasted the code to add the switch. Then I grep'd my way around to find where the logic I needed to modify was, and changed it to check for the new setting I added.
Granted, I know how Java works (enough to make a few Minecraft mods), but the Android ecosystem is something else entirely, with completely different libraries and idioms, but the way I did this change wouldn't be different if I were contributing to a "regular" Java codebase.
The specific change I'm talking about, for the curious
If I'm making something new to fix a problem, there isn't any incentive to learn something new there either, because I will most likely already have the tools in hand to patch something together. It won't be as elegant as if I looked for better tools, but my goal isn't to make an elegant and flexible solution, it's to make a solution that works well enough for the specific problem I have.
If you see me releasing some code, there are two main reasons for it:
Notice how none of them is "Because I want it to be something people will use". I am not forbidding anyone from using my code, I just don't care enough about it to advertise it on various places, do development logs, whatever people do to draw attention to their stuff.
(This is also why most of my code is permissively licensed, because I don't care what you do with it. If I did, I'd choose something copyleft.)
In the past, almost every line of code I wrote was about learning how to. Learning how to write Java and make Minecraft server plug-ins, learning how to write C# and make games with Unity, same with GDScript and Godot later on, and same with basically everything I know today. Learning was my primary source of motivation, especially since I wasn't as comfortable with programming back then. I never _used_ the things I made. I made them just to learn how to make them.
Now that I know what I can do, what I can look up (and how), learning isn't as motivating as it used to be, because I don't have any use for the things I'd make while learning.
The most recent thing I learned would either be Ansible (to manage my server's configuration), or Grafana/Prometheus (for pretty dashboards).
I learned Ansible (and Docker before it) because they solved a problem (how to keep my server organized) in a way I couldn't with my existing tools, which is why I was able to learn enough to re-create my existing configuration learning and trying for 2-3 days straight.
My post "Server Migration" from a month ago, detailing this.
The "2-3 days straight" part is important, because compared to something more recent, where I tried to make a game because I got bored and wanted to (not exactly good motivation), and it only lasted enough to make a pretty screenshot, trying to add a totally useless detail for 4 hours (that eventually looked out of place so I deleted it), and get lost in an accident involving btrfs.
(I could've recovered it since I had plenty of time to backup. I could still read from the partition without any problems, I just didn't because it wasn't important.)
I am still learning how to use Grafana and Prometheus to make a dashboard about what's going on my server, but because it's not as important (to me, anyway) I frequently see myself getting bored with it, and I totally expect to not even open the page in a few weeks or so, while it still tries to update in the background.
Most of the time, my solutions are best made with completely new code, but for (both) times they required modifications to someone else's code, my changes have been accepted upstream, and it just _feels nice_ contributing back.
I definitely expect some projects to be harder to solve problems for, and even harder to get my solutions upstreamed, but thankfully I don't have any problems with those yet.
There is a single problem I can think of that I can solve reasonably easily, but most likely won't get accepted upstream... But that's for Firefox and the combination of the horribly long build times and me using the Nightly builds make that pretty hard to solve reasonably, especially considering it won't make it upstream.
There are also problems where I don't even know where to start troubleshooting, much less fix. One example being somewhere in the Linux audio stack. (I am currently working around that by hacking around in the PulseAudio config using values I got off the internet I don't understand)
🐺 · CC BY-SA 4.0 · me@ecmelberk.com