I think we very often confuse engineers with scientists in this field. Think of the old joke: “anyone can build a bridge, it takes an Engineer to build one that barely stands”. Business value and the goal of engineering is to make a bridge that is fast to build, cheap to make, and stays standing exactly as long as it needs to. This is very different from the goals of science which are to test the absolute limits of known performance.

What I read from GP is that they’re looking for engineering innovation, not new science. I don’t see it as contradictory at all.

You should worry about code quality, but you should also worry about the return on investment.

That includes understanding risk management and knowing what the risks and costs are of failures vs. the costs of delivering higher quality.

Engineering is about making the right tradeoffs given the constraints set, not about building the best possible product separate from the constraints.

Sometimes those constraints requires extreme quality, because it includes things like "this should never, ever fail", but most of the time it does not.

> You want initiative, and you also don't want initiative. I presume you want it when it's good and don't want it when it's bad, and if possible the people should be clairvoyant and see the future so they can tell which is which.

The word you’re looking for is skill. He wants devs to be skilled. I wouldn’t thought that to be controversial but hn never ceases to amaze

Some of our code is of high quality. Other can be of any quality as it'll never need to be altered in it's lifecycle. If we have 20000 financial reports which needs to be uploaded once, and then it'll never happen again, it really doesn't matter how terrible the code is as long as it only uses vetted external dependencies. The only reason you'd even use developer time on that task is because it's less errorprone than having student interns do it manually... I mean, I wish I could tell you it was to save them from a terrible task, but it'll solely be because of money.

If it's firmware for a solar inverter in Poland, then quality matters.

> people who talk about business value expect people to code like they work at the assembly line. Churn out features, no disturbances, no worrying about code quality, abstractions, bla bla.

That's typical misconception that "I'm an artist, let me rewrite in Rust" people often have. Code quality has a direct money equivalent, you just need to be able to justify it for people that pay you salary.