Writing good code doesn't necessarily take more effort than writing bad code; in fact, my experience tells me otherwise. Teams that write good code iterate faster.

The point I'm trying to make is that the pursuit of "good" code is futile, as it does take more effort to achieve than writing functioning code.

But in a way you're right; if there is no to ensuring your code follows more conventions, go for it. That's exceedingly rare, however, as a situation to be in.

What property of the "good code" allows them to iterate faster?

Is it because it's perfectly abstracted and encapsulated and SOLID and DRY?

Or is it because it's written in a manner, easy to understand, easy to extend, and easy to throw away and rewrite if necessary?

It's abstracted a little bit, but every abstraction is designed to lift a roadblock and reused multiple times like an old tool. And special effort has been spent on avoiding technical debt (hard coded stuff, untested stuff, overloaded or missing properties) to the point of doing things with less effort.

Everyone's opinion is it's based on the code they actually work with(And devs have lots of personal projects which adds bias, because they think stuff is a good idea just because it works on 1000 line projects)...

I'm guessing solid and dry are a big part, but lack of cleverness, language choice that doesn't require cleverness, and heavy reuse with libraries and frameworks, and choice of feature complete libraries is probably a lot of the speed.

Something in C is going to be more work than JS or Python or Dart and work takes time. Code you write takes more time than code that already exists, unless the code that exists disappears one day.

>Or is it because it's written in a manner, easy to understand, easy to extend, and easy to throw away and rewrite if necessary?

This. But IME when you write for this purpose you tend to end up with code that is in fact confusing, not documented, and not test covered. So you need to slow down even if your goal is to one day completely re-write that module.

Perfect abstractions are never perfect unless you completely architect out the product, down to every single edge case. That's virtually impossible with a large codebase, be it due to an API or even compiler level bug.

>because I missed the market

This is not relevant to the vast majority of developers, realistically (and is an important caveat to your original comment).

It absolutely is, though many people would agree with you.

Statistically speaking, most developers are not working for startups. And of course, large companies have the sway and politics to go around not being first. e.g. Apple isn't worried about missing the market, they are trendsetters and they light a market up even when 10 years late to it.

Your “market” can be an internal customer.

it's strange seeing someone with absolutely no pride in their craft.

The craft is solving the problem, not endlessly circling around it. perfect is the enemy of good

My craft is not leaving a dumpster of a solution to the next people to look at my code when business logic inevitably changes. If someone's solution to seeing my code is "we gotta re-write it", I have either failed or a much more novel solution was discovered that makes my code irrelevant. I hope it's not the former.

Your “craft” is not to write code, it’s to solve problems. If you can’t be proud of the problem you’ve solved, you are no engineer. That’s the main difference between an engineer and a scientist.

Sure, and a civil engineer can solve a water leakage problem with duct tape. Real prideful moment.

As I said, it depends on the project. I'm not going to approach a leaky faucet the same way I would an industrial sewage pipe. Fortunately the industry is big and I can choose to work on larger problems where longevity is valued over throughput. You're fine whipping together a React App in a weekend While I'd be more the end of maintaining the React repository. To each their own.

I think coding is a balance of 2 problems

The first is the business problem, most important.

The second is the problem of maintaining and iterating on the solution to 1…

Without solving the first problem, the business dies and you don’t even need to care about the second problem… however the second problem can also kill the business if not solved eventually…

I am guessing that your definition of "problem" is a bit too narrow and simplistic.

> Your “craft” is not to write code, it’s to solve problems.

Writing code is part of solving problems.

The quality of code has an impact on the various aspects of how a group of people solve problems.

As a small example - consider onboarding time for a codebase/system. Longer onboarding time means - lower profits end of the day for the organization (I'd also argue that longer onboarding times correlates higher talent attrition). And code quality has a strong influence on onboarding time.

Code quality has an impact on the "debuggability" of your systems. How quickly can you fix stuff when things go wrong?

Code quality has an impact on the "deployability" of your systems. If your code is well-done it is easy to deploy, redeploy, etc.

I can cite maybe 10 more properties crucial to org health, which are influenced at least partly by code quality.

So, "the problem" is not as simple as it may seem at first glance.

Or maybe “code quality” really means how visually pleasing the code is, or maybe it means it takes up the least amount of disk space, or what if it means code that doesn’t use the letter ‘e’?

This is why the pursuit of “high quality code” is pointless; you are not an artist, you are aligned to solve a problem. If you do that, code or not, you are doing good work as an engineer. If you are not, you are not. Whether the code fits some arbitrary definition of “good” separate from your ability to solve a problem doesn’t play into it.

You refuse define the problem in a comprehensive way in the first place. That's the meta-problem :)

The second issue is that you think it is impossible to define an "abstract good" in code quality given a specific context (team, product, market). The "abstract good" stems for the given internal culture and market situation. One can see how it wields influence on parameters critical to business survival/thriving.

You’re falling for the trap I’m suggesting you avoid. Stop caring about platonic ideals of what Good Code ought to be, and start focusing on how well the code solves the problems it was built to solve.

You can call that good code if you want, but my argument is to stop caring about the code’s “quality”, as a value it carries independent of the problem.

It's not platonic, my argument is empiric.

The physician - operates "via negativa". He tries to find faults with the given body, tries his best, and when can't find - he calls it "healthy".

The engineer/businessman can look at the code from an empirical point of view.

If onboarding is bad -> code is bad

If understandability is bad -> code is bad

If deployment is bad -> code is bad

And so on. As you eliminate these issues, your "code quality" increases (just like as you eliminate disease, the body becomes more healthy).

Look into say, Taiichi Ohno's Toyota Production Management - one associates "zero defect" ~= "quality". So, the term quality alludes to a continuous elimination of faults and shortcomings.

The aggregate placeholder/banner term 'code quality' stems from very firm practical sources, that can be inspected, amended and improved.

Sure, but you are in agreement with what I’m saying; good code implies specificity towards the line-by-line writing and structuring of the language (that’s what “code” is, more or less), and I argue that’s useless, as do you here by citing examples of how the code solves the larger problem in the system.

I kind of agree, reminds me of a good quote from somewhere…

> make it work, then make it pretty, then make it performant

Solve the problem first, then improve the solution

Most people would, I'm sure.

On the other hand, those aren't the only two choices, by a long shot.