The Future of Programming

First published on
Something has been brewing in my mind for years about which I have unpublished blog posts, loosely linked ideas and frustrations in my daily life as a software developer. I love software and I enjoy my job tremendously, but at the same time I believe that software creation is horribly inefficient and unnecessarily complex.

I've noticed that my thoughts are slowly becoming more consistent and I believe I can see where our industry is headed. Of course I can't predict how the future is going to play out, but A) I can dream about how software should be created and B) I can also see what it would take to get there. I'm going to write publicly about what I think could (or should) be The Future of Programming in a series of blog posts.

This year is a good time to start thinking about this. We're at an interesting stage where we have thousands of languages, eco-systems,

Brewing means taking materials, letting them ferment for some time and getting a very different product as a result. Only at the end you get to see if the brew is terrible, so-so, good or great. Well, here's my result and I hope you'll enjoy it.

In this series, there will be a couple of types of posts:
- Foundational: the central ideas that are the essence of everything I say or think about software
- Highlighs: pointing out companies, products or experiments that are doing something very smart or interesting
- Comments: my ideas on patterns, languages, habits



Full disclosure: I worked at the Low-Code vendor Mendix for about 7 years. I have no financial ties to the company anymore. Many of my ideas came from that company and I strongly believe in its mission, which is to let Business and IT create software together. However, I think it's more important that the mission succeeds than that the company succeeds.

Popular posts from this blog

AI programming tools should be added to the Joel Test

First published on
Here's a wake-up call to all CTOs: AI programming tools are getting freaking amazing and if you don't allow your teams to use them somehow, it will bite you in the ass in a couple of years. You will be slower and you will lose your best people. The infamous Joel Test is a list from the year 2000 of 12 things all great software companies do. Since then most companies have implemented Git and CI/CD, checking of three items, so we have some space left in the 2024 update ;) I believe "Do you allow your developers to use AI assisted development environments?" is a necessary addition. I get that you don't want your source code to end up on some OpenAI / Microsoft / Github server somewhere, sure, but find a way to use your own models or learn to live with it. Note that this is often not the same as "#9 - Do you use the best tools money can buy?" as blocking AI tools is about data security, not money. So why do I think developers need AI programming tools? I&#
Read more

The unreasonable effectiveness of i3, or: ten years of a boring desktop environment

First published on
Image
My wife uses Windows and over the years I've helped her move things to new systems. Win8, 10 and now 11. With every change the UI changes. Now I can't right click the bottom right corner anymore to open Task Manager. The UI feels "fresh" and up-to-date I guess, but does it really matter? My desktop has looked like this since 2008. I love the picture of the gearbox, it's a testament to the hidden precision engineering that goes on inside the built world all the time. I don't see much of the gearbox though, because most of the time my screens look like this: The environment around my background picture has changed a little more, but has been stable for the last 10 years. My experience is very different to my wife's constantly changing system. In 2009 I moved from Windows to Ubuntu, then to Debian using Gnome. Then finally to i3 in 2013 after a brief affair with XMonad in 2012. So by now in early 2024, I've had the same minimal UI for more than 10 years,
Read more

Idea time: RFID+E-Ink, electronic price tags without batteries

First published on
I got this idea years ago, somewhere in 2004 after I had heard both of RFID and E-Ink. The order is irrelevant ;) The idea is simple, we take: 1) RFID readers, which send radio waves to tags, which pick up some of the energy in the wave, do some computations and send a reply. The tags are brilliant: no batteries, no connected power source of any kind except for the antenna. 2) E-Ink displays, which need power only to change pixels. After the power is cut off, the pixels remain in their current state. The result: a small tag with a display. The display gets initialised and updated by an RFID-reader and after that retains its state indefinitely. Perfect for price tags on shelves in supermarkets, which need to be updated every now and then but are hellish to replace. I soon found out in 2004 that Epson had already done this:  http://gizmodo.com/026090/epsons-electronic-ink-%252B-rfid--21st-century-price-tags
Read more