Dev: (Watches user print out screenshot of maintenance app to do list, walk across facility to printer. walk across facility to equipment and check things off on paper, then walk across facility back to their terminal and copy the findings over.)

Dev: We made the app responsive so they could do that on a mobile device. Why are they printing?

Manager: Printers are cheaper than getting more tablets.

Dev: …

Dev: Can we at least get a printer at each terminal so they don’t waste so much time walking across the facility?

Manager: That’s too many printers to maintain. It’s easier to just have one.

Dev: …

*During a walk around to check on the users*

Dev: *Watching worker laboriously dragging pallet jack with one wobbly wheel and another wheel practically seized*

Dev: Hey that looks broken, can’t you swap it out in the maintenance building?

Worker: If you do that management will give you one that’s worse.

Dev: …This fucking company

** Worker later threw out his back, company’s corrective action was to send out notice reminding employees to stretch before doing physical tasks

1) Read the wiki on git. I probably have enough shorthands and test methods that you won't need much other shit to debug issues.

2) when debugging, remember that if it is there, there's a good reason why I put it there.

3) commented-out code is probably useful for maintenance. I left it there for a good reason. 😛

4) chances are whatever I wrote, was the state of the art at the time I wrote it. There might be better ways to do it now tho.

5) I always work modular. First, understand the structure. (probably also documented on wiki) DO NOT fuck up the structure. If you change it, you document it.

6) If you feel I wrote shit, it's probably because management annoyed the living shit out of me. Pun intended.

7) Your confusion is normal. I don't do dumb shit.

There's one thing I hate about the new year. Everyone assumes it's the best time to do some cleanup, some maintenance. As the year starts fresh - everyone should start fresh, right?

NOT!

No, Hetzner, you don't need to restart my servers on Dec 26th.
No, local VPS providers, you don't need to clean-up all my /tmp/ files for me on Dec 29th, leaving me in the dark and unaware I have to restart my apps.

That's just a dick move. Your intentions might be alright, but the consequences... Damn you!

this year i finally found a job where I don't feel like dying, and it pays well. things are going so smoothly that I'm a bit weirded out, in a good way.
the work as a dev requires creativity and is mentally exhausting, but i got a nice routine going on (not a lot of programming, mostly database maintenance), and even with the high pressure I'm still fine :)

Small chaotic startup that never grew up (15 years atm).
Hosts/maintains a number of apps/sites for various customers.

At some point, someone decides that a CMS would be usefull to maintain the content across all products. Forgoing all sense, reason and the very notion of "additional maintenance and dev" it is decided that one should be built in-house.

Fast forward a number of years.

Ops performs routine maintenance on prod-servers. A java-patch accidently knocks out one of the pillars a 3rd party lib the CMS uses for storing images. CMS basically burst in to flames causing a.... significant incident.

Enter yours truly to fix the mess.
Spend a few days replacing the affected 3rd party lib. Run tests on CMS in test and staging environments. Apply java-patch. All seems fine.

When speaking to frontenders and app-devs, a significant hurdle present itself:
All test/staging instances of all websites/apps/etc ALL USE PRODUCTION CMS. Hardcoded. No way around.

There is -no- way to properly test and verify the functionality of any changes made to the home-brewed CMS.
My patch did indeed work in the end.

But did the company learn anything? Did they listen to my reasoning, pleading or even anguished screams for sanity?

No.

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.

My best and worst dev experience this year was getting a new job.

The bad parts: I’m inheriting a code base that was maintained by an outside agency, so there’s very little documentation. There’s a lot of systems maintenance and upgrades that have to be done because it was never done. I’m working at a larger organization, so tracking down who I need for info can be tricky. I’m the only person maintaining my code base.

Now the good parts: Better pay and benefits. My co workers, dev and non-dev, are always helpful. Since the dev team is small, we are very discerning when we pick up work for the websites. I have more independence to self-learn. I’m not at a blame culture. My role is permanently remote.

So far I think the good outweighs the bad.

A philosophical question about maintenance/updating.

There is no need to repeat the reasons we need to update our dependencies and our code. We know them/ especially regarding the security issues.
The real question is , "is that indicates a failure of automation"?

When i started thinking about code, and when also was a kid and saw all these sci fi universes with robots etc, the obvious thing was that you build an automation to do the job without having to work with it anymore. There is no meaning on automate something that need constant work above it.

When you have a car, you usually do not upgrade it all the time, you do some things of maintance (oil, tires) but it keeps your work on it in a logical amount.
A better example is the abacus, a calculating device which you know it works as it works.

A promise of functional programming is that because you are based on algebraic principles you do not have to worry so much about your code, you know it will doing the logical thing it supposed to do.
Unix philosophy made software that has been "updated" so little compared to all these modern apps.
Coding, because of its changeable nature is the first victim of the humans nature unsatisfying.

Modern software industry has so much of techniques and principles (solid, liquid, patterns, testing that that the air is air) and still needs so many developers to work on a project.
I know that you will blame the market needs (you cannot understand the need from the start, you have to do it agile) but i think that this is also a part of a problem .
Old devices evolved at much more slow pace. Radio was radio, and still a radio do its basic functionality the same war (the upgrades were only some memory functionalities like save your beloved frequencies and screen messages).

Although all answers are valid, i still feel, that we have failed. We have failed so much. The dream of being a programmer is to build something, bring you money or satisfaction, and you are bored so you build something completely new.

Man apples been a lot of pressure. I’m either going to acclimate to this high stress environment or burn out. I’ve had to learn to deploy a k8s cluster and manage one in 3 months along side maintaining an app, shipping features and bug maintenance. They treat devs like special ops all in ones. It’s great experience and there are dead periods but the learning potential is a lot.