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.

When I started university, I was getting out of some really awful situations-- emotionally abusive parents, a boyfriend who was blackmailing me, a truly bizarre rape, etc. My life had been a little rough, and I was dealing with some PTSD.

My first computer science course was great. The professor was clear, patient, everything a sensitive student needed. I was able to concentrate on the curriculum without any problems.

The second 'intermediate' course, though? Not so much. The professor shouted his lectures during the entire class period in a relatively small classroom. Occasionally, he would clasp his hands and move around pretty unpredictably (like jumping out at the class), which spooked me a few times. He also always seemed like he was just hovering on the edge of madness, like he was just barely keeping it together, but he never broke.

I sat in the front row and was absolutely terrified during his lectures because it seemed like he was mad at me. I was half expecting him to start attacking me at any moment. Because, you know, PTSD.

I was also only getting a comp sci minor, so the other students looked at me like I wasn't supposed to be there, which also made me feel pretty uncomfortable, but such is life.

After most classes with him, I would need to take about an hour or two afterwards to calm down, stop shaking, and recompose myself. I looked forward to test days because he wouldn't yell. It was rough.

Later on, I learned that he used to be a gym teacher, which explains the jumping and yelling. Also, his wife, daughter, and dog all died within six months of each other the year prior, which might explain why he always seemed so on edge.

>Be me
>Decided to annoy a friend somehow
>???
>Found a VBScript on the Internet
>VBScript runs, waits for 30 minutes, and then ejects the disc drive every 5 minutes
>Sneakily hide and execute the VBScript on friend's laptop before class
>*Patiently waits*
>It begins
>Friend casually closes the disc tray the first time
>See him gradually get annoyed and descend into madness before I tell him what in tarnation is happening
>Such fun

I can't stand Swift's initializers. No other languages have the problem with constructors/initializers that Swift does. It's a complete failure of a feature and to hell with safety if it comes with this cost.

Just to illustrate how ridiculous it gets, I want to have a class where my initialization logic can be split among reusable parts. That is, the logic that initializes the class with no parameters has logic that I want to reuse in my other initializers. Simple DRY stuff. Well, the only way I can do that in Swift is if I use a convenience initializer that calls another one. But convenience initializers have completely different rules from designated initializers (again, something only Swift does).

For example, you can't access "self" until you call a designated initializer. You can't chain designated initializers, and if you want to chain anything in the same class you have to handcuff yourself by using a "convenience" initializer (there's nothing convenient about them, I might add).

So now I want to subclass my class and initialize myself using one of my superclass initializers. Oh but the one I want to call is a *convenience* initializer so I can't, unless I turn my new initializer into a convenience initializer. Except wait, a convenience initializer must delegate with self.init(), so it can't even call a superclass initializer!

And it just goes round and round and round. I don't know if I should try to convert all of my initializers to convenience initializers or the other way around.

Why all this nonsensical madness? Get rid of the distinction and go back to nice clean powerful initializers like Objective-C. I mean what does it have to take? This is a complete nightmare.

When you're using openapi generators and stuff for generating SDK code and let "the architect" handle the data structure and nomenclature, don't you hate having to add 33 (I counted) models, most of which are just the same class with different name or one property apart from each other, serialization of which gives request body overhead 56-132x (actual calculated results depending on the model complexity) the size of actual data you want to send, just to add support for one endpoint that needs just one model that started this whole madness?
I just had to add this one top level model reference and this happened to me. Those 33 models are not including the ones I already had included in my project so they didn't have to import them again.
For the love of <your_belief_here /> and all that's holy, never ever agree on generating code based on openapi if the person responsible for that is unexperienced. It will do more harm than good, trust me.
Before we decided to go with generated SDK my compiled product was a bit over 30KB, and worked just fine, but required a bit of work on each breaking API change. Every change in the API requires now 75% of that work and the compiled package is now over 8MB (750KB of which is probably my code and actually needed dependencies).
Adding an endpoint handler before? Add url, set method and construct the body with the bare minimum accepted by the server
Now? Add 33 models (or more), run full-project find&replace and hope it will work with the method supplied by the generated code, because it's not a mature tech and it's not always guaranteed it will work.