I don't think it is. There are times in projects where you're exploring the problem space and figuring out how to get implement whatever you're doing and to speed up that process, you can take shortcuts such as assuming that a value always exists, there are X many users, or this function will never fail so you `expect()` on it. Also very little testing and no documentation. Once you have something that works, it's time to make it correct by removing those assumptions and adding tests and documentation. I believe this is what the distinction between "make it work" and "make it right" is.

I can measure "works" and "fast." Good can mean lots of things, it's a subjective assessment of code quality, readability, and maintainability. More experienced programmers probably have a better idea about how to achieve readable and maintainable code, but so far no one has come up with a measurable way to make code "good." Bob Martin spells out his ideas of "good" in his books but I don't find his examples particularly good, or even real-world. The only useful guide to "good" code I've come across in 40 years programming is The Elements of Programming Style, which Bob Martin has managed to expand from a thin pamphlet to multiple large books.