A dev newsletter

Radical Systems

This month I spent some time thinking about radical systems, thanks to an article I randomly found. It seems like every time someone is talking about a malleable system they quote lisp or smalltalk. Honestly, the approachability of lisp seems terrible due to its syntax, but stopping to think, there’s nothing easier on C-like syntax either, it’s just what I’m more used to. When my girlfriend was learning Java, random syntax rules were as hard for her as some lisp syntax were for me. So maybe lisp is a language worth learning and maybe teaching it to beginners?

Anyway, that was not where I was going. The possibility of having systems that are easy to change (as in: the final user can easily customize it) was intriguing me. Would it be really helpful? I’m starting to think that it would. It’s kinda like the “right to repair”. No one is telling random people to go on and poke their car’s engine, but if they want to learn how it works and fix small issues, why not? This in my opinion would translate as something like: building their own Telegram’s bots, “fixing” websites to behave as their users prefer and small OS modifications.

Having systems that are approachable by people with few or almost no technical background would allow more hobbyists to have fun with their computers (just like the old days).

For this to happen, we “programmers” need to stop and think on our abstractions. One colleague once told me that “engineers” liked to over-complicate things because they really enjoyed the process of building new systems. Something that could literally just be an if, becomes a huge amount of classes and interfaces, just-in-case in the future, maybe we want to change it. Ironically, those (wrong) abstractions are mainly the thing that stops systems to change.

We also need to start thinking on “open systems”, on how users can modify the software you are writing without having to recompile code or even redeploy. How can they test their changes and save it without a whole “install a code editor, install libraries, install…” process. A bit like what emacs allows us to do.

We need to break the wall between coder and user. Merge the two roles. Let those who want to modify their software do it. [1]

Personal Updates

This was a busy month, between work and lockdown life management I didn’t have much time to spend on personal projects or studying. I started doing meditation again though. It’s a very effective way to calm the mind and be able to focus on what is in front of you.

As I write this the government is signalling they will extend the lockdown for another month without easing the restrictions. Given other things in my life, I’m thinking in also extending my holidays so I can rest during that time…


Digital Garden






How to handle a toxic manager

Nothing new here, but it’s always good to read that you are not responsible for “fixing” the situation with a toxic manager.

Decentralized forge

Our world is increasingly controled by software. From medical equipment to political repression to interpersonal relationships, software is everywhere, shaping our lives. As the luddites did centuries ago, we’re evaluating whether new technologies empower us or on the contrary reinforce existing systems of social control.

Necropolitics, Social Fascism and Algorithmic Colonialism

Is the old world really dying while the new one struggles to be born? Or does it merely mutate, gorging on technology and the intensification of social fear?

Who Will Control the Software That Powers the Internet?

But the benefits of such a shift will be immense. Instead of placing our trust in corporations, we can place our trust in community-owned and -operated software, transforming the internet’s governing principle from “don’t be evil” back to “can’t be evil”.

Final note

If you liked this, I would recommend you to use the RSS to receive notifications when I post new stuff.

[1] - Just want to make it clear that software should be simple to use, I’m not saying to force users to be technical. I’m also not saying that any abstraction is bad, just saying that sometimes we over-engineer stuff.