Oh, I see. You don't want to impugn the abilities of the programmers (naturally), but if a programmer writes code that he himself knows is sub-standard in order to meet an unrealistic deadline that has been set for him, I would call that both bad code and bad coding. He's not at fault for the bad coding, but it is (even in his own estimation) bad coding, i.e. not the work he would do under a reasonable deadline.
Sure, but that's unhelpful pedantry when it comes to diagnosing efforts on how to do better in the future. I am assuming that that's what you're trying to delve into, apologies if I'm two-for-two on getting that assumption wrong (as I did with bumpyglint).
If I know something is a bad fix, and I tell the people above me it's a bad fix, and they tell me to do it anyway, then it's not "bad coding", it's "doing as I'm told". These things have acceptance criteria, go through QA (to the surprise of some here, no doubt), etc, et al. It's not on the programmer to determine that the fix is good enough for whatever release it's going into. Somebody else makes that call (whether it's a manager, QA, the QA lead, or a combination thereof).
To give a historic example for when I worked at a startup, we didn't really have a product team, so my code (as a junior) went through two seniors, and on occasion one of those seniors would clear it with the boss (CEO of eight people I guess is still a CEO). Nowadays my code would go through one or two peers (I don't really have anyone senior to me anymore so far as programming goes), and if it's a bodge job, this is communicated to them, and also to product if this has an impact on either the actual product, or something as simple as future maintenance for the area in question.
If Isabella is supposed, as a one-time matter, to get gold for every natural wonder, but the coding is such that she gets that not just in antiquity, but at the shift from antiquity to exploration and again at the shift from exploration to modern, wouldn't that represent a poor way to code that game effect? i.e. poor code. And however it came about, poor coding.
You're stopping the casual chain at the typing of the code. As others have attempted to point out, that's not generally where the causal chain stops, and hypnotising devs into only writing good code wouldn't solve the actual problem. Not being tongue-in-cheek, you can substitute whatever improvement at the programmer level you desire. My point is that it won't fix the actual issue, and the symptoms will manifest in a different way (e.g. if you force developers to take the time to only write good code, the same poor management or rushed deadlines will simply cause the code to be incomplete at point of code freeze, which introduces
other issues).