aslkfjasf. i've spent 12 hours today (and lots more over the past two days) trying to reproduce a bug that my [sort of] coworker insists is present. I haven't seen any proof of it anywhere, let alone steps to reproduce it.

I've poured through the code, following all of its tangled noodles of madness from start to fuck-this-shit. I've read and reread the pile of demon excrement so many times i can still read the code when i close my eyes. so. not. kidding.

anyway, the coworker person is getting mad because i haven't fixed the bug after days, and haven't even reproduced it yet. This feature is already taking way too fucking long so I totally don't blame him. but urghh it's like trying to unwind a string someone tied into a tight little ball of knots because they were bored.

but i just figured out why I haven't been able to reproduce it.

the stupid fucking unreliable dipshit ex-"i'm a rockstar and my code rocks"-CTO buffoon (aka API Guy, aka the `a=b if a!=b`loody pointless waste of mixed spaces and tabs) that wrote the original APIs ... 'kay, i need to stop for breath.

The dumbfuck wrote the APIs (which I based the new ones on mostly wholesale because wtf messy?), but he never implemented a very fucking important feature for a specific merchant type. It works for literally every type except the (soon-to-be) most common one. and it just so happens that i need that very specific feature to reproduce this bug.

Why is that one specific merchant type handled so differently? No fucking idea.

But exactly how they're handled differently is why I'm so fking pissed off. It's his error checking. (Some) of his functions return different object types (hash, database object, string, nullable bool, ...) depending on what happened. like, when creating a new gift, it (eventually...) either returns a new Gift object or a string error basically saying "ahhh everything's broken again!" -- which is never displayed, compared against, or recorded anywhere, ofc. Here, the API expects a Hash. That particular function call *always* returns a Hash, no matter what happens in the myriad, twisting, and interwoven branches the code could take. So the check is completely pointless.

EXCEPT. if an object associated with another object associated with the passed object (yep) has a type of 8. in which case, one of the methods in the chain returns a PrintQueue that gets passed back up the call stack. implicitly, and nested three levels in. ofc.

And if the API doesn't get its precious Hash, it exclaims that the merchant itself is broken, and tells the user to contact support. despite, you know, the PrintQueue showing that everything worked perfectly. In fact, that merchant's printer will be happily printing away in the background.

All because type checking is this guy's preferred method of detecting errors. (Raise? what's that? OOP? Nah, let's do diverging splintered-monolithic with some Ruby objects thrown in.)

just.
what the crap.

people should keep their mental diarrhea away from their keyboards.

Anyway. the summary of this long-winded, exhaustion-fueled tirade is that our second-most-loved feature doesn't work on our second-most-common merchant type.

and ofc that was the type of merchant i've been testing on. for days. while having both a [semi] coworker and my boss growing increasingly angry at me for my lack of progress.

It's also a huge feature, and the boss doesn't understand that. (can't or won't, idk)

So.
yep.
that's been my week.

...... WHAT A FUCKING BUFFOON!

I opened a post starting with a "NO TOFU" logo and I was wondering what relationship existed between the SSH protocol and anti-vegan people.

After some paragraphs it explained that TOFU stands for Trust On First Use (a security anti-pattern).

Me: Right, time to sit down and write some code.

Also me: I think I need to try a new IDE to see if that makes me more productive.

Productivity tools are my own productivity anti-pattern...!

While reviewing a PR from one of our newer FE devs, I ended up spending more time than I would like mulling over its composition. The work was acceptable for the most part; the code worked. The part that got me was the heavy usage of options objects.

When encountering the options object pattern (or anti-pattern, at times) in complex scenarios, I have to resist the urge to stop whatever I'm doing and convert it to the builder pattern/smack them in the head with a software design manual. As much as I would like to, code janitor is one of the least valuable activities I engage in daily, and consistently telling someone to go back to the drawing board for work that is functional, but not excellent is a great way to kill morale. Usually, I'll add a note on the PR, approve it, add a brown bag or two on that sort of thing, and make attendance mandatory for repeat slackers. Skills building and catharsis all rolled up in a tiny ball of investing in your people.

Builders make things so much cleaner; they inform users what actions are available in a context; they tend to be immutable, and when done well, provide an intuitive fluent interface for configuration that removes the guesswork. As a bonus, they're naturally compositional, so you can pass it around and accumulate data and only execute the heavy lifting bits when you need to. As a bonus, with typescript, the boilerplate is generally reduced as well, even without any code generation. And they're not just a dumping ground for whatever shit someone was too lazy to figure out how to integrate into the API neatly.

They're more work in js-land, sure; you can't annotate @builder like with Lombok, but they're generally not all that much work and friendlier to use.

Dev. policy: The use of SELECT * is forbidden.

Open Data Access Layer > first statement: SELECT * FROM bullshit_table

Oh gee whiz fellas. I lived through my nightmare. Recently too.

(Multiple rants over last few months are merged in this one. Couldn't rant earlier because my login didn't work.)

I joined a new shithole recently.
It was a huge change because my whole tech stack changed, and on top of that the application domain was new too.

