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

191–200 of 245 posts

Re: Maintaining code quality when nobody cares

#191

Post by Floegipoky »

WorkLifeBalance wrote: post #101
aalleavitch wrote: post #47

Earlier quoted context omitted.

This is absolutely the situation I am in right now, and I desperately need all the guidance I can get. We’re talking thousands of lines of React components that rely regularly on manipulating global js variables, mixed with MVC 5 written in Razor delivering variables in script tags, mixed with outdated jQuery, that’s all just concat’d together with gulp and that hasn’t seen a refactor in years of changing hands with…

Personally I thrive in this kind of environment, it's a kind of comfortable chaos. MVC5 is positively modern compared to many of the products I've worked with which have included (within the last 5 years) VB6 winforms but mostly aspx webforms. Understand that previous developers might not know what a DOM is have likely written ad-hoc jquery snippets, included 3 different versions of jquery-ui until they happened acro…

In regards to #5, worth pointing out that some coworkers are probably just as disappointed with the current state of affairs as you. They would probably really appreciate somebody pushing them to hone their craft.

Also worth considering that some people never learned how to handle constructive criticism and will take any suggestions as personal attacks. Stay as far away from these people as possible, you aren't going to change them but their pettiness can make your life miserable, particularly if they're closer to management than you are.

Re: Maintaining code quality when nobody cares

#192

Post by akud »

ManlyBread wrote: post #115

I've tried this approach in the past and and it has made me very bitter. Eventually I realized that the company I worked for enforced no accountability for bad code, so I would often open the solution later and found a pile of ugly hacks or other mess. Code reviews? Refactoring? "We don't have time and no one is going to pay for it". Eventually you come to a conclusion that if no one cares then why should you? If any…

It's not a tradeoff. The reason we like quality code is it saves time in the long run by being clear, easy to change, less error-prone, etc. If you expect to be employed in 6 months, you should be refactoring and putting care into the quality of your code. It's hard at first, but I'm at a point where I'm the most productive engineer and I work the least amount of hours - because my code is there to help me, not hurt me.

Re: Maintaining code quality when nobody cares

#193

Post by Jach »

Clubber wrote: post #179
tmorton wrote: post #103

Earlier quoted context omitted.

