Yes, it's been happening more and more over the past decade. 10 years ago, code was on average relatively clean and easy to understand. Concepts like 'high cohesion, loose coupling' were drilled into us. Nowadays, developers barely know what these terms mean. Most developers don't seem to take pride in their work anymore. Seemingly, they're trying to maximize their lock-in factor via complexity. Probably most do it subconsciously, but the effect is so strong and it has gotten so much worse over time that it feels intentional. Like people have been conditioned to add as much complexity as possible. Coding has become mostly unpleasant nowadays because of this.
Most experienced developers know that unnecessary complexity is the absolute worst enemy. You literally cannot overstate the harms of unnecessary complexity... It is absolutely and inherently harmful. But to the junior or mid-level developer, complexity is a sign of intelligence; that, along with the ability to churn out thousands of lines of code per day.
On my own projects, I never allow this complexity, but when you're working for a company, they don't like it if you point out that there is a complexity issue. They'll think that maybe you're just not smart enough and are jealous of or trying to demoralize the 'genius junior dev' who is churning out 2k lines per day! Truly Kafkaesque situation.
I honestly didn't know what to do in my last job. I was doing a lot of PR reviews but I just let the 'most productive' junior dev continue adding complexity because that was what the founder wanted me to do. Every time I tried to talk about reducing complexity, I would get brushed off, so I just stopped trying.
It's quite a ridiculous situation actually. Because all the code I write is high quality; highly maintainable, everyone is able to easily add features and make changes to it, but when I work on other people's ugly, over-engineered code, it's a struggle.
So from the outside, it looks like I'm slow when working with other people's code, and it looks like other developers are fast and adaptable since they can easily work with my code... So basically I look like I'm the one who is a low performer.
The winning strategy is clearly to write over-engineered code, then try to socially engineer the situation so that you only end up working on your own code or other people's high quality maintainable code (if there is such a thing at your company because people who produce such code tend to get laid off)... While at the same time, you need to try to ensnare your colleagues to work on your complex code so that they end up looking unproductive relative to you... Because huge amount of code + visible features is how directors decide on promotions and layoffs... It's always about picking low hanging fruits, sprinkling sugar on top and then personally delivering it to the boss on a silver platter; easy and visible.
Much of software engineering nowadays is social engineering; ensuring that you are only assigned to decent quality maintainable and highly visible projects, always hitchhiking on top of the work produced by good developers and dumping your own low-quality output on others to entrap them. Sigh... Then after some time, these big companies end up with ridiculously low productivity expectations... Which is great for social-scheming low performers who are used to this game of racing to the bottom.
Also, people like me who can see what's going on are never promoted to positions where I can have the last say on such things. It feels like the entire tech economy is just a massive bullshit jobs factory at this stage. All about pretending to be highly productive while in fact being counter-productive.
> 10 years ago, code was on average relatively clean and easy to understand
We have very different memories of 10 years ago. I just remember peak OOP cargo culting with 10 layers of inheritance and searching `Factory` would OOM your IDE.
Given the rest was reasonable I was willing to grant that as "aims for high quality".
Because it wasn't about how good of a programmer they are, it was about their intentions and principles. "I try" vs "I don't try" already makes the significant relative difference regardless what the absolute values are.
Most experienced developers know that unnecessary complexity is the absolute worst enemy. You literally cannot overstate the harms of unnecessary complexity... It is absolutely and inherently harmful. But to the junior or mid-level developer, complexity is a sign of intelligence; that, along with the ability to churn out thousands of lines of code per day.
On my own projects, I never allow this complexity, but when you're working for a company, they don't like it if you point out that there is a complexity issue. They'll think that maybe you're just not smart enough and are jealous of or trying to demoralize the 'genius junior dev' who is churning out 2k lines per day! Truly Kafkaesque situation.
I honestly didn't know what to do in my last job. I was doing a lot of PR reviews but I just let the 'most productive' junior dev continue adding complexity because that was what the founder wanted me to do. Every time I tried to talk about reducing complexity, I would get brushed off, so I just stopped trying.
It's quite a ridiculous situation actually. Because all the code I write is high quality; highly maintainable, everyone is able to easily add features and make changes to it, but when I work on other people's ugly, over-engineered code, it's a struggle.
So from the outside, it looks like I'm slow when working with other people's code, and it looks like other developers are fast and adaptable since they can easily work with my code... So basically I look like I'm the one who is a low performer.
The winning strategy is clearly to write over-engineered code, then try to socially engineer the situation so that you only end up working on your own code or other people's high quality maintainable code (if there is such a thing at your company because people who produce such code tend to get laid off)... While at the same time, you need to try to ensnare your colleagues to work on your complex code so that they end up looking unproductive relative to you... Because huge amount of code + visible features is how directors decide on promotions and layoffs... It's always about picking low hanging fruits, sprinkling sugar on top and then personally delivering it to the boss on a silver platter; easy and visible.
Much of software engineering nowadays is social engineering; ensuring that you are only assigned to decent quality maintainable and highly visible projects, always hitchhiking on top of the work produced by good developers and dumping your own low-quality output on others to entrap them. Sigh... Then after some time, these big companies end up with ridiculously low productivity expectations... Which is great for social-scheming low performers who are used to this game of racing to the bottom.
Also, people like me who can see what's going on are never promoted to positions where I can have the last say on such things. It feels like the entire tech economy is just a massive bullshit jobs factory at this stage. All about pretending to be highly productive while in fact being counter-productive.