I think it's code that does what you need it to do and is ready when you need it.

Those are the two iron requirements. If it doesn't do the job or isn't ready when I need it, it's not good code.

Testability, maintainability, extensibility, the mythical "elegance": all great qualities of code. Sacrificing them entirely to ship faster is lazy hacking. Do as much of them as you have time to do. But they're not more important. If the code is wonderfully tested and six weeks late it's not good code. If I can extend it later but it doesn't do what I need it to do right now it's not good code. Nobody will need to maintain code if it never ships.

Of course any simple statement contains minefields of nuance.

"Does the job I need it to do" implies all sorts of things: a clear contract and requirements, error-free operation, reliability. You can achieve these goals with good management, with well considered tests, with judiciously chosen effort on future scaling requirements: if it does what I need it to do today but breaks tomorrow it's bad code tomorrow.

And therein lies a whole new world of nuance: if it breaks a day after it ships it was probably bad code at the start. But if it works for 10 years before breaking I think it was good code. When's the cut off of how quickly code goes bad — it all goes bad eventually — for it be bad code?

"Ready when you need it" is if anything even more fraught with assumptions. On time according to whom? It assumes reasonable expectations by management, and reasonably accurate estimation in advance by developers of how long work will take. Experience shows the former to be rare and the latter possibly imaginary. "Ready when I need it" doesn't necessarily mean "ready by the deadline".

If the system fails then the new code was not ready when you needed it. But what about new features? You don't need them, you want them, and the sooner the better, modulo all the other considerations already mentioned. When you need code has to be informed by larger considerations: finances, customer commitments, competitive threats, market position (I'm expressing these in capitalist terms but the same considerations apply to open source code in different ways).

My own code has a bias to being ready sooner rather than later. It is less tested, it is less extensible, it is less elegant by default than that of my peers. But it's usually ready when I need it. It's good code. It's not the best code; I am always learning and can always do a better job, get faster at doing the things I do and thus do more of them in the time available. But it's good.

My idea of good code relies heavily on libraries and frameworks. I don't care if it's not exactly the way I'd do it. I care that it works, and that it ready. I will avoid frameworks and languages and practices that slow me down in pursuit of elegance.

I will not write tests except when the labor saved by automated tests exceeds exceeds how long it would take to manually verify it works (but that happens very soon in a project of any complexity). Tests are a time saver, not an intrinsic good. Errors slow you down, errors stop you doing what needs to be done. So you test, and stop testing when returns on new tests begin to diminish.

Good code is ready and working. Other considerations, important though they are, are secondary.