[skohan]

"code quality" is not real, it's just something software engineers like to argue about like sports.

We like to talk about how code is written, because we look at code all day. The rest of the world only cares about what your code does once it's compiled.

Senior engineers solve problems. They're not overly concerned with ticking all the boxes just so they can get a "good code" sticker.

[nocman]

> "code quality" is not real, it's just something software engineers like to argue about like sports.

While I do agree that many developers sometimes like to argue about "code quality" too much (and I've probably been guilty of that at times), "code quality" is definitely a real thing. I have have interacted with code bases that were a joy to read/modify, and I've interacted with code bases that made you pull your hair out at every turn (and also many levels in-between the extremes). It is not always a case of just "arguing for the sake of arguing".

[skohan]

Probably I am being a bit hyperbolic. I could be more precise and say: code quality is a solution you should reach for if and only if you are running into real maintainability problems.

But I strongly disagree with the sentiment that someone should not write code in a certain language, or should not contribute to a project until they know how to write idiomatically according to all the "accepted" best practices. It's a pedantic and elitist attitude which has little to do with making good software, and runs counter to the practice of learning how to use a language, which is necessarily a process involving ignorance, trial and error.

[nocman]

I think somewhere in the middle is a good place to start. This can be managed by limiting the scope of code a "language newbie" writes (until they get reasonably up-to-speed) -- if/when that is possible. It also helps if you have someone experienced in the language who can help point them in the right direction when they need help. That can be a challenging thing to do well. Deciding where to provide direction, and where to just let them figure stuff out on their own can be difficult. You can come off as being too picky, or just being a jerk when you were just sincerely trying to help. I think to do it well you have to be vigilant about keeping your own ego in check. It has been my experience that most people who are fairly good at something (present company included) can slip into the state of "thinking more highly of themselves than they should". That's always counter-productive, and in my experience good "mentors" (or whatever you want to call them) are the one's who excel at avoiding it.

[lupire]

By the time you have real maintainability problems, it's too late to improve code quality.

[skohan]

It's never too late. I've had to pick up development on orphan projects before, and some of them are real stinkers. You can always quarantine the bad bits and start to impose a proper separation of concerns.

[ianbutler]

Code quality is very real, but the bounds you have to exceed before lack of quality start to bog down development are pretty large.

As a senior I can pretty quickly tell in the languages I write in often, when something is a smell, and if you keep repeating some code smells for a like a year you'll start seeing compounding effects on development speed. Understanding when to allow those with good reason and when to coach someone to stop doing those is an important skill for a senior imo.

But it's definitely not immediate, way more of a pernicious concern, the codebase will effectively rot until it's painful to make changes.

[nostrademons]

Eh, I've seen a number of startups sunk (as in went-out-of-business sunk) because of code quality issues. Eventually you hit a wall where every bug you fix introduces more bugs, and the product does not converge to a state where you can launch it. Then the VCs start getting impatient and you run out of money.

The point where this happens depends a lot on problem domain. If you're doing well-understood CRUD-screen database stuff but applying it to a novel business domain, you're probably not going to hit code quality issues. If you're doing heavy algorithmic, OS, financial, or networking stuff, though, where failures compound and any one bug might take the whole system down, you really want to pay up for experienced developers that have seen all the ways these systems can fail.

[ianbutler]

Oh sure, I didn't mean to suggest code quality can't kill a business. I however think like you said it's very domain dependent on how quickly that happens. I think taking on no debt wrt to code quality is impossible though and knowing how to take on that debt and pay it down to effectively meet the broader business goals without doing irreparable harm is something everyone has to contend with while being a dev.

That said, I can really only speak to web api dev, data engineering and search. I'd say out of all of those search was the tightest area with regards to quality and even then I was lucky to be working with another very talented dev. Him and I didn't run into very many issues we were unable to solve with scaling the technology even after hitting 100m pages or so and we could have kept going on scale but we were cost constrained, navigating the business side was far more challenging for us.

I'll admit as well I've been pretty lucky so far to work in situations where code quality is considered and managed and haven't yet worked somewhere where the concerns were entirely ignored or the team didn't care.

[breischl]

>The rest of the world only cares about what your code does once it's compiled.

People in your company (including non-engineers) definitely care, because code quality bears on how easy it is to debug problems and how easy it is to implement new features or fixes (or sometimes if a feature is even practicable).