The art of crafting and loving your own tools

I have learned one good lesson from tasting someone's else food, it's never salty enough and I always miss the good drink pairing or something else is missing. And I'll feel bad for making any critique or special request.

I have a similar feeling about apps, tools and platforms I don't maintain. Sure i can help fixing them with requests that will likely be forgotten in their backlog. Or I can pick an alternative product which will unfortunately lack features from the former or will have their own ux issues, bugs, weirdness...

In the end I'll flavor ones that focus on simplicity and which provide good documentation and support for data import/export and customizations through their API or through plugins and scripting.

Miniflux, Shaarli, Obsidian, Dropbox, Cloudron....are those kinds of apps and platforms I use that do a thing well yet I have customized to my taste, e.g of such personalizations:

  • Dropbox is automatically organized based on custom rules, all orchestrated through cron jobs.
  • Bookmarks in Shaarli are tagged automatically thanks to a plugin I've made available in my shaarli_plugins Git repository.
  • My apps hosted in Cloudron are restarted automatically on schedule if they stop responding, thanks to some cron jobs and Cloudron's API.
  • Music I download on-the-go from my mobile phone through Seeker (Soulseek client) is synced automatically to my storage and visible in my Navidrome and Subsonic clients; so I do not need Spotify. It is also orchestrated via cron jobs, using rsync and syncthing.
  • Notes I take on my Obsidian at work and at home are synced automatically thanks to Syncthing an Git on my personal Gitea server.
  • Miniflux is the tool I've extended the most as I've blogged in Reading RSS in peace with a few Miniflux Hacks, e.g:
    • organize the feed categories in Miniflux.
    • group items by author.
    • show stats about each feed.
    • highlight links I've already bookmarked in Shaarli.
    • add one-click buttons Add to Shaarli / Follow in Miniflux next to each link mentioned in those articles depending if it's some RSS feed or a random link I might want to bookmark in Shaarli.
    • Some of those recipes are available in my repo.
  • Email attachments related to our financial activity are archived in our Dropbox and renamed automatically based on their content, using OCR. The whole thing simplifies communication with our accountant and their software.
  • My monthly invoices are generated automatically from InvoiceNinja and I'm looking at a solution using only Python.
  • I'm also making my own RSS feeds from sources that lack one like https://indieblog.page/all and https://www.journee-mondiale.com/les-journees-mondiales.htm, I've shared the source code for indieblog and for journee-mondiale, both are orchestrated via cron jobs.
  • I keep building more, I'm working on my own tools to supplement or replace InvoiceNinja, Shaarli, Wallabag, Obsidian and Miniflux. The fewer apps I rely on, the more focused I become.

Relying on my own recipes, scheduling things though cron jobs and building my own platform saves me costs, improve my computer experience and make me more efficient about problem solving.

It also likely make me a bit lazier and annoying.

You can be more efficient too, and I can help if you like!

💌 The best way to get in touch is via my email morgan at zoemp dot be. I speak (a lot) French, English and a bit of Dutch.

Typing fast is not so important

In response to https://www.rugu.dev/en/blog/on-typing-fast.

HN comments.

What to say on this ? I like typing and feeling productive. But the two are unrelated.

TLDR; We need to slow down a bit, as programmers, and as technologists.

I believe there are virtues to typing fast, for the impatient programmer, for the prolific coder, for the over busy person, and because free time is never given to anyone. I tend to be quite impatient at times, because I see fast builds and fast code as solved problems, at least with boring tech.

I nurture other virtues like removing code, remove dependencies, pipeline steps, YAML soup, hundred lines setup instructions and docs, frameworks and libraries. You can shift to simple scripts, binaries and code, that is efficient and -- most important -- that your understand, can maintain and validate and which can fit in your screen without needing to scroll through long files nor switching between tabs and editors to understand it.

There are benefits to pushing releases faster, but it has nothing to do with typing more code faster. Do not push buggy code at first. Understand the code you write and make it boring, readable, concise, because you understand it an you know enough to improve it and vanish some complicated concepts.

