Putting mobile phone to DnD.

Putting on Bluetooth headsets with ANC, blasting some good shit music.

Violently cooking or desperately ordering food at the good restaurants.

While waiting, grinding some coffee beans, making fresh coffee or some nice tea with milk.

Laying on the sofa in a food induced coma, turning on any streaming service with the real bad shitty movies.

Hentai Kamen, The Machine Girl, ...

Anything thats either pure groteske bullshit or that doesn't require more than a braincell cause it appeals either to the violent or complete nonsense side of my brain.

Last but not least, a few cold beers.

ANC headset stays on, just switching from music to tv - shutting out all the outside noise.

i had an epiphany today, in a discussion with the software architect of our new project.

i'm having the epic job to design & implement a prototype for a C++ library in a new software project and collected some inspiration in our "old" software, where i'm maintaining the module that fulfills the same functionality (i thought). i've been maintaining this module for around a year now. i analyzed the different features and stuff to consider and created a partial model of the new library.

when i showed it to the architect today, he was like "oh my god, no no no, you don't need all this functionality, this shall not be part of the new library!"

this was the moment when i realized how deeply fucked up the code base of the old module is.

imagine it like this:
you want to automate the process of making yourself a good ol' cup of coffee.
the reasonable thing would be to have

- a smart water boiler where you set parameters water temperature and amount of water to be fetched from the water supply
- a smart coffee bean grinder where you can set type of beans, amount of beans and grinding fineness
- a component where water and ground coffee are joined to brew the coffee, where parameters like duration, pressure etc. are set
- a milk tank where amount of milk, desired temperature and duration / speed of foaming can be set
- a sugar dispenser where amount of applied sugar can be set
- optionally, additional modules with spices, syrup, ice cubes, whatever for your very personal coffee experience

on requesting a coffee, you would then configure and orchestrate all components to your wishes to make you a fine cup of coffee. you can also add routines like "makeCappucchino()", "makeEspresso()", or whatever.

our software is not like this.
it is like this:
- a smart water boiler consisting of submodules that know how to cook water for e.g. "cappucchino with sugar" or for "espresso without sugar, but with milk and ice cubes"
- 5 smart bean grinders that know how to grind beans for e.g. cappucchino, espresso, latte macchiato and for 73ml of water preheated to 82°C
- a very smart sugar dispenser that knows how to add sugar to 95, 98 and 100°C coffee and to coffee made of BOTH coffee arabica AND coffee robusta beans.

etc. etc., i think you're getting the gist.

when i realized this, it was like, right in front of my eyes, this terrible pattern emerged like a foul, corrupted caleidoscope of chaos, through the whole code base of this module.
i've already known how rotten from the core this code base is, but today i've actually identified a really bad pattern that i hadn't realized before. the whole architecture is so bloated that it is hard to have an overview of the whole thing. and it would require a LOT of refactoring to repair this pattern.
but i guess it would also be infinitely satisfying because i could probably reduce the code base for 30% or something...

but unfortunately, this is never going to happen, because screw refactoring.

it's a great feeling to start this new library from scratch, tho...

Isn’t it delightful when you come in to a large project to discover that they have a large underlying core that no one wants to touch but everyone relies on.

Quickly perusing the code you realize that the base was clearly created by someone who found their first tutorials for Java, but were previously a c developer.

It’s funny cause this code is of course from ~20 years ago and in different sections you can tell they were a C developer, a business admin, a Db admin, a junior conforming to pressures from others.

I recently looked at the deep rooted abuses of Java beans, and this entire internally created state management engine that serves no purpose but to create contrived complexity.

The use of propriety tools, that they paid lots for that perform incredibly simple tasks that have long since been solved by the open source community. Many of which are long defunct.

And the constant focus is on monkey patching the engine to solve small issues, which bloat the time to deal with issues. Since everything needs to be tested by their methodologies.

The inability to understand that the underlying structure is the issue and that tackling that, rather than just shifting the entire solution to new languages will suddenly solve the problems(or other underlying systems).

It’s just sad.

you know knowing people are always watching and that in the long run it doesn't amount to a hill of beans because they drive themselves crazy too is somewhat liberating to a point.