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.

Sans

Can you live a day at work and at home "sans"?

Sans smartphone?

We used to boot a computer and even a modem and be actually productive and enjoy life without checking for news, notifications, or email every 15 minutes.

Sans version control conflicture crap due to using Git-ware conflict-friendly patterns?

We used to just work together on code and discuss code, without focusing on the version control tooling.

Sans CI/CD tools to validate your work?

We used to validate our work before committing, in the old days.

Sans markdown?

We used to be able to read and write text without non-sense formatting, HTML was even a thing.

Sans proprietary note taking digital tools (Obsidian, Notion)?

We used to take notes on paper or in our own text editors in the past and format our notes in "raw" HTML.

Sans LLM for coding?

We used to reason about code and go read a programming language book or ask for help from colleagues in case of doubt.

Sans daily upgrades and ads and other modern web crap?

We used to have nice experience with computers.

In a world that used to be simple, what other "sans" would you can think of?

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.