The problem here is that you're making the organizational culture _worse_ while you make the code better. And it's organizational dysfunction that led to your situation in the first place.

It's a dysfunctional organization that doesn't let you write quality code without lying (assuming you are correct that this is ultimately counter-productive for the organization's goals), and most every dysfunctional organization I've seen is characterized by lack of transparency and truth internally -- nobody knows what's really going on, so there's nothing to do but political games. I think that lack of internal honesty is a cause, not just a symptom. So your workaround to let you do quality work despite being in a dysfunctional organization, misleading your peers and/or managers/administrators, makes the organization's dysfunction even worse, making it even harder to do quality work. In another kind of vicious cycle.

After a bunch of years of programming professionally, I've come to the conclusion that my job includes not just trying to make the code better, but trying to make the organization better too. The same way you've got to 'fight' for quality code, you've got to 'fight' for healthy (honest and respectful) organizational culture.

There are some (many) places that are so dysfunctional that they seem hopeless, and maybe you can't easily leave and find other employment. You've got to do what you've got to do to stay sane (and keep your mind from dying) and I don't fault people for their coping strategies in such an organization, but I think misleading/lying (which is really just a kind of 'political' game of it's own) to give you space for code quality is likely to lead into a vicious cycle of descending badness all around, not ultimately leading to increased job satisfaction.

Your definition of fighting for a better organisation, boils down to replace people who are apt at nothing but political games with people who are apt with engineering knowledge.

You cant do that, unless you have a little island of sanity at the top, giving you a lifeline and air-support. Sorry, i for once m not good at office version of the game of thrones.

So what's the alternative to lying for what you hope is the greater good?

This is the advice that I give my colleagues who, after exhausting all other methods, try to squash technical debt before a 1 hour task becomes a 5 hour task. Leaving the job doesn't solve the problem (though it may save your sanity). In fact it might make it worse, because the leaving person is likely taking tacit knowledge with them.

I'm not saying that lying is preferred, but what else can one do?

You need to flip the script on the problem. It's no longer a technical problem, it's a management problem.

Management problems are solved with spreadsheets that show concrete numbers going up or down.

At the beginning of each sprint ask the manager what % of time developers should spend fixing quality issues on each story after the story is complete. 0%? 30%? 50%? Track it. Graph it.

At the end of the sprint ask developers "how do you feel about the quality of the code base this sprint? [ 0 dangerously unstable --- 100 - clean and perfect ]. Track it and graph it.

Track what % of stories in the sprint are "code quality" stories (e.g. upgrade node). Create a graph showing four consecutive sprints with 0% time allocated to code quality stories.

After about 4 sprints of this, provided you were reasonably open and transparent about what you were doing, you'll probably have a slightly freaked out product manager who is newly cognizant of the need to properly allocate time to "quality".

If it turns out he's an idiot who ignored your little game, well, you've amassed documentation necessary to make his bosses start considering his termination and replacement.

Don't fuck around with this stuff though - you can invite all sorts of problems if you're not careful with this approach. Assume everybody is honest and has good intent until proven otherwise.

I have not completely figured out what to do, but I'll say that if you leave because the organization is not interested in producing quality code and you don't want to work for such an organization, and they were unwilling to give you time (ie money) to produce quality and maintainable code -- the problems they have maintaining the code after you leave, having made efforts to educate/convince them of this fact and failing, _are not your fault_ and _not your problem_.

The tacit knowledge you take with you, when they were not willing to give you enough time to share/document this knowledge, or produce code that was more transparent, despite your efforts to tell them the consequences -- are _not_ your problem. Don't get Stockholm syndrome.

I realized at one job that I kept busting my ass to cover up for management failures (that I wouldn't get credit for saving them from)... they would NEVER LEARN. I was enabling terrible management and a toxic environment. They didn't even _realize_ I was saving them from themselves (and if I'm wrong and they were right and I wasn't, all the more fine it was for me to leave).

I just left a job where I knew that management would never learn. That was my primary reason for leaving. All other problems could have been fixed IF they would listen to the employees and/or learn from their own mistakes.

Alas, it was not meant to be. I feel like I was an enabler because there were a lot of things that I held together despite not receiving any support from management.

If the organization doesn't care about code quality, then they don't deserve talented engineers with domain knowledge.

You're absolutely right, and my immediate bosses have dedicated themselves to laying down the law that good work requires more time. We live in a culture where there is a lot of technical debt inherited from a culture that used to be much worse than it is now, and I think we've made some progress on the front of not increasing the technical debt, by insisting on the resources to do things right. Now, reducing the technical debt is another matter.

I don't know why this comment is in gray. I have been repeatedly pressured to "make it run on GPUs" and needed to spin some fiction to buy time.

In the end, if your superior tries to micromanage but doesn't understand the details, then a lie woven from bits of truth, if it helps achieve a goal, is morally indistinguishable from the whole raw truth.

It's sad that this gets downvoted, because it's the only realistic approach in such a situation (which is also sad).

I've seen a lot of teams in a lot of organizations, both bad and good.

Good teams cheat in bad organizations. That's why they're good teams. Whatever your metric, code quality, quality of life, being kind and supportive -- in organizations that pervasively do it bad, good teams cheat in order to do it well.

I think the trick is that only a small group of people know that they cheat, otherwise some mid-level manager would come down on them, hard.

Yes, I don't see this a problem, normally releases get delayed, if you get more time to develop better, then why not? I always saw testers talking with product owners and managers about one or other developer that was slower but had delivered less defect.

I know that feeling. I'm one of those developers that is slower than a lot, but I also know from long experience that when I deliver something, it's solid. It's not that I don't make mistakes, but that I work in a way that helps to minimize them when I do make them. It takes me longer to get things done than the hotshots, but there will usually be fewer problems and the problems that do exist will usually be much shallower. And unlike a lot of people my work contributes to a net decrease of technical debt.

I'm not saying this to brag, but to emphasize that this is what it takes to do quality work.

The downside to this approach is people. You risk other (well meaning or otherwise) developers trying to help fix your misunderstanding or telling your supervisor that you need help. Others may need to be in on it and sometimes that sort of environment breeds cut-throat behavior. If the business has the power to dictate unreasonable requirements people that break ranks to tell them what they want to hear can gain a political advantage.

People have different situations in life and the range of options that you have as an employee can vary pretty dramatically. However, here's how I tend to cope with these situations (in order of preference):

1. If I don't get the time to do what I think is necessary, then I lobby to make sure that it's my decision about how much time it takes. You're not going to get handed this on a silver platter, but the main argument is that as a developer you are making a good salary. The person paying that salary should get the best value from that money. If you have to do your job in handcuffs, you're not going to be able to give the best value.

2. If I'm not in a political situation to do #1 (and you should probably try to make sure you are before you actually stick your neck out), then I will note the constraints I have to work under. Making a project succeed when everything goes exactly as you want it to is relatively easy (well, TBH, I think it's never actually easy, but you get my point). What makes a great developer is making the project succeed even when you don't have everything your own way. So find a way to succeed with the constraints that you have. If you fail, make sure to make it obvious which constraints are causing the most problems. Usually after you fail you can get some extra leeway on those issues. Work on the issues one at a time, most important first. Eventually you can usually promote yourself to option #1.

3. If I can't do #1 and there is some reason why #2 fails (and I can't fix it), then I will go elsewhere. No point in sticking around in a place where you can't succeed. Wish everybody great luck. Express remorse that you couldn't get the kind of success that everybody wanted. Thank people for the opportunities that you had.

4. If I can't go because I have no other job, or I need to stay because my visa says so, or my spouse will go crazy from stress if I switch jobs, or a million other possible reasons... I'll keep working and keep studying exactly what's causing the problems. It's easy to conclude, "Joe is breaking everything. I hate Joe" (I only picked the name Joe because to the best of my recollection, I've never worked with someone named Joe). But you're stuck and you might as well learn about the situation in more detail. Wait and watch. I hate waiting. Man, do I hate waiting. But eventually it will pay off. Opportunities are out there. Your job is to recognise them.

That's it. Don't lie. You'll only get found out and then make your job a hundred times harder. Don't get dragged into petty politics. The job is hard enough without drama. Play it straight and give everyone the best chance they have to understand what you are doing and cooperate with you. Don't undermine people. Just do your best. It's not always easy sailing, but learn how to navigate rough waters and you'll be fine.

It's not even lying: the cycle is red-green-refactor, not red-green-done. Knowing when to extract functionality (and when to inline functionality) is part of our job, not a management concern.

I think we tend to forget this because we so often muddy management and technical work, but management's job is to tell you what to build. You are the professional and it is your job to know how best to build it.