What part of faster is better means engineering to you? Non engineers will prefer you get there faster, but however you get there, better is better.

If you want to say something just say it no need for trap questions.

Faster delivery of a project being better for engineering is obviously one of the most important things because it gives you back time to invest in other parts of your project. All engineering is trade-offs. Being faster at developing basic code is better, the end. If nothing else you can now spend more time on requirements and on a second iteration with your customer.

> obviously one of the most important things because it gives you back time to invest in other parts of your project

That is until you get so deep in code debt that you cannot move anymore.

There is an equilibrium to be found. Faster is not always better, and trying to have every single line perfect is not good either.

I did mention trade offs.

> we do engineering here

Well, we make software, at any rate.

Most of the time that's pretty divorced from capital-E engineering, which is why we get to be cavalier about the quality of the result - let me know how you feel about the bridges and tunnels you drive on being built "as fast as possible, to hell with safety"

Don't put words in my mouth, you don't care about safety not me. And for what it's worth I'm an electrical engineer first, so if you have some inferiority complex about software you don't have to apply it to me.

Hey, you're the one who said "faster is better", not me

Consider applying the strongest version of an argument than the weakest. Obviously faster it's better means to a similar standard. Not faster due to a shittier standard.