This is basically long-term vs. short-term choice.
You may implement a feature in an hour doing dirty hacks,
Or you may spend the next week studying the actual needs of the users/your boss, translate them into requirements, refactor the code to accommodate the code base for the new change, write tests, implement the changes and document the new code.
The week minus one hour you gain immediately has a long-term cost. It costs money every time somebody (or you in six months) has to read the code. It costs money when something breaks, and nobody can find the reason of the issue. It costs money when you need to implement new changes, but you can't, because the code base became too legacy to work with.
How to deal with it?
By telling your boss the actual time needed to do the change. No, you can't do it in a hour, because the only thing you can do in an hour is a quick hack, and you're a professional programmer, not a quick hacks guy.
You'll often encounter pressure from your superiors. Remember that the duration you give is not negotiable. If the boss wants the feature to be implemented for tomorrow, tell him that there is no way you can do it. Imagine if your boss tells to Boeing that he needs to travel from Seattle to Hong Kong in twenty minutes. Asking you to implement one-week feature in one hour is similar.
Remember that you are a professional programmer, and your boss probably isn't. This creates an interesting situation where it might look like your boss has a choice, but in fact, you're the one who takes the technical choices—which also means that it's your responsibility to take smart choices which makes your company competitive. It's easy: what your boss wants is high quality, low price and short schedule, all three at the same time. Since what he wants is not possible, it's up to you to find the right balance.
Always be aware that your boss may not know things you know, so don't talk to him in technical terms. If you explain that you can do something in a week, or the same thing in two days but this will increment the technical debt, for most non-technical people it means: "I can do this in a week, or in two days if I make an effort." They don't know what technical debt is, so they interpret the part they understood. Your boss doesn't know what testing is, or why common coding style is important, so don't bother him with those aspects. He shouldn't need to chose between 95% targeted code coverage or 40% targeted code coverage: again, this is your responsibility as a lead (or sole) programmer of the company.
In the same way, your boss doesn't know if a feature should take an hour or a week. I stopped counting the cases where my customers were truly convinced that six man-months project can be done by one person in less than a week, and the cases where they were convinced that a change should take weeks of development, while it simply consisted of changing a value of a constant and recompile.
Negotiate and suggest solutions. If your boss wants shorter schedules, suggest to remove this feature or that one, or make this thing more basic. Or find a creative way to fulfill the needs of the customers while reducing custom development to a minimum. Some problems can even be solved without writing any code at all. Your boss is not expected to know that; likely, he doesn't even know precisely what programming is about.