Because you focus on the user experience, on quality, on the business, not on the code, you will be able to explain the business that it's more important to do the right thing than having to rewrite the things three times later and debug it four times. You know how to defend your case because and you know the impact of a badly designed solution built too fast. You already prefer quality code, and you know enough about the business to explain how risky it is to push bugs faster and have to spend all your valuable time debugging your code or peers code.

Do I enjoy more YAML and code on a daily basis ? Certainly not. Duplicated code and YAML makes me puke. I'm happy if a colleague thrashes some code I wrote, because in the end we do not need to keep it all. An a good CI pipeline should likely be 2 lines long, not thousands lines long (hello GitLab/GitHub and other YAML soup lobbies). More code is more fragile and harder to validate and rework. Good code takes lot of rework, or maybe more thoughtful upfront design.

Also, do you really want to type the whole day ? Is it your only way to solve problems ? Some things are not so urgent nor important.

  • A single line of code added or removed can make a whole day better. A simple "NO" can avoid tons of bugs.
  • Reading code, learning about boring and legacy tech, will teach you valuable lessons.
  • Discussing decisions and designs with peers, and even in the middle of other things, will lead you to connect more dots together, and lead to opportunities and more collaborative ways to solve the problems.
  • Reinventing the wheel, simplifying solutions, solving problems, thinking, writing, do not require typing faster.
  • Programming do not require typing faster.
  • Authoring good books and novels do not require typing fast.
  • The best work is not always the result of fast work. A good movie/tv show script, a good (comic) book, a good music release, requires thoughtful work.
  • Maybe feeling emotionally pressured to react/rant on internet or social media leads you to type faster.
  • Maybe a bad manager wants you to answer faster to what appears to be urgent/important. But maybe you have to reconsider the urgency.
  • Maybe we do not need to reach 120% productivity, nor 600%, nor 100%. We are not machines.

We do not need more code/bugs in the world, nor more pressure to deliver more in fewer time.

We need more quality and care. We need to take the time to think and discuss code. And sometimes consider doing nothing and maybe waiting for some technology to mature rather than succumbing the hype... hello LLMs and their carbon footprint that ruin long efforts, while a few good IFs could have done the work.

I tend to see myself as a slow programmer, I mean thoughtful one. For a decade at least. And I believe this is rarely valued. Yet an important virtue for me is to take the time.

And reconsider our ways for solving problems rather than trying to convince the world to speed up a little more. We already suffer with enough crap to fix, alerts, dark patterns, slow code, bugs, security incidents, broken tests, broken pipelines, fix(ci) commits everywhere, git conflicts, ignored specs, overlooked docs...

Do we want more code delivered by heroes (or glorified code addicts) through harder and faster work ? Do we want your value determined by your typing speed or the count of hours spent at work ?

Do I really want to pressure peers and myself even more by typing always faster and more, energized with caffeine (which I love too much)? No thanks.

I'm not a luddite, nor for status quo, yet... less is a viable option.

  • Maybe the problem is not so urgent.
  • Maybe this feature will make everyone even more busy with the bugs and side effects and consultancy.
  • Maybe this extra feature or dependency will introduce too much risks and maintenance.
  • Maybe teaching you how to reach the same goal with this alternative way is as efficient.
  • Maybe this work can be avoided with a phone call, a chit-chat or a boring old idea or tool.
  • Maybe you do not need to be a code hero, especially as code is expensive.
  • Maybe you can solve the problem without a computer.
  • Maybe you need something simpler.
  • Maybe your problem was already solved many times before. Do not repeat the cycle or history.
  • Maybe we deserve a more disconnected world, long live local and offline first.
  • Maybe I want a world where I'm not urged to switch apps and copy paste the MFA within a 30 seconds time frame.
  • Maybe I can cultivate patience by watching someone type slowly, and it's fine.

Or if you insist, let's do it the right way, and think of a minimalist, solid and boring way to do it.

Related: Silicon Valley S01E05 - Typing speed

Markdown: a text adventure

Seriously I wonder what is wrong with us, computer scientists and computer hobbyists. I thought I loved markdown, that I needed to keep telling the world about it, but what renders in Gitea is not rendering the same in GitHub, nor in Obsidian. I'm likely idiot, let's find out.