Boss: ho hey newbie, here take this task which is a core service redesign and implementation and finish it in two weeks because it has to be in production for a client.

Normally I'd be able to provide a reasonable analysis and estimate. But being new and unaware of how things work here, I just said 'cool, I'll try my best.' (I was aware that it was a big undertaking but didn't realize the scope and the alarming lack of support I'd get and the bullshit egos I'd have to deal with)
Like a mad man I worked 17+ hours a day with barely a day off every week and changed and produced a lot of code, most of it of decent quality.

Deadline came and went by. Got extended because it was impossible (and fake).

All the time my manager is continuously building pressure on me. When I asked questions I never got any direct/clear answers. On asking for help, I'd get an elaborate word vomit of what was already known/visible. Yet I finally managed to have an implementation ready.

Reviewer: You haven't added parameter comments on your functions and there aren't enough comments in code. We follow standards. Clean code and whatnot. Care for the craft verbal diarrhea.

Boss: Ho hey anux, do you think we'll be able to push the code to production?

Me: Nope. We care for the craft and have standards. We need to add redundant comments to self documented code first, because that is of utmost importance as Nuthead reviewer explained.
(what I wish I had said)

What I actually said: No, code is not reviewed yet.

And despite examples of functions which were not documented (which were written by the reviewer nut), I added 6-7 lines of comments for my single line functions describing how e.g. Sum takes two input integers and returns their sum and asked for a review again.

Reviewer: See this comment is better written as this same-meaning-but-slightly-longer way. Can we please add full stops everywhere even though they were not there to begin with? Can we please not follow this pattern and instead promote our anti-pattern? Thanks.

Me: Changed the comments. Added full stops. Here's a link for why this anti-pattern is bad.

Reviewer: you have written such beautiful code with such little gems. Brilliant. It's great to see how my mentoring has honed your skills.
.
.
.
I swear I would have broken a CRT on his stupid face if we weren't working remotely (and if I had a CRT).

It infuriates me how the solution to every problem with this guy is 'add a comment'.

What enrages me more is that I actually thought I could learn from this guy (in the beginning). My self doubt just made me burnout for little in return.

Thankfully this living nightmare will soon be over.

Weekly Group Rant suggestion: What anti-pattern exists that still keeps being propagated or infecting other areas of your code base (like a virus)?

Code samples/screen-shots required.

What do you do when your client WANTS a shitty website?
If it's considered a UI anti-pattern, he wants it.

I'm pretty frustrated because I keep bringing him what I consider professional-quality work and he's disappointed, asks for something dumb instead. I made the mistake of giving him Photoshop and encouraging him to try to design some of his ideas. I thought he would be frustrated and decide, okay, Patrick knows best. But that backfired. Now I'm forced to answer basic questions about "how to delete the pixels" and end up on TeamViewer for hours trying to explain vector masks.

His current bright idea is to advertise his product with a comic strip. And let me tell you, it looks really, really awful. Not tasteful material-design-esq vectors, he thinks those are dumb, he prefers crude clipart. But he loves it.

I've kind of dug myself a hole here. It's what the client wants. But the client wants a steaming pile of shit. What do I do? Also forgot to mention, dude is my landlord and I'm behind on rent. FML

pic related; it's his comic

I've been inspired by cpg grey (I think that's the name), mainly his 10 tips on how to be miserable, to write a blog or some kind of post explaining the 8 things you need to do if you hate your coworkers and want your codebase to go to shit.

So it'll be like a anti-SOLID, anti-pattern type of blog promoting every code smell imaginable

I feel like 8 tips to fuck up your codebase (php perhaps) might he more memorable than actual helpful advise. I'm sure that this has been done before, but I was wondering:

Do you think this would be effective? Would it help people understand why not to do the 8 tips? Does this reverse psychology work?

Today was a bad dev day working on a shitty React project. Not that React in itself is bad, but it can be hell to work with when the code is a big pile a crap full of anti pattern code. I spent the day refactoring to try to fix a bug, but to no avail. It would take days if not weeks to put some order in this mess and to prevent such bugs.

Few days back, I developed an app for a client where users can buy textile designs online.
The designs to be uploaded on the server must be square to display correctly on the app. so I had to make them square manually (by either pattern repetition or by filling extra space).

I was like "fuck me!", 800 design image to make it square and each takes like 1 and half minute. I did uploaded 30 to 40 images and then...

I got really frustrated and I was lazy to make more designs square anymore.. So I developed an algorithm that would identify the type of design and then it automatically makes it square by self decision.

so that was my little anti-laziness for my big laziness.

I don't know what to think of Vue 3 Composition API anymore. At first I hated it because it's nothing but one big ole rip off of React, and I hate React so much; its hook system is the most disgusting anti-pattern I've ever seen in the entire JS ecosystem. This gave me the incentive to try out Svelte instead, but after doing so, I look back at Vue 3 and noticed that they're kinda similar... why are so many JS devs allergic to classes? You can have much better written code that way. Idk, I'm waiting for vue-class-component and vue-property-decorator to fully migrate. In the mean time, if I'm gonna be forced to write composition based code, I might as well use Svelte.

