Ticket: Add <feature> to <thing>. It works in <other things> so just copy it over. Easy.

Thing: tangled, over-complicated mess.
Feature: tangled and broken, and winds much too deep to refactor. Gets an almost-right answer by doing lots of things that shouldn't work but somehow manage to.

I write a quick patch that avoids the decent into madness and duplicates the broken behavior in a simple way for consistency and ease of fixing later. I inform my boss of my findings and push the code.

He gets angry and mildly chews me out for it. During the code review, he calls my patch naive, and says the original feature is obviously not broken or convoluted. During the course of proving me wrong, he has trouble following it, and eventually finds out that it really is broken -- and refuses to admit i was right about any of it. I'm still in trouble for taking too long, doing it naively, and not doing it correctly.

He schedules a meeting with product to see if we should do it correctly. He tells product to say no. Product says no. He then tells me to duplicate the broken behavior. ... which I already did.

At this point I'm in trouble for:
1) Taking too long copying a simple feature over.
2) Showing said feature is not simple, but convoluted and broken.
3) Reimplementing the broken feature in a simpler way.
4) Not making my new implementation correct despite it not working anywhere else, and despite how that would be inconsistent.

Did everything right, still in the wrong.

Also, they decided I'm not allowed to fix the original, that it should stay broken, and that I should make sure it's broken here, too.

You just have to admire the sound reasoning and mutual respect on display. Best in class.

It works.

How I hate that sentence.

Whenever that sentence pops up, I wanna take a frying pan, make some bacon, eat the bacon and slam the still hot pan with grease through someone's face till the skull breaks.

Why has he so many anger issues, one might ask.

Usually the sentence "It works" means that after looking at "working thing" it works wrong in 95 % of all cases, but hey - for 5 % it at least does *something* right. Not everything, don't get ya hope up.

We had this fun topic happening again today and I'm still too angry to sleep.

Lucene analysis of texts in Elasticsearch.

Stopword list? Multiple word n-grams per line, duplicates, not lower cased, not properly encoded.

Tokenizers? Duh. Why should one put them in proper order.... Or more realistic: There is an order in tokenizers necessary *devs with shocked faces*.

Language specific details... UHM. Wait. Languages are different? There are edge cases in languages? *more shocked faces*.

Even more shocking that if an text processing pipeline is implemented horribly wrong, it delivers wrong results. *mind blown*.

But our unit tests (this goes out to @kiki) were working.

Yeah. You dumb nuggets who even an amoeba would be ashamed of, when you only do positive tests in unit tests with the most obvious working examples, then your unit tests are just useless waste of nibbles.

Some of the devs are really a fucking waste of genetic information, should have probably ended better in a sock.

If this sounds too harsh, they had 2 weeks.
In just 3 hours I found out that they can redo that with supervision.

-.-

I'm getting too old for that shit. Seriously.

Ok, so our team is responsible for writing an app that consumes an API written by the client's team (I refuse to call it a "REST" API, despite their claims). On one of the clarification meetings we are discussing an endpoint that accepts a (logically) unique field multiple times, even though an entity is already registered in the system with that unique identifier. Our proposal would be that this API of theirs should not happily accept duplicates as many times as there are bits on a 4TB hard drive, rather it should signal an error.

The response we got is this: Due to the Separation of Concerns principle they thought that it should be our app's responsibility to not send a request if an entity with said field is already in the system. Thus there's no need for the backend to validate this.

I didn't hear the next part, because I had to collect my headphones from the other side of the room where they were flung in rage.

MTP is utter garbage and belongs to the technological hall of shame.

MTP (media transfer protocol, or, more accurately, MOST TERRIBLE PROTOCOL) sometimes spontaneously stops responding, causing Windows Explorer to show its green placebo progress bar inside the file path bar which never reaches the end, and sometimes to whiningly show "(not responding)" with that white layer of mist fading in. Sometimes lists files' dates as 1970-01-01 (which is the Unix epoch), sometimes shows former names of folders prior to being renamed, even after refreshing. I refer to them as "ghost folders". As well known, large directories load extremely slowly in MTP. A directory listing with one thousand files could take well over a minute to load. On mass storage and FTP? Three seconds at most. Sometimes, new files are not even listed until rebooting the smartphone!

Arguably, MTP "has" no bugs. It IS a bug. There is so much more wrong with it that it does not even fit into one post. Therefore it has to be expanded into the comments.

