That's incredibly myopic. Any system that yields an "ounce of prevention being worth a pound of cure" is one that should be even more important to someone like you who's under tight time constraints. During any given day, you're not just spending time on the particular task at hand, you're spending time as a result of past decisions. If you're adding a new feature to the Widget class, the amount of time that'll take today is directly proportional to how well that class was originally written. If it was originally tossed together, to be just "good enough", but not readable or maintainable, then every feature you add will be more costly to implement.
Similarly, your work today may involve fixing a bug, that would never have surfaced had the code been properly reviewed 6 months ago.
You have to try to envision an alternate universe, where you were taking the time to implement those quality processes that pay future dividends (commensurate with their cost, of course). The question you should be asking is, "would I be further ahead in that alternate universe than I am today?".
It's just bogus to claim "schedule" is the reason you have to implement processes that forgo earlier, cheaper fixes, for later, more expensive ones. I know lazy coders use that excuse all the time, and managers frequently go along with that short-sighted rationale, but it doesn't make it right.