So one year ago I was working at this company from the US, me being in Europe, which automatically implies there is several hours of timezone difference.

The eng. manager decided we would have a release tomorrow (decision was made one month earlier), and stuff was being prepped up to make that happen.

In the US the workday was about lunch time and in EU it was one hour before finishing. The manager gets us in a meeting and asks me and another dude to do some testing that would take several hours to do. This testing could have been done several days or weeks earlier.

40 minutes after that meeting I get a private message from the PM asking for the status of the test...

Me: aaa.. well I started it and will continue tomorrow

Manager: wait what? we have launch tomorrow, this testing has to be done by tomorrow

Me: it's the end of the workday here, I got personal errands that I have to attend to

Manager: uhm ok ... I see...

I was just messaging something in the public chat right before calling it a day and the manager writes "thanks for the input, your day is over now", completely out of context to the conversation I was having with whomever.

There was no question of "can you stay extra hours and do this?", there was no "hey, I know your day is over we will pay you premium hours with this amount as according to our contract, could you do this now as we have release tomorrow?" ..no ..just .. "do it!". I automatically assumed that ..hey, maybe he wants to do this during and after the live launch (and yes I do admit my mistake of not asking just to be clear, but I assumed the manager knows that there is a timezone difference ..like it's a no brainer).

I can not tell you the heat sensation I had after that last reply from the manager ... it was completely uncalled for, and unreasonable.

I mean why not make a pre-launch phase where you put stuff on the staging server, and perform all the necessary tests and then when you get all the green lights from testing you then proceed with the actual deploy? ...no ... mention this like right at the end of the day before the launch....

And another thing that scratched my neuronal cortex is, how does he know exactly how long the tests would take?

Me passing time on the weekend

Random call from unknown number

Turns out it's the manager

M: hey , how is your weekend going ...

Me: nothing much ... Whatsup ?

M : yeah well , we wanted to push some minor adhoc fixes as some clients wanted it urgently

The Devops folks need developer support . Can you pitch in and monitor

Me : I'm not aware of what changes are going , i don't think i can provide support

M : don't worry it's minor changes , it's already tested in pre prod , you just need to be on call for 30 mins

Me : ugh okay .. guess 1 hr won't hurt

M: thanks 👍🏽

Me: *logs in

*Notices the last merged PR
+ 400 lines , implemented by junior dev and merged by manager

*Wait , how is this a *minor* release...

*Release got triggered already and the CI CD pipeline is in progress

*5 mins later

*Pipeline fails , devops sends email - test coverage below 50%

Manager immediately pitches in ...

M: hey , i see test coverage is down , can you increase it ?

Me: and how do u suppose I do that ?

M : well it's simple just write UTC for the missing lines ... Will it take time ?

Me : * ah shit here we go again

Yeah it will take time , there are around 400 lines , I am not aware of this component all together

Can you ask junior dev to pitch in and write the UTC for this

*Actually junior dev is out on a vacation with his girlfriend

M : well he's out for the weekend , but
as a senior dev , i expect you to have holistic understanding of the codebase and not give excuses ,
this is a priority fix which client are demanding we need this released ASAP

Me : * wait wat ?

---

I ended up being online for next 3 hours figuring out the code change and bumping up the UTC 🤦🏾

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 think I just realized what my biggest gripe about our career paths that I hate the most.

This is something that has worsened over time, especially the last 2 to 3 years.

As developers, we have far too many options. Some of the most powerful apps are written with languages that have hard, and I mean HARD, guardrails in place. If the app is written in a language that does not meet this criteria usually a framework has been used to install those guardrails.

We just get our minds so wrapped around the possibilities and the opportunities in the software, that we just can't focus on the end result. We're like puppies that are excited about something and we just piss all over everything.

In my career I have met far too many developers that don't have the capacity and mental fortitude to take control of their actions. Because of this I think the only way for us to stop this corruption, that I feel we are nurturing, the solutions/services that we use need to push back on us and install those guardrails for us.

All this came from a change that Microsoft put in place that seems well intended, but introduces yet another choice and a multitude of opinions in how you release code.

It used to be a simple check box. If it was checked it was pre-release, if it was unchecked it was a production release. That's it. On or off. The simplest choice you ever needed to make on a release.

Now though, there are two check boxes. One for a pre-release and one for a latest release. You can also not check either for some "ephemeral" release? So now something as easy as on or off has been made into a difficult decision on how this works within my pipeline. Now every time I make a release I have to ask myself, "which one do I check?"

I shouldn't need to spend more than a second to identify a path forward on simple shit like this, but here we are with a third choice.

Can we just stop overcomplicating shit?