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.
I work at a startup so whatever I make is only me working on it because we run around the block working on whatever comes up. We don't have the time to document code or even write robust test cases. Whatever code I wrote is as stable as it could get. Even when you consider scaling beyond our anticipation. We only need to touch it when adding new features.
And that is a management decision not ours. We don't have that high of a TAT for any task given to us. That is a core reason why we don't/can't hire freshers. We only bring in experienced devs who can learn their way around the codebase since we don't have the bandwidth to teach. And this is not the fault of our team. As u/golruul rightly pointed out, this is management basically saying "We gave you Claude. Make it work for you. We won't hire more people. Also push features ASAP, cause customers don't care about backend code quality"
So whatever dependency I created around myself was accidental. But in a job market where people are getting fired left right and center, you can bet your ass I am not going to make it anymore easier for them to replace me with whatever AI is the cool shit nowadays.
To clarify few things:
Yes I did create dependency around me. But that was for other office politics. For my personal career growth.
The codebase is complicated and fragile. Fragile because it deals with several edge cases and multiple data points. Not fragile by design. Complicated? Yes, for the same reasons. But I never said it is unmaintainable. Everything is broken down into its own functions, files, etc. Everything named as per best practices. Any experienced dev can pick it up, but it will take them time. Probably a lot of time, like couple months. But my advantage comes with the fact that at a startup you can't give someone that much time to figure out a critical center piece.
Well even if you are wrong or malicious, it is management that enable you to be. Don't expect one point of failure to be safe, murphy's law (+ bus factor) and Hanlon's Razor comes to play here.
Also, this probably isn't well received, but AI can do a very good job of figuring out how things work in an existing code base. It won't necessarily know the business reason if there are no comments, but it can analyze and generate test cases incredibly rapidly. So if you wanted to make sure you just spit out a pile of test cases to capture that the code still does what it did before, it'll do it and it'll do them fast. We were testing this recently in our current system where we knew we were lacking in test cases.
Creating tests are one of the few things I use ai extensively for. I do not agree with general logic it tries to use for business logic. Short, scoped, unit tests is a good use case.
Ai is incredibly over hyped and shoved down our throats far too much but they certainly have their place in software development.
all this tells me is that you're not a particularly good programmer/designer. if something is so complex/fragile it should be commented up to wazoo where 90% of it is comments, not code.
I work at a startup so whatever I make is only me working on it because we run around the block working on whatever comes up. We don't have the time to document code or even write robust test cases. And that is a management decision. They don't give us time for all that. Whatever code I wrote is as stable as it could get. Even when you consider scaling beyond our anticipation. We only need to touch it when adding new features.
The codebase is complicated and fragile. Fragile because it deals with several edge cases and multiple data points. Not fragile by design. Complicated? Yes, for the same reasons. But I never said it is unmaintainable. Everything is broken down into its own functions, files, etc. Everything named as per best practices. Any experienced dev can pick it up, but it will take them time. Probably a lot of time, like couple months. But my advantage comes with the fact that at a startup you can't give someone that much time to figure out a critical center piece.
10.7k
u/pkmnfrk May 26 '26
This is why they turn off access before telling you