4 ms·
Between sabotage and people wanting to sink the lifeboat, I have a third option: These people have a warped perception of what's happening and priorities aroun
by stakhanov 7y ago
Between sabotage and people wanting to sink the lifeboat, I have a third option: These people have a warped perception of what's happening and priorities around what's happening. Warped by their own irrational beliefs which have come about as a result of cognitive dissonance reduction. Initially, they can see how messy & bad things are but since they, themselves, are responsible for things having gotten to that point, they start bending their own beliefs in a way that will make themselves and their past actions look good. In the final phase of this psychological process, some kind of Stockholm syndrome kicks in in relation to the poor standard of engineering that is making their lives miserable: They start to actively seek out poor engineering because it's the only mode of existence that their psyche will allow them to fathom.
Warstory time.
A tech company I worked at was being encumbered by a codebase with poor code quality. Bugs were being introduced all the time, with no chance of preventing it because nothing is testable/tested. Bugs were introduced at a faster rate than they were fixed. The whole system was a timebomb because it was built in a dying ecosystem. For certain kinds of code changes, their effect couldn't even be made visible at development-time at all. You had to release them into the production system and look at metrics to see their effect, hoping that nothing would blow up, so the system was layers and layers of code that was trying to be minimally-invasive with respect to existing code.
Whenever an engineer would be newly hired, they would, within their first week of working there, suggest "Let's take a month to refactor this/that part of the system". When an oldtimer would hear the new guy say "refactor", their warped perception would hear "accomplish nothing" or "threaten our mode of existence". They would give the following speech: "Hey, get it in your head, noob: We don't do that here. This company is not focused on code quality, it's focused on a mission. Every week we come to work and we accomplish a part of a mission. I KNOW the code is probably the worst piece of shit you've ever seen in your 20 years. [This company only hires extremely experienced people]. The engineers who work here are all on board with our mission-driven culture and pride themselves about their skill at dealing with the shitty codebase. Your suggestion tells me that you can't deal with it, and you are unwilling to absorb our mission-focused culture. You will not get a career out of working here, unless you properly absorb that element of our culture".
So, in their mind, they'd taken "shitty codebase" which is a negative, and turned it around and made it into a religion about a "mission-driven" culture which is a positive. [Cognitive dissonance reduction at work, right there]. The reality was, of course, the poor code quality was a huge drag on this company's ability to accomplish a mission of any kind: Because changes that took their competitors a day, took them a week. Changes that their competitors did in a month, would have been a suicide mission for them and they therefore rationalized their way out of even wanting to do them. ...but I wouldn't recommend to the newly hired engineer in the story to mention that particular elephant that was in the room.
Now, here comes the really sick part, where the picture of the drowning man falls apart: From time to time, due to a rare alignment of circumstances, this company might be forced into a situation of starting an implementation of a new element of the system with a clean slate, i.e. completely unencumbered by the current codebase. They would intentionally implement the new codebase to be just as shitty as the legacy code. They would implement it in the dying ecosystem. They would generously insert unreachable code. They would pursue the fastest path towards making it untestable.
Now, under normal circumstances, if I hear someone telling that story, I would suppose there might be a motive for this. For example, I've seen developers in hedge funds intentionally rig a system to explode if they should ever be forced out of the company and be as hard as possible for anyone else to fix, for obvious reasons having to do with their incentivization structure. But that's not what was happening here. They had a culture of openly sharing knowledge of the system, were hiring new people all the time, and working hard to bring them up to speed about the system's working etc, so it wasn't that.
My guess is that it must be the "Stockholm syndrome" element I mentioned: They started to develop a psychological attachment to a poor standard of engineering. It was making their lives miserable. But it was also the only existence they knew and they felt was available to them, so cognitive-dissonance reduction was maneuvering their psyches into actually favoring that mode of existence.
Some might have said things like: "One day, after we've grown enough, we will do a complete rewrite." Or "Any day now, we might be acquired by another company and will leave all of this behind". But it was more in the vein as when a religious persons speaks of a glorious afterlife.
There is a lot of really sick shit that the human psyche is capable of, and sometimes it surfaces in engineering. I think that's my takeaway from all this.
- palisade 7y agoI have so many war stories there's not enough space on HN to contain them. I'll just state my overall experience. I write elegant well designed code, but generally speaking you won't find that anywhere especially if you're working in teams. Unless the code is all written by one person who had a chance to design and implement it well solely by themselves with adequate time, it's going to be a mishmash of they just didn't have time and the pressure was on. I'm of the mindset that if it works, it's good code regardless if it isn't. This I think is the healthiest mindset to have in any team. I will refactor things slowly to clean up issues and of course my own code is well thought out and integrated into the codebase regardless how reckless anyone else is being. Any other way of interacting with a team would be antisocial and not beneficial ultimately. The way I see it is they wouldn't be paying me if there wasn't more work to do. The most important thing is that it works and the customer is happy. Your disappointment with elegance or coverage comes second to that. The thing that actually annoys me is when, having exceeded my own delivery deadlines and everyone else's if I provide value added like a new feature that puts us far ahead of our competition I get pushback. Management doesn't want to have to maintain it. Even though my code is really solid compared to the rest of the garbage going in there. They just see me as a plumber fixing a leaky pipe and don't want anything further. I get that there's ROI and whatnot but it still bothers me when I show them some next level shit and I'm told to mothball it. Especially when I'm the reason we're usually way ahead of schedule. </rant>
- stakhanov 7y agoI've had that same thing happen to me numerous times too. I wrote code that demonstrably and undisputedly added to the value of the product in a way that went far beyond anybody's expectation. I took no longer to do it than it would have taken to do it the "normal" way. People get mad at me making the argument "Well if you leave the company, somebody else is going to have to understand your next-level shit, and we just simply don't have people here who can do that. So then what?"
- Discombulator 7y agoI think it depends on the details. If your code is simply cleaner, well documented etc, then fully agreed. If you introduce new dependencies, or the latest free monad transforming framework when there was none, then I’d be wary as well.