Soulless code

Code isn’t just a tool—it’s a reflection of the coder’s mind, a part of their soul turned into logic. When I write code, it becomes mine. I take care of it, I understand it, I think about it. Even when I stop working, the code stays with me, like a thought I can’t let go. It feels alive, like something I’ve created, something that matters.

But when the code comes from an LLM or someone else, it’s different. I might use it, but I don’t really make it mine. I don’t take the time to fully understand it. I let others—or the machine—do the hard work. And often, it feels easier to just start over or forget it.

This kind of code feels distant, like it has no home. It’s less work for me, and that can feel good, like letting go of something heavy. But at the same time, it feels empty—like something is missing.

Maybe when we stop owning our code, we lose more than just control. Maybe we lose a piece of what makes coding human.

// Functionally correct. Morally bankrupt.  
// Just like the rest of us.

Writing

Today is international logic day, and I really want to read logicomix comic strip someone offered me for Christmas.

I realize as a logician that I can perfectly organize some stuff and as ADHD I feel completely stuck with some tasks yet to have my attention drained by completely unrelated events.

Often the fix or the way to disconnect from my mental paralysis is to write, walk, climb, talk, tell, draw or code.

It's a form of calm expression of self, an escape from news, emails, todo lists, code problems, mental load and daily stress for all the code and life bugs I can't unsee.

Like this blog where I write without caring if anyone is reading, and with no other purpose but the act of writing.

Flow

  • Cannot really stop coding while in a task. Coding is fun.
  • Cannot really stop improving after solving a task. I'm in the flow and each improvement unlocks another.
  • Cannot really stop bug fixing before solving it. Interruption is frustrating and I need to kill this problem.

Related

Continuous improvement is addictive because of the desire to reach perfection and repair the broken window (cfr Broken window theory).

Thanks to Vincent L. for the thoughts that inspired this blog.

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!

Contact me to learn how to master of your digital life.

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