> One thing I've been having trouble with as my project gets more complex is when to refactor. I usually wait until (A) something is painful and (B) I have eno

> One thing I've been having trouble with as my project gets more complex is when to refactor. I usually wait until (A) something is painful and (B) I have enough instances of that pain to see the pattern that my refactor/abstraction will address/consolidate. Else I'm just rearranging furniture or making it harder to rearrange in the future because my assumptions were wrong -- I've built a fridge and stove in a room that never became the kitchen when I could've just fetched a bucket of ice and a bunsen burner as I needed them. But now all the doors are too small to migrate my appliances because I thought this was going to be a hobbit house. Turns out the guests are only half hobbit. It's easier to refactor naive, repetitive, even dirty code than it is to refactor failed and premature refactors/abstractions. Seeking correctness is cool, but often I can't see far enough ahead to know what "correct" actually entails. Writing what feels like a simple/obvious hack now can be better down the road than trying to prematurely engineer something that seems correct.