Someone else has your problem too 🔗
, filled in development, tech
I was perusing through the excellent Sacha Chua Emacs new's where she links to this article. @naiquevin@fosstodon.org talks about technical debt in Emacs configuration. I saw there a pattern I've seen a few times. A software user stumbles upon a problem, looks it up on the internet and copy/paste a random solution.
What I now know is that for most of the problems I'm hitting when using a tool, there's almost certainly someone out there with the same problem.
And most of the time, it's a lot of people.
So what I'm doing these days is to always look first at the project's issue tracker before searching the web for a random solution.
Sometimes there's the actual solution in there, sometimes there's a workaround, but there's almost always a reference to my problem.
It can also be a
WONTFIX but then with some explanations of why that way is not a good way.
But at least, you get the actual expected way of doing things and you can start to understand how the software is supposed to be used.
I don't know how many users of a piece of software there is but we're billions here on earth so there's always someone. I implemented a Home Assistant integration for a niche domotics system developed by a small local company that's out of business today. I thought I would be alone in needing this combination. Fast forward 3 years later, and IÂ stumble upon a comment on the Home Assistant forum's from a user looking for the same thing. Even at my small local scale, using niche systems, there were people with the same needs as me.
Now I'm also a developer so another thing I learned is that even if it's a missing feature or bug, if it's open source, use the code Luke. At first it can be a bit difficult to understand someone else's code but you get used to it. You get used to understand how software projects are made, and guess what? There's not that many ways. Of course there are multiple languages, architectures, build systems and combinations of those, but at the end of the day, it's always the same. Even if you don't know the language, take a stab at it. Look at the code. Nowadays, the various forges makes it so easy you don't even have to check out the code locally.
The project I'm working on these days involve using a
nRF53 embedded processor.
I like to use a
Blackmagic probe to do my debugging on embedded stuff.
It's open source, open hardware and, I think, much simpler to use than the proprietary JLink stuff.
Unfortunately, that processor was not supported.
So I hopped on their project's development page, and lo, there's an
open issue for it.
I never messed with the
jtag protocol and such low-level stuff, so my first reflex was to simply subscribe to the issue and propose my help but I didn't felt up to the task of implementing it myself.
And then I went to the code, looked how the other similar processor are implemented.
It's about 500 lines of
C which at first seemed a bit esoteric.
I just copy-pasted it, looked up the code for my processor and started to edit bits by bits.
And I finally got it working and learned a lot in the process.
There's almost always somebody who has or had your problem. There's almost always a sanctioned solution for it. Looking up the official documentation and bug tracker is the first thing to do before looking random stuff on the web. If you're a developer, look at the code. At the very least you'll learn something, you might even discover you're able to contribute a fix.