"Quiet quitting", as you so aptly did not wish to call it, does not exist in a vacuum; it is a response to unheard, unaddressed critiques from the people who actually do the work, and likely the only avenue those workers have left to 'voice' those critiques. I think anyone who has worked in a large org, especially hot on the heels of laying off so-called 'high performing' employees, should be able to empathize with the message.
You don't get it. You are entitled to nothing more than it says in the contract. There are ways to get more performance out of people but you have to decide if you need it and have to chose to do it. We can struggle and share the victory over a deadline or you can have those dumb shits put in some overtime and hope you will make it. You get to be whoever you want to be.
> You don't get it. You are entitled to nothing more than it says in the contract.
People have lost their sense of duty and responsibility to act civilized. Example: You have a meeting at 11:00. You wake up at 10:59 and don't want to turn your camera on or turn it on while lying on your bed. Don't prepare well for the meeting, didn't check, i.e., the scrum board, don't remember what you did yesterday, etc... I've been hiring developers since 2005. I still work as a developer. I played different roles as CTO, Product Manager, Team manager, etc... It's getting hard to get developers under 30 that can act as an adult. You cannot write everything in the contract, even though responsibility, organization skills, etc., are requirements for every job, and it is, in one way or another, written down in the contract that we all sign when accepting a job.
If I were to be in an environment where there are multiple developers who can understand even the basic mathematics of geometry and linear algebra too do what I do (that's a tall order. It hasn't happened once in 20 years that I've worked in a company that has had even one other developer that knew anything beyond basic algebra), why would they spend their time telling me how to do my job, rather than just doing their job? If I got something wrong in my code, A) how did the process guarantee that it will be caught? B) why wouldn't whoever found the problem just fix it?
It's kind how my children argue over basic things like bedtime. They insist it's only "fair" if one of them turns off the light and the other closes the door. And if the light is already off when they enter the room, then the door closer is going to get pissy and turn the light on to make his brother get up out of bed and turn it off.
It's a meaningless exercise developed to give the illusion of control.
I struggle to believe that your coworkers don't understand the basics of LinAlg and geometry. It seems much more likely that you write code which is hard to parse, can't be explained, and your concept of maintenance is rewriting it from scratch because you don't understand it a year later either.
Writing code that other people understand is an independent skill from solving the particular problem at hand. If your colleagues don't understand your code, either you need different colleagues, or you can't write understandable code.
>> Writing code that other people understand is an independent skill
> It's also the main skill of a developer. Code is for people.
If there are any people reading this starting out in their career, i can't stress how important this is. Being able to write beautiful code and being able to explain it to your peers and see them take off with it and do amazing things is the single most important skill as a software engineer IMO. I would put it above any algorithm riddle, esoteric language feature, tool expertise, or anything else.
Why would you expect for code review to catch all errors? That's a false dichotomy. Code review is expected to catch some errors.
Why code reviewer wouldn't fix errors himself? Well, that's an interesting question for sure. One reason, I guess, is that it current way encourages people to avoid doing mistakes over and over again. If code reviewer would have to fix error himself, that would not encourage person writing the code to avoid issues in the future and that would discourage person doing code review to find any issues. But, I guess, in a very trusted environment that definitely could work.
> If I got something wrong in my code, A) how did the process guarantee that it will be caught? B) why wouldn't whoever found the problem just fix it?
well.. fair point. Code review guarantees nothing, if there is an issue found there's going to be delay to fix it as it rolls back through the process. I hate "process" as much as anyone else but I learned during COVID its importance. I implemented a vaccine system for a state government with a team starting at 3 and growing to over 100 in about 8 weeks. It was the hardest thing i ever did and "process" saved my ass and kept CNN off my front lawn a few times. It also was a real thorn in my side when i needed to get things done. Process vs getting-shit-done is a balance and it's rarely perfect.
