My first compsci teacher was Harm Bakker aka Harm the Almighty Recursion Master, and anyone who followed his classes has the following quote imprinted in their brains:
"... and then it's tempting to start kludging. I have a suggestion: get it right the first time."
Whenever I'm programming I can still feel his disappointed stare of disapproval when applying a quick and dirty hack.
> "... and then it's tempting to start kludging. I have a suggestion: get it right the first time."
Where this falls down in the real world is that oftentimes your understanding of the problem is quite limited at first. You'll ship a demo or an MVP, and that will teach you a little. As you continue to explore the problem through your work you'll often redefine it. Or it will redefine itself, as happens in so many war stories of service scaling, product maturation, and so on.
Fortunately, it's not as black and white in the real world. Quick and dirty hacks are a real thing that will never go away. If anything, having the ability to do those under stressful scenarios is a good quality to have.
Someone already responded with hacks being a fact of life. There's basically CS programming, and then 'real life'. If there wasn't a need to generally get things out the door I imagine there would be far fewer exploits of software out there.
"... and then it's tempting to start kludging. I have a suggestion: get it right the first time."
Whenever I'm programming I can still feel his disappointed stare of disapproval when applying a quick and dirty hack.