I disagree with most of this comment, but I think it's an interesting and valuable discussion. Here's where we agree: You need to stop the erosion in order to fix it. Every developer on the project needs a shared vision of what "better" means. For example, the parent comment mentions React components that manipulate global variables. First of all, everyone agrees to stop doing that, and agrees on the alternative (use…

That's what I've always done. Fix it when you see it. Eventually, you have a clean codebase.

I've mixed feelings on this still. It leads to big code reviews, with most of the changes being less important. So I rather like the separation, spend some time just for cleanup. Maybe take notes on wins as you see them but you don't need to do them yet (or put them in the same review as another bug fix / story item).

If you're using git and can separate things out cleanly then I think fixing it as you go would work better. I yearn to use git every day again...

Re: Maintaining code quality when nobody cares

#195

Post by sanderjd »

nightski wrote: post #166
reaperducer wrote: post #141

Earlier quoted context omitted.

It can be very frustrating, but ultimately it's a reflection on you. Whether you're a coder, or a librarian, or a janitor, take pride in your work. Do the best job you can. If everyone else's code looks like crap, that's on them. When new people come on, they'll see your work compared to the slackers, and start emulating you, not them. Like anything in life: Do the right thing, even when you're surrounded by villains…

A contrary opinion based on experience - instead of focusing so much on how bad the code is take the time to get to know your coworkers better. Talk with your manager and the business leaders about the business. Learn more about the business you are in and how your code makes an impact to that business. At the end of the day the goal is not to produce clean code. It's to make your company successful. I'm not saying c…

Yep, this is difficult, but I think it is the correct approach. To follow on: if you do this successfully and you also demonstrate technical value to the organization, you are very likely to find yourself with enough credibility to successfully advocate for (or lead) efforts toward better engineering practices.

If you do all this, and never gain that credibility, possibly due to problematic individuals at the higher levels of the organization (which you can't control), then it's probably time to move on.

Re: Maintaining code quality when nobody cares

#196

Post by laythea »

ionforce wrote: post #164
ComputerGuru wrote: post #97

There needs to be a sense of ownership and pride. Even my side projects are written then rewritten over and over again until I’m personally satisfied with my approach and the quality of the code. If I use a hack to get something done on code no one but myself will ever see, I still leave a shame comment (//mqudsi: this is an ugly hack because I was too lazy to clean up access to this global variable. Fix me.) We aren…

> I place a premium I think the problem is are you saying this as an individual or are you saying this as someone in leadership with power. Place a premium all you want. But if you're a grunt, that opinion is going straight to dev null.

I laughed at this :)

Re: Maintaining code quality when nobody cares

#197

Post by LrnByTeach »

ComputerGuru wrote: post #97

There needs to be a sense of ownership and pride. Even my side projects are written then rewritten over and over again until I’m personally satisfied with my approach and the quality of the code. If I use a hack to get something done on code no one but myself will ever see, I still leave a shame comment (//mqudsi: this is an ugly hack because I was too lazy to clean up access to this global variable. Fix me.) We aren…

carpenter 2,000 years a very good analogy with quality of code.

This is very good reward system for developers . placing a premium on “skills learned or perfected” over “bugs closed or features implemented”

> We aren’t dealing with anything new in terms of work ethics and quality control in software development. I maintain my code quality the same way a carpenter 2,000 years ago would have cared about how well the insides of a finished product are designed, whether it exceeds its required specifications, what other carpenters would think of their work, how they would feel if a future apprentice or master saw what they created that day, and so on and so forth.

> Additionally, I place a premium on “skills learned or perfected” over “bugs closed or features implemented.” If xx is better implemented via an approach I haven’t used before - well, here’s my chance to learn how to do that. Sure, it’ll delay the process. But that’s where technical debt comes from.

Re: Maintaining code quality when nobody cares

#198

Post by rhizome »

crdoconnor wrote: post #87
lloeki wrote: post #28

Earlier quoted context omitted.

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…

IMO there are two features which linting tools need before I can start treating them as serious "necessities" on a code base rather than "nice to haves". lint [cosmetic | medium | serious] - you must select one to run the tool, and the rule defaults must be sensible. No "100 character line length" in 'medium'. That's strictly cosmetic. Serious is for initialized and unused variables and the like - things which you mi…

In this case, rubocop is indeed configurable: https://github.com/bbatsov/rubocop/blob/master/manual/config...

Re: Maintaining code quality when nobody cares

#199

Post by ionforce »

troels wrote: post #52
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…

Depends. Some programmers have absolutely no hygiene wrt formatting. You'd want that sorted for readability. But the bigger point is that you reduce merge conflicts since you won't have all sorts of unrelated formatting changes mixed in with the real changes.

> Some programmers have absolutely no hygiene wrt formatting.

I don't know how these kinds of people live with themselves or are tolerated by others. I hate it.

Re: Maintaining code quality when nobody cares

#200

Post by house9-2 »

flynnieous wrote: post #154
tboyd47 wrote: post #56

> Code review at the end of the task. This is something I still struggle with. I think it's a result of an open source tool (GitHub) bringing bits of culture along with it. In open source world, all contributions are entirely voluntary, and most follow the Benevolent Dictator For Life form of governance. So you do a bunch of work, and you submit a polite request for the BDFL to pull your work into the project. He or…

Or you can do pair and/or mob programming, where the review happens as the code is created. This eliminates the feedback loop and the creation of throwaway code.

Even when I pair program it is nice to have someone else review the code before merging. Or at a minimum do a 'self' code review after the work is complete, once you have pulled your head out of the weeds things might look different.
Post reply on HN