I was tasked to build something with TDD a month ago, and along with TDD, one of the many things I ended up learning in the process was how to better estimate - not necessarily how to make my estimations better, but how to not just blurt out the first number that popped into my brain.
My background is a largely non-technical one with a lot of weird tech bits sprinkled on. My working background most recently has been of the variety where I was told "Do this by this date" with no room for input from me, so coming back into a world where I have a say has been quite the transition. In a moment of panic and pressure, I'd just give whatever estimate popped first into my brain -- giving estimates that were less than ideal and not wholly considered. And against all Agile ideals and principles of common sense, there I was, with estimates and work to do in that time and of course the thing that I sacrificed was quality, and the biggest area where I did this was in refactoring.
The thing about refactoring that makes it so easy to throw to the way-side is that, well, the code works. Yes, I could spend more time making it more elegant, but why bother when it does what it needs to and I have a pile of other things to get to? So, red/green/go was my motto for a few weeks there.
The problem with listening to that line of thought is that the end result is something fiercely ugly. I asked for a week to clean and refactor my code, and honestly all I've done this week is learn what I should have done, attempt a few things, and then realize that, oops. Fixing that now -- way after the fact -- would take much longer than I budgeted for, so this is how my code lives now. Or worse, sometimes I look at something, know it's bad, research and still have no idea what to even do with it. It's been an incredibly humbling experience.
The refactor of the red/green/refactor process isn't optional. It's what keeps code consistently something people can be proud of. I'm not horrified with any of my design choices in my tiny project, I just don't like a lot of them. And I can see how if this were living in a larger codebase or had more of a lifespan, how much those not great choices would compound and spiral.