Ask HN: When Quality Doesn't Matter

You mention that there is no penalty for not writing a "proper" code, nor is there any incentive for writing one. But I'd like to argue that doing something right purely for the sake of doing it right should be the entire reason for doing it. In a certain way, this is adjacent to the age-old question of "why should one be good?" While I'd refrain from discussing philosophy at length, suffice to say that doing good work should not be purely driven by the desire of any reward or recognition. Doing it right is an incentive on its own. Besides, if you ever have to switch your current org for one with a better work culture, you may find that bad habits have an annoying property of being difficult to get rid of.

I am not comfortable writing bad code, as it is detrimental to my professional development. I am unable to improve my technical skills in this environment. The issue stems from a lack of qualified or senior developers on the team, which makes it easy to write poor-quality code and pass code review. The developers who were on the team before me wrote subpar code, and nobody questioned it. Now, we have items to deliver in sprints, and it's challenging to deliver quality software within the given timeframe. When I try to write good quality code or try to write, I often can't finish my items on time. Unfortunately, nobody blames the existing codebase; instead the blame falls solely on the developer.

I guess it's a difference in perspective?

The reason I make my code the best it can be isn't to please my employer or get some sort of recognition. It doesn't matter to me if the code is never viewed by human eyes again.

I do the best work I can because of a sense of pride of workmanship and personal accomplishment. Whether or not the company I work for recognizes that doesn't enter into it.

In this sense, anyway. There's a different angle that overlaps this: if I really think the company doesn't give a shit about the quality of their products/services, then I'm quitting that company because I want my employer to be at least as interested in quality as I am.

What if you do not have enough time to do you best work... Problem isn't about caring, problem is when you care it takes time and when it takes time nobody gives a shit, because they do not care good software but just ship and get results. Also when you have a codebase full of fixmes or bad code it is not easy to adding a single line sometimes because 'technical depth'.

> What if you do not have enough time to do you best work

Early in my career, I'd just do the best work I could given whatever the constraints were.

Later in my career, once I grew a bit of weight to throw around, I'd push back and say that the deadline doesn't allow for quality production, given the scope of the task. Then I'd offer various options to narrow the scope such that good work becomes possible.

Even then, sometimes reality is not what we would prefer and I end up falling back onto "the best I can do given the constraints". Good engineering isn't developing some platonic ideal of excellent code, because there are always constraints. If not time, then something else. Good engineering is developing the best possible solution given the constraints that have to be worked with.

Thanks for the comments.

Agreed. My company puts out terrible code that only mostly works. I was literally laughed at when I suggested we start documenting things and adding tests. This is a dev team of around 30 people who still have to site through a morning "stand up" every day, who are never given enough time to do quality work, and where only 3 devs are trusted to merge code and make deployments. Until recently, they were also the only devs who were able to generate API keys for certain, necessary third-party APIs, so if your key stopped working and they weren't in, you were completely blocked until one of them showed up.

There are devs here who have been "junior" for 4+ years, and senior devs with less than 2 years of experience - all learning and teaching the same bad habits and bad code to each other. A few months ago I did a Lunch N' Learn showing some JS features and when I showed how to use `.map` in place of a for...each loop for certain situations, it blew more than one mind - which in turn blows my mind. These are "senior" front-end devs who never new that things like `map`, `find`, and `filter` existed. They haven't actually _used_ any of these features since then either, and I have been labelled "picky" when I point out how to change their 10 line block into a 3 line block during code reviews. I doubled-down on that label when I noted that converting observables to promises (these are Angular applications) was a bit of an anti-pattern, and all our inter-application communication is completely unsecured and 100% open for abuse.

This company is not interested in improving things and is actively in a code-based death spiral towards unmaintainable complexity caused by terrible management and ignorant (but friendly and likeable) product owners. When I put together a proposal or plan to improve something (like switching to a message service instead of relying on inter-iframe messages), the first question I get asked (by 3 different people, no less) is how I had time to put that together (it took about 30 minutes); didn't I have better work to be doing?

But I can't find another job, so here I sit, witnessing the slow tech-death of their little universe, doing what I can to not go down with it too far. I am atrophying and can't stop it.

When you say, 'subpar code', what do you mean? How are you measuring the quality of the codebase? Is it objective? Can a tool be run that will spit out a number and below a certain number the code can be deemed 'subpar'?

When you see many of functions with 500 - 1000 lines or most of functions with 10-15 if else statements, I am not joking... There lots of and lots of FIXME: bla bla. If you see this what would you think ?

Point taken.

Do tools such as Crap4j exist for other platforms? It measures the amount of CRAP (Change Risk Analysis and Predictions) in your code. Cyclomatic complexity is one of its big measures for determining CRAP. What's nice about having a tool is there are no arguments. The first step on a pull request is determining whether the code is CRAP!

Most organizations quickly outgrow the need for such a tool, but yours might be one that would benefit. You'd be amazed at how objective social pressure works on a dev team, though beware, you may have problems if your team's Primadona consistently produces CRAP code!

Edit: Link to Crap4j - http://www.crap4j.org/

We just heard about it, thanks for the comments.

At my place, I would complain about your code in code review. Because https://youtu.be/9L3M2WC5LPA

And I've trained people who have been writing bad code into writing better code and into delaying all merge requests by also complaining about bad code! >:]

I'd be pretty depressed if I worked somewhere this weren't the case. So it sounds like either your workplace culture is very bad or like mine is very good. (I don't know how common either case is.)

I really like to code, as well as being reviewed or doing code reviews. However, when I try to do code reviews, most of the time I receive comments like 'We do not have time' or 'We can fix it later' or 'This task is just a bug fix'. The problems isn't about caring; I care about the code I write, but when you care, it takes time. When you need time to do things right, this isn't reflected in your performance. I experimented with being like others who don't care much and just do the task as needed, no more. Then I realized improvements in my performance :D.