I have the following conversation with my colleagues all the time:
Don't worry, we'll hack that together in no time.
And on the flip side:
Oh my god, that project was such a hack job.
It really confuses non-technical people in the team. Sometimes we talk about a hack being a sublime thing and other times it's the most hated thing in the world.
Often it's necessary to put together a hacky solution to meet a deadline. The problem becomes where the level of dirty code outweighs the rest. We jokingly refer to this as "Dan's Law" - where 5% of hacks are permissable, but no more 😉.
The thing with hacks, is they're often the source of progress. When you see an innovative piece of UI in a mobile app, often the coder is hacking the frameworks or tools to do unexpected and delightful things. In this way, hacking is a form of creativity - bending the code to the will of the programmer.
On the flip side of the coin, the thing that annoys programmers the most is a really untidy codebase, where no care has been taken. Coding is a team sport, and it's disrepectful to other people on the team to litter crap all over the place.
How do you resolve these two conflicting views?
If something is a hack in order to achieve something delightful, and genuinely useful, then it makes sense to include it - but there's no reason it shouldn't be documented equally well as other code. In fact, it should be documented even better to make it clear why an unconventional approach was taken.
With regards to time pressures, having hacky solutions is ok if it's a prototype, or it'll get cleaned up later. What's really insidious is relentless tight deadlines, which leaves no room to clean up the previous hacks. The problems just compound until the team is neck deep in technical debt, and ultimately it will start to reflect in the quality of the product and the customer experience.