Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maintaining code quality when nobody cares

mkdev.me

Post reply on HN
Print view View original

21–30 of 245 posts

Re: Maintaining code quality when nobody cares

#21

Post by jrochkind1 »

Pica_soO wrote: post #6
oldandtired wrote: post #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 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.

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.

Re: Maintaining code quality when nobody cares

#22

Post by jimmy1 »

jacquesm wrote: post #15
pgsandstrom wrote: post #13

> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old. Is it just me, or is less that four years not "really old"?

The number of years a piece of software has been alive is not always a good indicator of how old it is. It can be 2 years old and in outright legacy territory. Some people are working hard to replace one legacy project with another. Software does not age well when it isn't constructed properly.

In my opinion, when speaking of "legacy software", we should place a stronger emphasis on the actual meaning of the world legacy rather than the usual pejorative. Meaning that: this software has created a "legacy", in some form or fashion. Whether that legacy was it was used in the past to build the business, it paved the way for some standard or better practice, or it simply outlived it's time.

Downvotes are usually reserved for when a comment is low quality or not relevant to the conversation at hand. Could you please explain if my comment fit into these categories for my own learning? Thank you.

Re: Maintaining code quality when nobody cares

#23

Post by pjmlp »

carlmr wrote: post #18
crdoconnor wrote: post #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? The…

So what is the prescription to find a company that doesn't check these 5 boxes?

Start your own.

Re: Maintaining code quality when nobody cares

#24

Post by mathgeek »

crdoconnor wrote: post #20
dep_b wrote: post #14

You need to get the programmers together and agree on a coding guideline, a linter and other architectural fundamentals. Then the gardening phase begins, which means no refactoring or warning or style fixes unless you touch the code to do something meaningful like a feature or bug fix. Leave everything you touch better than before. Dissolve big classes and functions into smaller ones. Write a test or two for the smal…

IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor). The reason people like to default to linting when "fixing code quality issues" is purely because it's 100% objective and measurable, not because it picks up the truly important issues. It doesn't. Edit: I am aware that coders have OCD impulses which can be sated with a linter, b…

Most linters allow you to disable whitespace linting. Good tools allow you to learn to use them better.

Re: Maintaining code quality when nobody cares

#25

Post by DanielBMarkham »

majewsky wrote: post #7
Pica_soO wrote: 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).

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.

Re: Maintaining code quality when nobody cares

#26

Post by crdoconnor »

carlmr wrote: post #18
crdoconnor wrote: post #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? The…

So what is the prescription to find a company that doesn't check these 5 boxes?

In general the companies that don't both A) pay better and B) are located in tech hubs / do remote work. So, go for more money, prefer remote or in a tech hub.

You can also ask during interview about the coding experience of the manager you will report to. Usually they are up front about it. If you turn them down, do us all a favour and let the company know that was why (more coding managers and fewer MBAs please!).

I'm not gonna lie, it's not going to be possible for everybody to avoid this kind of company, especially in the more backwater places. I left Singapore because I basically found one company that didn't obviously follow that pattern. They frustrated me too for other reasons so I didn't take their offer.

I think that this is one of the most underrated reasons for the formation of technology hubs and one reason why Singapore, in spite of really trying to become a "silicon valley of asia" (VC money: check, money pumped into education: check, huge startup grants: check) just won't, and will bleed rather than attract talent.

Re: Maintaining code quality when nobody cares

#27

Post by simonpantzare »

crdoconnor wrote: post #20
dep_b wrote: post #14

You need to get the programmers together and agree on a coding guideline, a linter and other architectural fundamentals. Then the gardening phase begins, which means no refactoring or warning or style fixes unless you touch the code to do something meaningful like a feature or bug fix. Leave everything you touch better than before. Dissolve big classes and functions into smaller ones. Write a test or two for the smal…

IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor). The reason people like to default to linting when "fixing code quality issues" is purely because it's 100% objective and measurable, not because it picks up the truly important issues. It doesn't. Edit: I am aware that coders have OCD impulses which can be sated with a linter, b…

I'd argue that there's a significant mental overhead reading code when it doesn't follow the same conventions, and that enforcing a style guide is a matter of having no broken windows. But of course there's no point trying to make shit look good.

Re: Maintaining code quality when nobody cares

#28

Post by lloeki »

crdoconnor wrote: post #20
dep_b wrote: post #14

You need to get the programmers together and agree on a coding guideline, a linter and other architectural fundamentals. Then the gardening phase begins, which means no refactoring or warning or style fixes unless you touch the code to do something meaningful like a feature or bug fix. Leave everything you touch better than before. Dissolve big classes and functions into smaller ones. Write a test or two for the smal…

IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor). The reason people like to default to linting when "fixing code quality issues" is purely because it's 100% objective and measurable, not because it picks up the truly important issues. It doesn't. Edit: I am aware that coders have OCD impulses which can be sated with a linter, b…

We did that (rubocop). Lots of fluff, a dozen or three minor to medium issues, and a couple of downright critical ones that slipped through production cracks out of sheer luck. Not even counting the last ones, the holistic effect of having a code base normalized is unmeasurable (i.e == through the roof), because suddenly moving from one part of the code to another is consistent enough that it removes a mental barrier to seeing patterns and enabling refactoring.

Re: Maintaining code quality when nobody cares

#29

Post by sesutton »

pgsandstrom wrote: post #13

> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old. Is it just me, or is less that four years not "really old"?

I suppose it is for webdev. I regularly work on C code that's nearly as old as I am.

Re: Maintaining code quality when nobody cares

#30

Post by dep_b »

simonpantzare wrote: post #27
crdoconnor wrote: post #20

Earlier quoted context omitted.

IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor). The reason people like to default to linting when "fixing code quality issues" is purely because it's 100% objective and measurable, not because it picks up the truly important issues. It doesn't. Edit: I am aware that coders have OCD impulses which can be sated with a linter, b…

I'd argue that there's a significant mental overhead reading code when it doesn't follow the same conventions, and that enforcing a style guide is a matter of having no broken windows. But of course there's no point trying to make shit look good.

A linter and code conventions are a way to make code more consistent and easier to switch between. At times it becomes hard to see what code you wrote and what somebody else wrote, which is a good thing. If I open a file and everything "just feels wrong" but I can't change it because enforcing my personal preferences are just my personal preferences is just making things worse that really takes some valuable energy away I could use for actually improving things. But I can get used to a coding guideline that's not 100% my preference but a well enforced and consistent one. Knowing that if I fix indenting and naming the fix will not enrage someone else.
Post reply on HN