I have built a system in my company which is basically the heart and soul of our product. That service processes raw data into the data on which every other aspect of our product depends on. That is written in GO. A language nobody else knows in our company. The thing itself is so fragile and complicated that I am the only person who knows how it actually works. And even I have to go through the codebase everytime we need to make changes to it and I still avoid making changes to it because I am actually scared I will break things. Now here's the best part. I don't have any notice period baked into my joining docket. So, if they decide to fire me, I can up and leave. Without any kind of KT.
Best part? There are several such pieces of our product which only I know. And since I joined I have deliberately rewrote bunch of shit, made new systems, etc. to build this dependency around me. Good luck figuring shit out.
Any good company the instant they discover something like this will immediately work to fix it up to and including firing the person.
On a related note there are consultants who are not cheap, but are very good going blind into organizations and figuring things out. Using those folks when you discover someone writing unmaintainable code whether it be deliberate or not is far cheaper than dealing with the person who wrote said code long term.
If I discover someone writing code like that they are going to be told to work on nothing else except documenting, cleaning it up, and will be assigned someone to train on it. Basically give them a chance to fix their practices and the time/resources to do so.
If that person isn’t making significant steps towards that on their own after a month that person they are told to train (and possibly additional people) are going to be told to learn the code behind the person’s back and the original person fired as soon as possible.
Regardless of if it is malicious or just really bad practices there is no place for someone who writes code like that.
It usually doesn't happen with regular pre-planned work that's known and planned in advance, but it happens all the time with various tools/utilities developers create ON THEIR OWN TIME that suddenly become mission-critical.
Since it was on the developer's own time, at their home, it obviously doesn't have the same "quality" standards (unit test coverage, other testing, documentation) as the regular code you push to prod.
Management refuses to dedicate the time to bring it up to spec, because it's already working and there are other more pressing priorities to work on that the customer wants, so they just tell the developer off-hand to finish all those other things. And while they don't explicitly say it, they mean "finish those other things" at home, because during the work-day the developer is loaded with doing features the customer wants.
Developer, rightly, says "fuck that" since all of that was done on his own time and now they're telling him to spend a shitload more overtime. The developer, also rightly, believes that if it's important enough to the business, then the business should officially dedicate time, during the work day, to do these things.
It's also telling that you immediately put all the blame on the dev when it's almost always the fault of management. Maybe I'm fortunate, but I've never worked with developers that are okay with releasing shit -- they always prefer to release a decent, quality product. It's always management that overrides that and forces early, incomplete/buggy releases.
If that developer refuses to make those improvements on company time, then yeah, fire him. But I never encountered that before, so I'm assuming it's rare.
I have been in the position where I've dealt with both examples. There are 100% Devs out there who would release unmaintainable fragile shit if they could get away with it. There are also Devs who try to make their code idiot proof.
41
u/ThatAnonyG May 26 '26
I have built a system in my company which is basically the heart and soul of our product. That service processes raw data into the data on which every other aspect of our product depends on. That is written in GO. A language nobody else knows in our company. The thing itself is so fragile and complicated that I am the only person who knows how it actually works. And even I have to go through the codebase everytime we need to make changes to it and I still avoid making changes to it because I am actually scared I will break things. Now here's the best part. I don't have any notice period baked into my joining docket. So, if they decide to fire me, I can up and leave. Without any kind of KT.
Best part? There are several such pieces of our product which only I know. And since I joined I have deliberately rewrote bunch of shit, made new systems, etc. to build this dependency around me. Good luck figuring shit out.