This will be a quick post about why you should not make your own identifiers if you can and also if you need to have an identifier that is easy to communicate with/about for clients base it on something that is still very much unique.

I am not talking about the cost of a coffee bar complete with barista, two old arcade machines, some bean bags, a table-tennistable, maybe one desk with a MacBook Pro on it to do some work as you attract the new edgy hispster software engineers that only write the latest trending obscure esoteric languages.

We all know the saying it is that you know what to do with it. Well it seems in development world the size is not the bigger the better but everything has to be as tiny as possible; from silicon chips to frameworks. Also they have no idea how to use it and what to do with it.

To add to previous post where I talk about using Unix timestamps for all things related to when I want to give the following addendum.

This post is in response to many claims of other posts stating that storing a UTC date is not enough in all situations. The most recent one that triggered me being this one. They all claim that you lose information about when something happened. I will refer to Unix timestamps when saying timestamps from now on.

Today I found myself in a discussion about why the state of the project was in the state it was. The voices of concern were that we were just working blindly without there being a refined user story and ticket to keep track of. No usage of Pythonic standards were followed. No linting, no tests and no clear structure in the code. In short all the things we as developers have said time and again we should not accept in a project yet we did it again anyway.

I recently had a small discussion on why it is a bad thing when we can not automate, or script, something. The only argument this person had was if we spend two weeks on automating something that takes 5 minutes that is a bad thing. There are several reasons to automate procedures and saving time is not the main thing.

So there are moments in your career where you face a choice: to go or to not go nuclear.

What does it mean to go nuclear though?

This is a brief post on a phenomenon that is easy to detect but hard to combat and even harder to eradicate. The following happens more often than not, sadly. So you are in a discussion with a colleague on what kind of tech to use and it actually got started by the other colleague saying we should use this technology. We shall call the technology Starlit Snowflakes. I hope you learned by now the first and only relevant question to ask that needs a satisfying answer is of course:

No I have not caved and suddenly love Kubernetes. Also this is probably the best topic so far that has given me so many things to write about so I hope you will allow me to milk it a little more.