Programming should be like art, where you try and learn different skills and tools to get better over time.... Not a continuous game of whack-a-mole where your try to hit everything with a hammer...

¯\_(ツ)_/¯

Bugfixing is like whack-a-mole... For every one you squash, 3 more pop up.

CTO: We can't keep getting egg on our face letting these simple mistakes through. We value your expertise, please speak up.
QA: This looks fucky, should it look this fucky?
*crickets*
Dev: That is dangerously fucky.
QA: Ticket time.
PM: Hey Dev, I know it's not your AOE, but I need to assign it, and you spoke on it so here's your ticket.
Dev: *dies inside*

I took a job with a software company to manage their product, which was a SaaS property maintenance system for real estate, social housing, etc.

There was no charge to real estate agents to use it but maintenance contractors had to use credits to take a job, which they pre-purchased. They recharged their credit costs back to the real estate agent on their invoice).

Whether this pricing model is good or not, that's what it was. So, in I came, and one of the first things management wanted me to deal with was a long-standing problem where nobody in the company ever considered a contractor's credits could go into the negative. That is, they bought some credits once, then kept taking jobs (and getting the real estate agent to pay for the credits), and went into negative credits, never paying another cent to this software company.

So, I worked with product and sales and finance and the developers to create a series of stories to help get contractors' back into positive credits with some incentives, and most certainly preventing anyone getting negative again.

The code was all tested, all was good, and this was the whole sprint. We released it ...

... and then suddenly real estate agents were complaining reminders to inspect properties were being missed and all sorts of other date-related events were screwed up.

I couldn't understand how this happened. I spoke with the software manager and he said he added a couple of other pieces of code into the release.

In particular, the year prior someone complained a date on a report was too squished and suggested a two-digit year be used. Some atrocious software developer worked on it who, quite seriously, didn't simply change the formatting of that one report. No, he modified the code everywhere to literally store two-digit years in the database. This code sat unreleased for a year and then .... for no perceivable reason, the moron software manager decided he'd throw it into this sprint without telling me or anybody else, or without it being tested.

I told him to rollback but he said he'd already had developers fixing the problems as they came up. He seemed to be confident they'd sort it out soon.

Yet, as the day went on more and more issues arose. I spoke to him with the rest of the management team and said we need to revert the code but he said they couldn't because they hadn't been making pull requests that were exclusive to specific tickets but instead contained lots of work all in one. He didn't think they could detangle it and said the only way to fix was "play whack-a-mole" when issues came up.

I only stayed in that company for three months; there was simply way too much shit to fix and to this day I still have no idea the reasoning that went on in the head of anyone involved with that piece of code.

Current debugging situation has been described as “purgatory’s whack-a-mole”

Dependency hell is the largest problem in Linux.

On Windows, I just download an executeable (.exe) file, and it just works like a charm! But Linux sometimes needs me to install dependencies.

At one point, I nearly broke my operating system while trying to solve dependencies. I noticed that some existing applications refused to start due to some GLIBC error gore. I thought to myself "that thing ain't gonna boot the next time", so I had to restore the /usr/lib/x86_64-linux-gnu/ folder from a backup.

And then there is a new level of lunacy called "conflicting dependencies". I never had such an error on Windows. But when I wanted to try out both vsftpd and proFTPd on Linux, I get this error, whereas on Windows, I simply download an .exe file and it WORKS! Even on Android OS, I simply install an APK file of Amaze File Manager or Primitive FTPd or both and it WORKS! Both in under a minute. But on Linux, I get this crap. Sure, Linux has many benefits, but if one can't simply install a program without encountering cryptic errors that take half a day to troubleshoot and could cause new whack-a-mole-style errors, Linux's poor market share is no surprise.

Someone asked "Why not create portable applications" on Unix/Linux StackExchange. Portable applications can not just be copied on flash drives and to other computers, but allow easily installing multiple versions on a system. A web developer might do so to test compatibility with older browsers. Here is an answer to that question:

> The major argument [for shared libraries] is security, that if there is a vulnerability in a commonly-used library, then only that library has to be updated […] you don't have to have 4 different versions of a library installed