Documentation is an anti-pattern

I was reading a few interesting postgreSQL solutions to constrain polymorphic tables (anti-pattern, I know) when something caught my eye.
Some solutions were looked down upon (or looked favorably upon) based on their portability to other rdbms like MySQL.
Is that really so important? I get it, if somehow you decide to change from one to the other for some god-forsaken reason it will make the switch easier. But really, how often will that happen?
I feel there is a tendency to just avoid using SQL beyond the basics.

Once took over a bunch of webservices from a coworker who had found another job.
Worst bunch of copy-pasted, anti-pattern, duplicates-ridden, dead-code infected spaghettimess I ever saw.
I spent a year getting that shit into a semblance of order. You could tell for certain the guy had no professional pride or sense of maintainability.

The kicker is, after that year of getting everything in shape, I got laid off due to cutbacks.

'Hey, great work, Refactor Ninja!
Now leave, you must be needed elsewhere!'

🙄

I was just asked to make a method for the "logical or" (aka "||") in JavaScript "because it's used multiple times".

How dense do you have to be to argue against "it creates additional closures" and "creating functions for built-in operators is an anti-pattern".

Come on!!! At least it's my last week here, I'll be done with this soon enough.

Now almost everything is a fuckin' anti-pattern

How do you know when you are senior level dev? What’s the threshold?

2codepaths1function

I need some advice to avoid stressing myself out. I'm in a situation where I feel stuck between a rock and a hard place at work, and it feels like there's no one to turn to. This is a long one, because context is needed.

I've been working on a fairly big CMS based website for a few years that's turned into multiple solutions that I'm more or less responsible for. During that time I've been optimizing the code base with proper design patterns, setting up continuous delivery, updating packaging etc. because I care that the next developer can quickly grasp what's going on, should they take over the project in the future. During that time I've been accused of over-engineering, which to an extent is true. It's something I've gotten a lot better at over the years, but I'm only human and error prone, so sometimes that's just how it is.

Anyways, after a few years of working on the project I get a new colleague that's going to help me on my CMS projects. It doesn't take long for me to realize that their code style is a mess. Inconsistent line breaks and naming conventions, really god awful anti-pattern code. There's no attempt to mimic the code style I've been using throughout the project, it's just complete chaos. The code "works", although it's not something I'd call production code. But they're new and learning, so I just sort of deal with it and remain patient, pointing out where they could optimize their code, teaching them basic object oriented design patterns like... just using freaking objects once in a while.

Fast forward a few years until now. They've learned nothing. Every time I read their code it's the same mess it's always been.

Concrete example: a part of the project uses Vue to render some common components in the frontend. Looking through the code, there is currently *no* attempt to include any air between functions, or any part of the code for that matter. Everything gets transpiled and minified so there's absolutely NO REASON to "compress" the code like this. Furthermore, they have often directly manipulated the DOM from the JavaScript code rather than rendering the component based on the model state. Completely rendering the use of Vue pointless.

And this is just the frontend part of the code. The backend is often orders of magnitude worse. They will - COMPLETELY RANDOMLY - sometimes leave in 5-10 lines of whitespace for no discernable reason. It frustrates me to no end. I keep asking them to verify their staged changes before every commit, but nothing changes. They also blatantly copy/paste bits of my code to other components without thinking about what they do. So I'll have this random bit of backend code that injects 3-5 dependencies there's simply no reason for and aren't being used. When I ask why they put them there I simply get a “I don't know, I just did it like you did it”.

I simply cannot trust this person to write production code, and the more I let them take over things, the more the technical debt we accumulate. I have talked to my boss about this, and things have improved, but nowhere near where I need it to be.

On the other side of this are my project manager and my boss. They, of course, both want me to implement solutions with low estimates, and as fast and simply as possible. Which would be fine if I wasn't the only person fighting against this technical debt on my team. Add in the fact that specs are oftentimes VERY implicit, so I'm stuck guessing what we actually need and having to constantly ask if this or that feature should exist.

And then, out of nowhere, I get assigned a another project after some colleague quits, during a time I’m already overbooked. The project is very complex and I'm expected to give estimates on tasks that would take me several hours just to research.

I'm super stressed and have no one I can turn to for help, hence this post. I haven't put the people in this post in the best light, but they're honestly good people that I genuinely like. I just want to write good code, but it's like I have to fight for my right to do it.

Anyone work with a dev "higher" up than you, but that "senior" dev really doesn't understand how to write good code? That dev also doesn't understand how to remove old un-used code and basically follows every anti-pattern in the book -- bad variable naming, using switch statements when an if would be more logical, etc. I don't know how these people reached the height of the totem pole that they are on, but my goodness is it frustrating. How can someone SO OBLIVIOUS have so much power?! And everywhere they go they leave a wake of destruction that undoubtedly will need to be cleaned up by someone else later down the time... It's like they don't care at all but deep down you know they are just bad at their job... UGH!

SQLAlchemy is such a bloated piece of crap. Even without the fact that many consider ORMs an anti-pattern, this library is extremely janky, salty and uncomfortable to work with.