Live data from Hacker News

Maintaining code quality when nobody cares

mkdev.me

131–140 of 245 posts

Re: Maintaining code quality when nobody cares

#131

Earlier quoted context omitted.

So what's the alternative to lying for what you hope is the greater good? This is the advice that I give my colleagues who, after exhausting all other methods, try to squash technical debt before a 1 hour task becomes a 5 hour task. Leaving the job doesn't solve the problem (though it may save your sanity). In fact it might make it worse, because the leaving person is likely taking tacit knowledge with them. I'm not…

I have not completely figured out what to do, but I'll say that if you leave because the organization is not interested in producing quality code and you don't want to work for such an organization, and they were unwilling to give you time (ie money) to produce quality and maintainable code -- the problems they have maintaining the code after you leave, having made efforts to educate/convince them of this fact and fa…

I just left a job where I knew that management would never learn. That was my primary reason for leaving. All other problems could have been fixed IF they would listen to the employees and/or learn from their own mistakes.

Alas, it was not meant to be. I feel like I was an enabler because there were a lot of things that I held together despite not receiving any support from management.

Re: Maintaining code quality when nobody cares

#132

Earlier quoted context omitted.

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!).…

> You can also ask during interview about the coding experience of the manager you will report to. Yes, for tech leadership. No for people management. Simply put, too many people in people management positions who were "technical" x years ago. This leads to them making technical decisions that their team should be making, which they absolutely should not be doing.

>Yes, for tech leadership. No for people management.

A good tech leader can handle people management too. A good "people management" leader can't handle tech. You want both.

>Simply put, too many people in people management positions who were "technical" x years ago. This leads to them making technical decisions that their team should be making, which they absolutely should not be doing.

Good tech managers will trust the judgement of their team and know when to give them agency and when to overrule them (there are sometimes legit reasons to do it).

Re: Maintaining code quality when nobody cares

#133
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…

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…

You should trust your engineering judgement, and your tech lead should listen to you when you raise these issues, and your product team should give your team engineering time to start cleaning things up. If any of this doesn't happen, get a different job.

As engineers we have a responsibility to raise concerns about bad practices and projects that have been neglected this way. Doctors raise concerns about hospitals, lawyers raise concerns about firms and enterprises, structural engineers raise concerns about buildings and infrastructure. Software engineers should do the same, resigning in protest if need be.

Re: Maintaining code quality when nobody cares

#134

You build version 1 to throw away, version 2 to be upgraded, and version 3 to be maintained. If you never get to version 3, you never get the opportunity to worry about code quality.

Every company I've worked at will ship version 1 to production and proceed to build on top of version 1 forever. Of course, by version 1 I mean "the proof of concept I showed someone else".

A log can dream, can't it?

It's the classic bait-and-switch of corporate development. They get you in the door by pretending they have a rational process, and wait until you're invested before dropping the facade.

I, too, have never worked for a company that ever considered retiring software ahead of immediate necessity. Generally, it's always "we don't have time to do it right in the first place, because we're too busy fixing all the stuff that is broken right now."

Re: Maintaining code quality when nobody cares

#135
I hit almost this exact situation at my last gig. It came down to one of two things: was I okay with complete job security while being completely bored and apathetic all day, or would I take a bit of a leap of faith if it meant getting out of a rut? I chose the latter and it worked out. Maybe if I was a higher-up I would have tried to fix things, but it wasn't really my responsibility at the time. I'm not completely absolved; I could have tried harder to institute things like PRs and linters, but my give-a-fuck was far below the threshold it would have taken for me to really take action.

Re: Maintaining code quality when nobody cares

#136
The largest burden to raising code quality I have ever seen is the conflicting burden of maintaining product quality.

That is to say, many of the loudest proponents of code quality are the first to completely disregard the customer quality points in the product.

Yes, there are fun meta arguments about how higher quality code can let you deliver faster. Nobody is going to wait for you to get to that point, though. You have actual users and customers today. Their problem is not the code's intrinsic quality. Instead, they are trying to use the product. If you can't tie their concerns to visible metrics that you can move more effectively than someone else, then you are likely just yelling at your peers. Not helping your customers.

And please, do not make the mistake of thinking you can push massive changes without breaking things. You will cause regressions. Period. If the changes are truly needed, you will make up for them with more rapid progress afterwards. Don't punish your users, but don't lie to them either. Respond and get so that you can measure your impact before they contact you about it. Reach out, apologize and make right.

Re: Maintaining code quality when nobody cares

#137

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…

I'm in a similar situation right now: The company thinks that any feature-wanter who's loud enough is automatically "one of the product owners" (always plural, always ambiguous) with the ability to tap an outsourced development house for "additional capacity."

I regularly come across months-old new code that the main team wasn't even consulted about. Reinvented caching layers, eval'ed code in database tables, file-download endpoints that accept any path from the browser, and code with so many immediate red marks that the writer can't possibly have been using an IDE.

It hurts my pride that I've been here for years and can't seem to change the pattern, but perhaps at some level it's basically codependence [0] and I have to leave the sick corporate-entity until they really "want to change."

[0] https://en.wikipedia.org/wiki/Codependency

Re: Maintaining code quality when nobody cares

#138
post #67

Earlier quoted context omitted.

Welcome to code development in the real world 101. You either go insane, give up and take up beekeeping, start your own company or finally decide to not give a shit anymore and start hacking the same way as everybody else because in the end your are not sending astronauts to Mars, and it works "most of the time" is good enough for the clients and the price and time they are willing to pay.

> take up beekeeping I thought the idea was to have less bugs to worry about...

Yeah. On the whole, it is less. ;)

Re: Maintaining code quality when nobody cares

#139

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…

This is why you want to do some work in the interviewing steps to see if the company you're considering has a culture of code quality and mature engineering processes. "What do you need to do to release code?" "Do you do code reviews?" "How do you set aside time for refactoring?" and so forth

Re: Maintaining code quality when nobody cares

#140
post #104

I’ve often wondered about a twisted form of asynchronous “pair” programming: One person codes quickly, creating mediocre code that achieves the goals, the other person cleans the code up and modularizes it. I’m drawn to this because they are two different mindsets that achieve somewhat conflicting goals, and the tasks can be separated with minimal communication overhead. Thoughts?

I've done this very frequently on pet projects - except I'm both people. There are projects I have where I'd grab a drink, and bang something out for a few hours in the evening that works - and then, in the cold, sober light of day make sure the underlying ideas are still sound and refactor it to make it more readable.
Post reply on HN