A few days ago I started writing down a list of my work experience. This is something I had not done in a very long time.

There are a few reasons for which I kept postponing this exercise.

Non-linear work

As an independent consultant my work is not linear. I may be working on multiple engagements at once, whilst also preparing a training delivery or a conference talk. How to put this down on paper? I opted for the solution of categorizing work engagements by their nature.

The focus of consulting engagements is to provide expertise on a given topic. These engagements can be of short duration (a few days to a few week) or smaller amounts of work during a long duration (a few hours per day over a period of months, or a few days every couple of weeks over a period of years, etc.).

The purpose of contracting engagements is to integrate with a client team in order to work hands-on on the development of a project. These engagements are typically longer term (months to even years in some cases) and are continuous.

Then there’s other type of work such as training delivery, conference talk preparation and delivery, contribution to open-source projects, writing publications, my own research and development etc. which also takes place in between the other types of engagement.

Secret work

I have done some very interesting work that I’m not allowed to talk about in any depth at all. This is quite standard when working as a consultant or contractor, as many clients require you to sign a NDA (non-disclosure agreement).

And then there’s really secret work, for which you have to sign a NDA about the NDA. I cannot say more about this.

In any case, my list of work experience will forever be incomplete.

Invisible work

Staying up-to-date in the field of expertise requires significant work on its own (reading papers, testing new technologies, etc.) which is an effort that cannot be easily measured or conveyed in writing.

How to quantify this? Even if I were to maniacally track metrics such as the number of academic papers read and understood, the number of books read, the number of tweets or articles read or deep technical discussions held with others in the field, I think that these metrics still would not really convey the amount of work that goes into this activity.

The same goes for conference talks. Anyone having delivered a conference talk will know that it requires a fair amount of work to delivery a good talk. The better and natural and a conference talk looks, the more work went into it.

So these are a few reasons which make this list-of-work exercise hard. Perhaps not futile, but hard enough.

And then, there’s something else that happened, which I did not quite expect.

Remembering work

Do you remember now?

It turns out that remembering what I had worked on turned out to be the most difficult part of this exercise. I ended up using invoices in order to reconstruct the list of engagements I’ve had, however the invoice list at my disposal only back to 2017 since I switched invoicing systems back then, and the rest of the invoices are stashed away in paper form in folders at a storage facility. And invoices don’t typically detail what exactly I had worked on, just who I did it for. And payed engagements do not cover other type of work such as open-source work.

As it turns out, getting two kids really has not been very helpful for my memory. I don’t know if this is due to having the kids or the massive amount of sleep-deprivation that comes with it (or both), in any case I noticed that remembering things got a lot more difficult. Also if you have kids and they sleep through the night, just consider yourself lucky and don’t talk about it (seriously, don’t).

All in all, I am quite happy that I have not postponed this exercise for another ten years.

Knowing or not knowing

“The more you know, the more you realize you don’t know”

Aristotle

I wrote my first computer program at age 7 on a Sinclair ZX81 with 17kb of memory (I had the 16kb extension pack). Since then I have learned to use a few more languages other than BASIC. What I am noticing is that learning new languages gets increasingly easier. The concepts keep on repeating themselves.

When squinting, technologies start to look alike. A few years back, containers and container orchestration engines were new but also very familiar to anyone who has worked with application servers in the past. Ideas keep on repeating themselves, being re-implemented over and over again with more or less complexity included at each iteration. And yet after having spent a fair amount of time in the past 15 years learning about, analyzing, building and teaching about distributed systems I can’t shake the feeling that I, much like Jon Snow, know nothing.

Thankfully, it seems that I’m not alone in this. In his talk The Future of Programming, Bret Victor concludes:

“We don’t know what programming is. We don’t know what computing is. We don’t even know what a computer is. And once you truly understand that, and once you truly believe that, then you’re free, and you can think anything.”

So maybe it’s fine not to know anything after all.