I was answering to "using a substandard approach and language" -- if that is an option that's on the table I am assuming the time savings would be substantial (

I was answering to "using a substandard approach and language" -- if that is an option that's on the table I am assuming the time savings would be substantial (order of 50%). I do of course agree that one should often "Taking a little more time to think about or improve some code". It seems like you almost say that it is better to be good at coding than bad at coding. Which I think nobody will ever disagree with. What I was talking about was assuming senior coders, knowing what they are doing, who think about actively choosing a shortcut. I don't think it's a strict dichotomy, but I think there is a scale. For every project you can choose how well to do the job, and compare it to the importance the task seem to have and the budget it ought to have in developer time spent on it; then find relevant short-cut which does not dig you too much deeper in the hole. I usually try to figure out "how would I refactor this later to clean it up", make sure it can be done without too much pain, then if I can see the path clearly it's OK to take the shortcut if needed.