[jrochkind1]

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.

[Pica_soO]

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.

[noxToken]

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?

[crdoconnor]

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.

[jrochkind1]

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).

[justin_oaks]

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.

[s73v3r_]

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

[ConceptJunkie]

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.