Comments as first class citizens

In the future it will be possible to link comments to sections of code, instead of just writing them a couple of lines above of it. Today, comments are second-class citizens that frequently get out of sync with the reality of the code. This is because working on code is done when the brain is in spotlight mode: we first look at this piece of code, which calls this function, which calls this method, etc. . The brain jumps from line to line, and misses the context around it. Documentation and comments are more holistic and should not be in-line with code, as they are something different entirely. Comments are "about" the code, not code itself.

In a merge request, you should see the changed piece of code with the comments that are applicable to it. These can be locally (like the comments that today are in the same file), but also an architecture document could refer to sections of code that implement the architecture. In the IDE, and certainly in a merge request, the developers…

What's so terrible about software?

[this is a work in progress]

One of the things you should understand before reading this series of blog posts, is why I think software is so terrible. I also think it's amazing, but that's another post.

1. Very little standardization Check out this little map from the Cloud Native Computing Foundation.

This map is what's wrong with the software landscape today. My thoughts are very well expressed by the late Joe Armstrong in this talk.

2. Software "evolved" to where we are now

3. Technology is disrupting our lives and our culture
You probably recognize these trends:

What's so great about software?

[this is a work in progress]

One of the things you should understand before reading this series of blog posts, is why I think software is so amazing. I also think it's terrible, but that's another post.

1. It is ridiculously cheap to get started with software. Carving wooden toys is probably cheaper because you only need wood and a knife, but for software, you need:
- the ability to read and think somewhat logically
- a second hand laptop, which you can buy for about $50 - $100
- power
- an internet connection (or a manual)

Mind you, it will take lots of time and effort
2. It is practically free to copy digital resources. All things that can be stored digitally can be copied for almost free. If you wanted to reach thousands of people before  3. It is ridiculously cheap to scale software. WhatsApp famously scaled to a billion (?) users with a team of about 50 people. Their servers each connected millions of users at the same time. With clever engineering, anything is possible. …

The Future of Programming

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…

UUIDs in MySQL follow up

Last week my blog post on UUIDs in MySQL stirred a discussion on Hacker News.

I wrote the post in about half an hour and stupidly enough, I did not think about UUID v1. I knew about v1 (from the Melissa virus case), v4 and v3 & v5 (which I once used to generate deterministic UUIDs). I just didn't link my case to UUID v1 because I've hard-wired UUID with UUIDv4 in my head.

Here are two observations from the discussion on HN.

First: over time, the first characters of UUIDv1 are still uniformly distributed.

The only reason I had the same prefix was because I filled in all values with one UPDATE query when I initialized the column. If on the other hand you use UUID() whenever you create a new row, the first characters will be distributed evenly.

Second: the different UUID versions should be more clearly distinguished in general. The Zen of Python has a line:
"Explicit is better than implicit." In following this, I think it's better not to expose any UUID() functio…

UUIDs in MySQL are really not random

Universally Unique Identifiers (UUIDs) are great. I love how you can tell the progress of a batch job just by looking at the current UUID. If it starts with 0..., the task is less than 1/16th done. If it starts with 7d.., we're almost halfway there. At ff... we are nearing the end. The fact that you can tell this rests on two principles: 1) you sort your jobs by their uuid and 2) UUIDs are random, as in, distributed uniformly.

However, last week, I noticed a strange thing: a clearly visible pattern in the uuid column of a database table. It should be impossible, but there it was. It looked like this:

> SELECT uuid FROM example ORDER BY id;

Highly Productive Teams and their Speed Bumps

In Civilisation, the fantastic BBC series from the 60's, Kenneth Clark is puzzled by the short burst of time in which cathedrals, spiritual movements and art styles are created. For a couple of decades (which sounds long by our standards), there seem to be surges in productivity, creativity and energy in almost the entire population. More was accomplished in these bursts than in the centuries of relative inactivity before or after.

In my experience, product development is very comparable. When looking back at some of the most important software projects in which I've played a part, there were bursts of just a couple of days where we were incredibly productive. We were energized, worked as one and were in a state of flow most of the time. The best part is this: although the experiences are very intense, they don't leave you very tired. Instead, afterwards you feel energized and you realize that you just did your best work! As a CTO, I would love my team to work like this!