[BigJeffeRonaldo]

It's a matter of incentives. Business folks don't care about comments unless they have a dev background. Your options are then to focus on the incentives present in the situation, or materially harm your own life and well-being by working extra hours to make up for your management's inability to manage.

[vinceguidry]

I hate this excuse. It seems like every lazy habit of programmers gets pushed onto the "business folks".

Just because business folks don't know how to value certain developer practices doesn't let you off the hook. Just do what you have to do and if it takes longer because you had to learn how to do it, then it takes longer.

Let the business folks tell you when it's taking too long to deliver features.

[BigJeffeRonaldo]

But it does. It depends on the organization, but there are groups where chugging coffee, talking a lot, and pumping out dozens of half-working features by coding like a drunk cowboy will get you promoted and recognized as a team player, while pushing back to take time and do things right will have you reprimanded. Many such cases out there.

[vinceguidry]

My point is that you shouldn't push back. Just do things the way they need to be done, and it takes as long as it takes.

A manager looks at a programmer bringing up something like unit testing as "why the fuck is he asking me about this, it's his job? Obviously because he's asking me it's outside of his professional ken, so that means it's going to take absolutely forever." Out loud he'll just say, "Can you just get the feature done?"

Don't ask, just do it. It takes as long as it takes. If they ask, just say it's not done yet.

[BigJeffeRonaldo]

This generally won't work for straight forward game theoretic reasons. Boss thinks you're slow->boss brings on h1b consultant willing to pump out spaghetti code and toady up to him->you looking for a new job. Organizations get what they ask for

[vinceguidry]

The boss doesn't have to think you're slow. You could... gasp... be good at your job.

[MaulingMonkey]

Being good at your job won't magically make you fast at fixing up other people's spaghetti code. It won't let you ship 3 working features faster than someone else who's also "good" at their job ship 6 mostly broken features. It won't convince your manager that the former is actually getting more work done than the latter, and won't prevent them from thinking the first guy is slow and the second guy is fast.

But for what it's worth, I agree with you in that I'm still on the hook. Either to help educate my manager, or to pick managers who already understand this stuff.

[BigJeffeRonaldo]

I can tell you're upset, Vince, so I'll be the one to end this discussion.

[Johnny555]

In my company, the business folks have no idea what the code looks like or whether or not there are comments.

All they care about is that the code works, and that features can be delivered on time.

That second part "delivered on time" includes maintaining the comments along with the code since it makes the code more readable, and eases future changes. If Management doesn't give you time to write maintainable code (which includes keeping comments in sync with the code), then you may as well start looking for a new job because the technical debt is going to pile up and it's going to get harder and harder to meet deadlines.

[emodendroket]

They don't care about comments, per se, but they probably care about whether someone else can easily work on the code. I'd think (hope) most technical managers are going to encourage some sort of team review of the code and not get all the way into the weeds about what specific issues in the code review need attention.