Live data from Hacker News

Maintaining code quality when nobody cares

mkdev.me

1–10 of 245 posts

Re: Maintaining code quality when nobody cares

#2
Some things I've learned about code quality in organizations where the quality is terrible:

1. The problem starts with culture. These organizations are run top-down by people who don't understand coding. Sometimes they are ex-engineers, but that's usually about as good as non-engineer.

2. These organizations are systemically incapable of determining good work from bad. Who on the team is performing and who isn't? They can't tell. They will usually default to seniority (meaning how long a developer has been with an org, not how good they are).

3. These organizations reward fires that are put out. They do not reward fires that were prevented from happening in the first place. Those "senior" developers will frequently be rewarded for putting out fires they caused.

4. If you do a lot of work that prevents fires and that means you weren't working on features or bugfixes, you are going to get punished, not rewarded because to the people above you it looked like you were doing nothing.

5. If you're going to do this kind of work, you need serious intrinsic motivation.

Re: Maintaining code quality when nobody cares

#4
In many companies I worked that were like this, other developers also wanted to fix these problems. So, talking with them is also a good start I would say, if you get get one more colleague to work kind of right from beginning is a nice start too. Normally, QAs and test automation engineers will be all for improve the situation. Being a bit more vocal on these problems, but it is important to choose what should be the 1st problem to be tackled.

Re: Maintaining code quality when nobody cares

#5
Code quality depends on you. If you are maintaining the system then for your own sanity, clean it where you can. If you are writing the system for someone else to maintain, clean it where you can, because you will probably be the poor sod who will have to maintain it later on.

If you can't clean it now, write down everything you know about the system, all those little annoying assumptions that nobody else has documented. Do this for your own sanity.

Don't be afraid to rebuild something if that will get you out of a bind. It will be for your own sanity to do so.

The pragmatics of cleaning up code is for your own sanity, unless you intend to leave in the near future. In that situation, it will be someone else's problem. But remember that in your next job, you'll become the someone else.

Re: Maintaining code quality when nobody cares

#6

Code quality depends on you. If you are maintaining the system then for your own sanity, clean it where you can. If you are writing the system for someone else to maintain, clean it where you can, because you will probably be the poor sod who will have to maintain it later on. If you can't clean it now, write down everything you know about the system, all those little annoying assumptions that nobody else has documen…

If you dont get the time necessary- lie to your clueless superiors- tell the story about the complicated feature, that needs hours more- they will never understand how much a well made library will save them future time, so you are actually helping a clueless fool to do a good decision with that little lie.

Re: Maintaining code quality when nobody cares

#7
post #6

Code quality depends on you. If you are maintaining the system then for your own sanity, clean it where you can. If you are writing the system for someone else to maintain, clean it where you can, because you will probably be the poor sod who will have to maintain it later on. If you can't clean it now, write down everything you know about the system, all those little annoying assumptions that nobody else has documen…

If you dont get the time necessary- lie to your clueless superiors- tell the story about the complicated feature, that needs hours more- they will never understand how much a well made library will save them future time, so you are actually helping a clueless fool to do a good decision with that little lie.

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

Re: Maintaining code quality when nobody cares

#8
post #6

Code quality depends on you. If you are maintaining the system then for your own sanity, clean it where you can. If you are writing the system for someone else to maintain, clean it where you can, because you will probably be the poor sod who will have to maintain it later on. If you can't clean it now, write down everything you know about the system, all those little annoying assumptions that nobody else has documen…

If you dont get the time necessary- lie to your clueless superiors- tell the story about the complicated feature, that needs hours more- they will never understand how much a well made library will save them future time, so you are actually helping a clueless fool to do a good decision with that little lie.

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.

Re: Maintaining code quality when nobody cares

#9
post #7
post #6

Earlier quoted context omitted.

If you dont get the time necessary- lie to your clueless superiors- tell the story about the complicated feature, that needs hours more- they will never understand how much a well made library will save them future time, so you are actually helping a clueless fool to do a good decision with that little lie.

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

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.
Post reply on HN