The guide at https://www.markdownguide.org/book/ already starts by confusing its readers, looking for simplicity, with prompting the user to pick between normal or extended syntax. The top menu also mentions hacks and tools and books. Woot ? Aren't we talking about a simple text format and about making things simpler ?

This can't be so complicated, at least I thought. Then I visited https://en.wikipedia.org/wiki/Markdown#Implementations and fallen of my chair -- note the >dramatic< tone here, but I'm only sitting in my sofa and avoiding sleep, I'm all fine.

I hope we are solving this problem. Likely, the smart people figured it out... < o> < o> https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=variant+markdown&sort=byDate&type=comment. Woot.

Damn, even on Markdown supposed to provide a simple and better source format and publishing tool than HTML, we experts can't agree. Myriad of tools and implementations each extended by a few more artisanal tools here and there, millions of hours wasted ?

They are plenty static site generators and people crafting them and enriching markdown with details to hopefully generate, well, mostly valid HTML ? Or not ? Last time I checked, only an handful of those would take care of this goal.

We could chose to go back to working with text or HTML without tools in our way. This blog post for instance is almost just text and links, nothing much I require from markdown. This likely makes this portable. No transpiling needed, no tools.

It's NOT SO HARD and still readable. This blog post also has links that do not require remembering keyboard shortcuts on Mac for [Title](...) nor combining any special key.

Markdown is like sharing a recipe, but everyone reinvents a different complicated meal.

Simple is however better.

Instagram

As a reminder of how shitty those social media can be, I'm feeling obligated to write this short rant.

This morning, using my secondary empty and idle Instagram account to do some research, I end up discovering a nice content through the home page feed, and I'm trying to share it with my partner.

For some reason, the share does not reach my partner, so I want to find the content again and I navigate backward and this triggers a home feed refresh. My home feed is now completely unrecognizable and this causes immense frustration.

Last week, I was about to revive my main Instagram account, and this kind of bad UX reminds me that the benefits are not worth the immense frustration and non-sense of navigating an endless loop of evaporating content. No, Meta, you won't fool me again.

Fear of missing out ? not worth it.

Magic is problematic

I deal with computers, hence I want things to work the most boring and reliable way possible, with automation, procedures, scripts, not through magic.

Hence, while I love tools such as Atuin, I've a problem with their slogan "Making your shell magical" and generally speaking with any product using such selling argument, especially AI LLM-based products.

For this reason, I'm usually against any kind of black box and one-for-everything tools and platforms that want to ease our lives by hiding the complexities. I think that the only result we get out of those abstractions is complexity, pain, and a culture of incompetence and dependability. I mean, if you want to deal with technology, at least you should understand it.

In the end, it's not all magic [1] [2], but it can feel magic for sure once we lack understanding. Magic feels shiny and appealing after all, its antonyms say it all.

Let encourage everyday users to look inside the box and understand what is happening, even if not everyone is going to switch to Linux, even if debugging is not easy.

At work, there exist an onboarding procedure targeted towards new developers in the team, and this procedure relies on scripts which were left untouched for way too long. The bad things : the procedure is broken but nobody dares to fix it, instead the old timers in the team share dirty hacks and workarounds with the newcomers.

Once you face such problem, the only solution is to address the root causes, not the symptoms. I choose to take a look at the procedure, run it again and again after each attempted improvement, cut it piece by piece, shred or rewrite what seems unreliable and suspicious.

Magic exists, but I’ve never seen any in software. Problems are logical. Nothing is impossible. You can solve this problem.1

As a software engineer, please don't fix symptoms. Don't get too used to deal with crap and unsolved problems. Don't be lazy, don't accept the status quo, make the hard work to understand and solve the problems. Set your focus on understanding things deeper. Enhance your and everyone's knowledge. Be a firefighter against ignorance, and help educate your peers to be better at understanding why things work or doesn't.

Thank you.

HN Comments.

  1. https://catskull.net/thoughts-on-debugging.html ↩︎