worst experience with a manager was the (female) one who got away with harassing a female employee for YEARS and thought it was ok because she thought they were friends.

She also retaliated (in ways that were hard to prove), played favorites, didn't know metrics or general business sense, couldn't do her employee's jobs but loved to tell them how they were wrong all the time, and then when she was fired, after the female coworker finally reported the ass slapping and the harassment based on disability, she went back into employee only areas with client personal information and thought taking selfies was ok (she was very quickly corrected and had to wipe her phone and memory card to ensure she hadn't been doing it when she wasn't caught, which cameras later proved she had been).

(I only sound calm. I will take a needle to her probably fake boobs and deflate them with glee if I ever see her again)

Remember kids: the more space a compression algorithm saves, the slower it is to deflate/inflate!

(imho this is why xzip isn't as mainstream as it is)

I choose to believe performance self assessments are useful. Not for, like, my actual job, but they keep me grounded. Nothing like seeing your entire body of work for a year summed up in 30 to 40 bullet points to deflate your ego. Also it gives me a chance to work on my skills in what some of you might consider "lying" though I consider it more along the lines of "creative truth telling" and "having a loose grasp on reality".

I've decided to, as an educational exercise, implement DEFLATE compression / decompression and zip file format, and eventually tackling Excel format (which is just a .zip) so I can generate true excel spreadsheets (instead of .csv files) client-side using JavaScript.

Are there already libraries that do this? Yes, but then I don't get to try to implement these interesting algorithms. Is it currently 1 AM? Yes. Do I have work tomorrow? Also yes.

If I don't just fall flat on my face, I'll post updates!

Ticket: implement compression algorithm to crypto object x

Details: object to big, we must devise a way to compress it. A deflate algorithm should be added here, yada yada yada we did not have the time Yara yada...

Go see crypto provider's documentation... It has compression options... -_-

You lazy fucking stack overflow copy question dimwits!!! Jesus fucking Christ! This reached production like this shit, I've got clients complaining of the size of the payload because you are a bunch of lazy fucks who can't even read simple documentation!!!

I want to kill someone for wasting my time and patience... Don't call me for this kind of crap... I have better things to do!

I mean, the time it took you to write the ticket should suffice...

Persisterising derived values. Often a necessary evil for optimisation or privacy while conflicting with concerns such as auditing.

Password hashing is the common example of a case considered necessary to cover security concerns.

Also often a mistake to store derived values. Some times it can be annoying. Sometimes it can be data loss. Derived values often require careful maintenance otherwise the actual comments in your database for a page is 10 but the stored value for the page record is 9. This becomes very important when dealing with money where eventual consistency might not be enough.

Annoying is when given a and b then c = a + b only b and c are stored so you often have to run things backwards.

Given any processing pipeline such as A -> B -> C with A being original and C final then you technically only need C. This applies to anything.

However, not all steps stay or deflate. Sum of values is an example of deflate. Mapping values is an example of stay. Combining all possible value pairs is inflate, IE, N * N and tends to represent the true termination point for a pipeline as to what can be persisted.

I've quite often seen people exclude original. Some amount of lossy can be alright if it's genuine noise and one way if serving some purpose.

If A is O(N) and C reduces to O(1) then it can seem to make sense to store only C until someone also wants B -> D as well. Technically speaking A is all you ever need to persist to cater to all dependencies.

I've seen every kind of mess with processing chains. People persisting the inflations while still being lossy. Giant chains linear chains where instead items should rely on a common ancestor. Things being applied to only be unapplied. Yes ABCBDBEBCF etc then truncating A happens.

Extreme care needs to be taken with data and future proofing. Excess data you can remove. Missing code can be added. Data however once its gone its gone and your bug is forever.

This doesn't seem to enter the minds of many developers who don't reconcile their execution or processing graphs with entry points, exist points, edge direction, size, persistence, etc.