For a long time, I was that guy—not the one who writes perfect code (I always thought my code was "meh"), but the one who always tries to create that challenging pull request for reviewers, you know? And sometimes it worked.
I confess that even today in my personal projects I still try to stay close to that, but these projects aren't paid for by someone who wants results with a date and time.
Lately, I've been understanding that "the awesome project" isn't always about having the best gitflow in the world, or impeccable code quality and test coverage. It also doesn't need to be a project with an enterprise look full of miraculous architectural solutions.
The awesome project is the one that simply works, that even with butterflies in your stomach, is delivered on time and without bugs (or at least with the minimum possible and that don't require major refactors). And most importantly, the awesome project is the one in which the people involved evolve more than the product/service created.
The crazy part of all this is that you've been hearing this throughout college, from more mature professionals, or from managers who repeat that cliché: "Done is better than perfect..." and you never realize the value of it until you reach this conclusion on your own.
Did it work? Great! Did it work with absurd code quality? Perfect!
A Note
Don't create bad code, just have the good sense to understand that sometimes technical debt can guarantee the delivery of a project. It's also your obligation to ensure that these debts don't become bottlenecks when this project needs to scale.