When moving files within an MTP device, MTP does not directly move the selected files, but creates a copy and then deletes the source file, causing both needless wear on the mobile device' flash memory and the loss of files' original date and time attribute. Sometimes, the simple act of renaming a file causes Windows Explorer to stop responding until unplugging the MTP device. It actually once unfreezed after more than half an hour where I did something else in the meantime, but come on, who likes to wait that long? Thankfully, this has not happened to me on Linux file managers such as Nemo yet.

When moving files out using MTP, Windows Explorer does not move and delete each selected file individually, but only deletes the whole selection after finishing the transfer. This means that if the process crashes, no space has been freed on the MTP device (usually a smartphone), and one will have to carefully sort out a mess of duplicates. Linux file managers thankfully delete the source files individually.

Also, for each file transferred from an MTP device onto a mass storage device, Windows has the strange behaviour of briefly creating a file on the target device with the size of the entire selection. It does not actually write that amount of data for each file, since it couldn't do so in this short time, but the current file is listed with that size in Windows Explorer. You can test this by refreshing the target directory shortly after starting a file transfer of multiple selected files originating from an MTP device. For example, when copying or moving out 01.MP4 to 10.MP4, while 01.MP4 is being written, it is listed with the file size of all 01.MP4 to 10.MP4 combined, on the target device, and the file actually exists with that size on the file system for a brief moment. The same happens with each file of the selection. This means that the target device needs almost twice the free space as the selection of files on the source MTP device to be able to accept the incoming files, since the last file, 10.MP4 in this example, temporarily has the total size of 01.MP4 to 10.MP4. This strange behaviour has been on Windows since at least Windows 7, presumably since Microsoft implemented MTP, and has still not been changed. Perhaps the goal is to reserve space on the target device? However, it reserves far too much space.

When transfering from MTP to a UDF file system, sometimes it fails to transfer ZIP files, and only copies the first few bytes. 208 or 74 bytes in my testing.

When transfering several thousand files, Windows Explorer also sometimes decides to quit and restart in midst of the transfer. Also, I sometimes move files out by loading a part of the directory listing in Windows Explorer and then hitting "Esc" because it would take too long to load the entire directory listing. It actually once assigned the wrong file names, which I noticed since file naming conflicts would occur where the source and target files with the same names would have different sizes and time stamps. Both files were intact, but the target file had the name of a different file. You'd think they would figure something like this out after two decades, but no. On Linux, the MTP directory listing is only shown after it is loaded in entirety. However, if the directory has too many files, it fails with an "libmtp: couldn't get object handles" error without listing anything.

Sometimes, a folder appears empty until refreshing one more time. Sometimes, copying a folder out causes a blank folder to be copied to the target. This is why on MTP, only a selection of files and never folders should be moved out, due to the risk of the folder being deleted without everything having been transferred completely.

(continued below)

Holly crap..... Just fixed a 7 months old bug in a system i worked on and had to leave it for 7 months coz i just wasn't seeing what i did wrong and today..... everything simply unraveled

It's a flask app and i got stuck on updating a column in the database and also it created duplicate configs on one of the configuration functionality

Figured out what was causing duplicates
A different function was creating new configs instead of updating...bypassing duplicate checking in the config function

I can now appreciate some design decisions behind react-redux after witnessing some angular OOP clusterfuck.

I am sure there is some clean/correct way to code in angular, but everyone is treating angular as java.

Some angular application (the one I have to work with) is littered with network calls. It's difficult to spot duplicates. People usually resolve promises everywhere. In services, in a top-level component, or in for loops. In react, people use apollo/redux-query or redux-saga to handle network calls. Since these libraries prevent duplicate network calls internally and reassigning apollo network call function or redux action function is always useless, it's easy to spot all network calls in a component tree.

In angular, it's difficult to trace data mutations when data can be updated everywhere. In react, you can easily find UI state updates by tracing state hooks/dispatch/apollo usages.

In angular, it's difficult to trace data pipeline. Since everything is imperative by default, people need to add update functions in data subscriptions. With all the littered mutations. Soon you will lose track of what the fuck is going on.

I hope angular get the agonizing death it deserves and fuck everyone who codes JS OOP clusterfuck UI.

Context: data warehouse

A colleague gets notified that his historisation produces duplicates. He checks the tables, sees that something has gone wrong ... and asks me for help.

I'm so sorry but I had to laugh so hard. Turns out everything crashed cause the value to be historised had changed back to an earlier version (which can happen). And now I'm here wondering how someone who calls himself a senior dev can create a historisation without taking care of gaps and islands. Seriously, how can you not think about that?