Excerpts from "Bastard devops from hell" checklist:

- Insistently pronounce git with a soft "G" and refuse to understand people not using that pronunciation, the same goes for jithub, jitlab, jit lfs, jitkraken etc.

- Reject all pull requests not in haiku format, suggest the author needs to be more culturally open minded when offending.

- increment version numbers ONLY based on percentage code changed: Less than 1% patch increment, less than 5% minor increment, more than that major version increment.

- Cycle ALL access keys, personal tokens, connection strings etc. every month "for security reasons"

- invent and only allow usage of your own CI/CD language, for maximum reuse of course. Resist any changes to it after first draft release

“We mob every thing so that means we don’t need pull requests, because by the time the code is committed it’s had plenty of pairs of eyes on it”

Well, I beg to differ.
Today I read through some of this spaghetti mobbed code to look into a performance issue. Wasn’t supposed to but bored stiff so I ‘went dark’ and did it without the mob.

After about an hour I figured out it runs a few lines of dubious code and if there’s an error it tries many times over with an exponential back off.
And each run of the methods will fail for sure because of how it’s written.
Someone must’ve seen this problem but instead of realising it can never work, they’ve wrapped it in retries and back offs.

So many back offs and retries that it just sits there doing this for 25 minutes.

But yeah. The mobbing works great guys, keep churning out this quality code. 😂😂😂
Can’t wait to see the back of this joke job.

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.

I give up. Some of these pull requests will never get approved.

Something I hate about working in the team is that the code reviewer will stall the time and leave a lot of pull requests unreviewed. As more code changes more commits and more pull requests.

The code base is conflicting with each other, what the fuck? I hate this.

My manager says you shouldn't be doing archaeology work looking at old pull requests and git diffs to figure out how things work.

Are there scenarios when this is useful? How common are they in your day to day?

Writing my first code review. Even though it really is a nice review and I'm happy with the solution code, I still somehow feel like an asshole for each critique I make. Maybe it's unavoidable with code reviews / pull requests?

It's funny when you MUST create two pull requests (from feature to ART main and from ART main to dev) also if the feature is just one because you need to respect the shitty flow.