K. Sabbak

I’ve spent a good chunk of time refactoring recently. It’s taught me a lot, mostly on code structure and good design but also about myself and my working style. I’m not sure if I’d count as a kinesthetic learner, after all, I’m really bad at Sports, but my favorite refactoring tool is my printer. I’m pretty sure this also makes me a bad millennial (for owning a printer at all…).

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.