Posts

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;
4f95de28-0fd1-48db-ad2e-34ecd169c483
4331cb9e-1d91-11e9-be2c-45923c63e8a2
4331cc4c-1d91-11e9-be2c-45923c63e8a2
4331ccec-1d91-11e9-be2c-45923c63e8a2
4331cd7e-1d91-11e9-be2c-45923c63e8a2
c7e2f124-f6ba-4434-843f-89958a7436ec
4331ce10-1d91-11e9-be2c-45923c63e8a2
4331ce9e-1d91-11e9-be2c-45923c63e8a2
4331cf28-1d91-11e9-be2c-45923c63e8a2
4331cfaf-1d…

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!

I…

Code Should be Readable

On the first day of my first job, at age 23, I learned the most important lesson of my life about programming: code should be readable. Four years of CS at university did not prepare me for this, but one day of work did (thanks Achiel!).

I had created something "clever" and was barked at by the Senior Engineer of the team that my solution was too complicated. For a second I thought he was suffering from low IQ, but he explained that:

He was not able to instantly understand my code. Lesson: It was apparently vital that other people in the team understood my code. In fact, it was not even mycode, the team owned it.The problem I was solving was simple and not worth spending much mental capacity on. Lesson: writing code is just a small part of what happens with it, code is much more frequently read, tested, debugged and refactored. All these activities take time and mental capacity.In 6 months, I would have forgotten the code and would look at it the same way he did now (that is:…

Necessary Evil

In one of the codebases I've worked with we had a module called "NecessaryEvil". All of the dirty hacks were put in there. This had three good outcomes:


We could track our technical debt by looking at the size of the module (and the references to it)Every time you saw a reference to a method in NecessaryEvil, your brain made a shortcut and instantly reminded you of how the thing you were looking at "worked" (that is: via a dirty hack, or in a non-intuitive way). This alone saved a lot of time in debugging.Over time the framework we used got more features. Every now and then we looked at stuff in "NecessaryEvil" and found things that could now be solved properly. This was highly motivational to the developers, because (a) it gave them a sense of ownership and (b) they saw the progress of the framework we used.

I highly recommend to make your "dirty hacks" explicit in your code base. Here is how you should do it:

Put all the dirty hacks in a dir…

Every Day Shampoo

Naming things is hard. Especially names for things that you want to market. From personal experience I can say that it's a lot easier to name a kid than to name a company or a product, but maybe that's just me.

The BEST product name I've ever come across is "Every Day Shampoo". I've seen it only in the Netherlands, where it's called "Iedere dag" but it probably exists in other countries too. Bottles of "Every Day Shampoo" are surrounded by exotic shampoos called "Ocean Breeze", "Rainforest Fresh" or ones with feature focused names such as "Anti-frizz" and "Colour Lock".

Instead, "Every Day Shampoo" simply tells you that you can use it every - single - day! Before this product came to market, people used to wonder if it's healthy to shampoo every day. Now they no longer need to think about that! Or at least they don't if only they buy this shampoo right now! Because maybe the oth…