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

211–220 of 245 posts

Re: Maintaining code quality when nobody cares

#211

Post by mistermann »

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…

> At the end of the day the goal is not to produce clean code. It's to make your company successful.

An even more accurate description: don't assume anything, determine what the goals of the power player employees at the company are, and follow their lead. Assumptions of doing a good job, helping the business, fulfilling the mission statement all seem like reasonable goals, but assuming you are working in a reasonable organization is not always a safe one. Sometimes, the whole thing is mostly smoke and mirrors, and someone coming along with the aim of doing a good job will become very unpopular.

If you happen to find yourself in one of these places, just imagine yourself on the set of a TV series about an IT department, say all the right things, and you might very well be able to get paid to play around with things that interest you 90% of the time while keeping up appearances with your other 10%. Be mindful of what this can do to your resume and skillset, but as long as you're making productive use of your time learning new technology, you can typically lie about what you did at your last job and most interviewers won't have a clue anyways.

Re: Maintaining code quality when nobody cares

#212

Post by betenoire »

mike986 wrote: post #155
Retric wrote: post #147

Earlier quoted context omitted.

Don't stress about code quality. Quality code is it's own reward. Yes, clean code is more fun to write and work with. But, just think of it as a different kind of optimization problem. If the investment is not going to pay off in the future, then it's not worth doing in the first place. PS: This is not giving up, it's about getting even better by becoming ever more flexible.

this is very selfish, unless you're the only developer in your shop. whoever works with you will have to bear the burden that you left behind because you think its a low ROI for YOU

There is a lot of binary discussion here that treats code as either clean or not. Of course, it's always somewhere in the middle.

Finding the right line in the sand for your current job is an art. There is ALWAYS more you can do, and being smartly-selfish is inevitable.

Re: Maintaining code quality when nobody cares

#213

Post by spc476 »

jerf wrote: post #85
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…

"IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor)." What language are you using? Dynamic languages are fairly difficult to meaningfully lint because it's hard enough just to analyze a function for problems, let alone extend past that. Static languages are easier to write non-trivial linters for, because there's more information…

I find luacheck (a linter for Lua) invaluable for picking up typos, unused variables, variables shadowing other variables and unintentional global use (since Lua defaults to global by default). The types of checks seems mostly reasonable to me [1][2].

[1] http://luacheck.readthedocs.io/en/stable/warnings.html

[2] I'm not entirely happy with the formatting issues, but they can be easily disabled.

Edit: hit submit by mistake.

Re: Maintaining code quality when nobody cares

#214

Post by bethly »

I've had business people tell me I should stop writing tests so I could go faster, even when I'm producing significantly more features than the developers around me who don't write tests. Once you get good at testing, writing code with tests is faster than writing code without tests: the challenge is the four to six year learning curve to get there.

I think we just need to stop telling people that code without tests is an option. It is an integral part of being a software developer, not a nice-to-have afterthought.

Re: Maintaining code quality when nobody cares

#215

Post by bethly »

vvanders wrote: post #201
scruple wrote: post #185

Earlier quoted context omitted.

Those places are basically unicorns, as far as I can tell. I have my own anecdotes, of course, and they oscillate between "we cared about code quality" and "we didn't have time." My experiences and the conversations I've had with others lead me to the conclusion that: almost all of us have deadlines that we didn't really help set, that we're always struggling to meet those deadlines, and that there is a stupid amount…

I've also seen the opposite happen as well where endless feedback and getting the "perfect" architecture has almost sunk a few teams. If you take too long building the ivory tower then the market may move past you. The thing I care about is if it's a deliberate decision made with consideration of the rest of the business of if it's driven by fear/reactionary/habit. The former usually means that you'll try and budget…

Any team striving for a perfect architecture rather than building something that works and then seeing where the bottlenecks are isn't focused on "code quality": they are ignoring best practice in favor of intellectual satisfaction. The best software architecture is any architecture that solves the problem.

Re: Maintaining code quality when nobody cares

#216

Post by bethly »

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 worked on code that had been in active development for sixteen years, but it only got to be sixteen-year-old code because it was reasonably well-written and maintained. Code quality and developer skill is what lets software become older than four years old without collapsing under its own weight.

Re: Maintaining code quality when nobody cares

#217

Post by bethly »

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.

Anyone can pitch a tent: building a house is harder.

Given that we need a lot of housing and we don't have many home builders, there are a lot of tents floating around this industry.

Re: Maintaining code quality when nobody cares

#218

Post by infectoid »

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…

Great advice here. Agree on a process. Do it slowly.

I work with a lot of legacy code and have felt overwhelmed at times by all the different coding styles that have been used through the code base and not know when to refactor or simply clean up.

Over the last year or two I've been using a linter to help me with all this. Basically any code I touch gets cleaned to the point the linter isn't complaining. This is usually a fairly quick and fun process and I've actually learned a lot along the way.

I would refactor as soon as too many things were touching and the code started to have a smell about it even though the linter wasn't complaining.

It has made maintaining legacy code more fun (almost like a game) and given me some better practices when moving into new code.

Re: Maintaining code quality when nobody cares

#219

Post by bethly »

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.

It's not even lying: the cycle is red-green-refactor, not red-green-done. Knowing when to extract functionality (and when to inline functionality) is part of our job, not a management concern.

Re: Maintaining code quality when nobody cares

#220

Post by bethly »

bethly wrote: post #219
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 not even lying: the cycle is red-green-refactor, not red-green-done. Knowing when to extract functionality (and when to inline functionality) is part of our job, not a management concern.

I think we tend to forget this because we so often muddy management and technical work, but management's job is to tell you what to build. You are the professional and it is your job to know how best to build it.
Post reply on HN