I just want my software to work! Period. I don't mind having multiple versions of libraries, I simply want it to WORK! To hell with "good reasons" for why it doesn't, and then being surprised why Linux has a poor market share. Want to boost Linux market share? SOLVE THIS DAMN ISSUE!.

Understand that the average computer user wants stuff to work out of the box, like it does in Windows.

Removing errors from code is like playing whack-a-mole.

You hit one and two pop up again.

Maintaining shitty code is a lot like playing whack a mole. Fix one thing, something else breaks. I wish they'd just let me replace this garbage already. Could've been done by now.

Just reported a minor tracking bug I found on WebKit to the WebKit bugzilla, and I have a few thoughts:

1. Apple product security can be kind of vague sometimes - they generally don't comment on bugs as they're fixing them, from the looks of it, and I'm not sure why that is policy.

2. Tracking bugs *are* security bugs in WebKit, which is quite neat in a way. What amazes me is how Firefox has had a way to detect private browsing for years that they are still working on addressing (indexedDB doesn't work in private browsing), and chrome occasionally has a thing or two that works, with Safari, Apple consistently plays whack-a-mole with these bugs - news sites that attempt to detect private browsing generally have a more difficult time with Safari/WebKit than with other browsers.

I guess a part of that could be bragging rights - since tracking bugs (and private browsing detection bugs, I think) count as security bugs, people like yours truly are more incentivised to report them to Apple because then you get to say "I found a security bug", and internal prioritisation is also higher for them.

Let me just say that I've been playing whack a mole with a new feature for while now. And it's becoming very tiring.

TLDR; CTO is changing the way we're going to implement this, every other day.

June 1st,
CEO: let's implement feature AAA,
CTO: we're going to have a call with Andy to tell us all about his product that will make this super easy, call will be June 4th.

Days before June 4th,
Me: Researchs product X, makes demo works flawlessly.

June 4th,
Call all good, few tips from Andy. We come to the pricing section of Product X

CTO: this will not work, pricing doesn't fit on our budget, fair enough.

June 7th -11th
Me: research altenative approach. Makes second demo.

CTO: Works good, seems to have too many moving parts, let's have call with Bob to check Product Y. It should make our lifes easier.

ME: Geee, ok let's check it out.

June 14th,

Call with Bob, all good, product has a fair price, stuff is experimental.

CTO: let's use Product Y, and just use what we get from their api now, and worry about changes later.

Me: Hmmm, that's a bit risky, but ok, you the boss, right?, starts again new demo. API doesn't work as documented.

Lots of trial and error to figure out how the api is working now, finally demo works well,

June 17th,

API changed, now it works as documented, (expected as it is experimental), previous demo doesn't work anymore.

June 18th,

Redoing research. inputs are completely different from Product Y now, need to redo all that is working and do and a lot more of research.

Go live is scheduled for end of next week, I hope that the API is stable now, and that I get to go live on schedule.

It is funny to see, that it would probably been the same if we just waited on the API to stabilize, and check the pricing section before choosing a product? Who knows.

Anyways, I actually feel happy that over the years I developed the patience to work with ever changing situations like this one.

I’ve had to fix code that was “working just fine” until someone decided to “make a small change.” Programming is like a never-ending game of whack-a-mole 🐭. But hey, at least we have our clever jokes and endless supply of energy drinks 🥤 to keep us going. 😂

Okay so being a developer is mostly like playing a never ending game of whack-a-mole with BUGS, you think you have fixed one until few more pops up like a bad case of acne.
But you know what's even worse? When you finally get something working, and you're feeling all proud of yourself, and then someone comes along and tells you that it's not "visually appealing" enough. "Can't you just add some more glitter and unicorns to the homepage? Oh, and can you make it look like it was designed by a unicorn who majored in art?"

So I am currently updating a application from play framework version 2.5 to 2.6 and am working through all the dependency updates... I feel like I am playing whack a mole.
and now there are suddenly ClassNotFoundExceptions because the classes are not in the same classloader as before and the access over reflection doesn't work anymore.

Anyone got some tips why the classloader is differing?
I think it might be because some dependency conflicts or such.

There's a special place hell for people who put their entire documentation on using an NPM package in the fucking READ.ME file.

I shouldn't have to play whack a mole through one giant ass file to figure out how a specific function works. Or figure out how specific optional parameters need to be defined.