Of course it is faster to build a solution with bad performance, is hard to maintain and a nightmare to test. The manager who doesn’t know the difference is just a bad manager.

I thought that was the definition of a manager?

I’ve had good managers.

I was mostly joking.

I would argue if you were ignorant of those items, you were not very productive. Someone eventually had to come back and fix that.

It’s like tossing code at QA that you didn’t debug first. If your initial dev time was 8 hours but you have 6 more in fixing issues you didn’t really get done in 8 hours.

As a senior developer you have a dilemma, leave code dept and maybe later get accused of writing crappy code. Or fix all edge cases and and get accused for being too slow and expensive. By the time I have assessed the requirements to chose the optimal balance between hardness and dev-time, setup the right environment and automated the deployment, and made a plan for scaling out ... My former self would have already shipped the code, it would be billed, and the boss would be happy. But you are right about the total productivity, because a year or so later, the boss will wonder why something that took 3 minutes to do before, now takes 3 hours. But usually those hours are billable, so the boss is happy anyway. Then there's time to market vs software quality, how performance and security only becomes an issue after the fact, maybe I'll write a blog post.