Originally published in April 2017.
Today’s lesson is knowing when to quit. I passed a very pleasant evening working on a regex kata. I read half of the Well-Grounded Rubyist’s regex section numerous times, parsing out each individual bit of code, I read Stack Overflow answers, and all kinds of other stuff. I wrote my own tests and code.
I couldn’t get it to work.
After an hour on this problem, I should have either stopped working on it or asked for help. I did neither. I kept going.
After two hours, I realised I needed to ask for help. But by that point, I had reached the “try random things” phase of programming, which meant I kind of had no idea of what was working and what wasn’t.
THANKFULLY I had at least committed some useful code but I spent another half hour struggling on my own because I knew at that stage asking for help would actually be difficult — how to recount what I’d done when for the last while I’d been just chucking in semi-random bits of code?
So lesson learned: don’t spend too long on a problem because it becomes counterproductive.
On the other hand, I am fully immersing myself in the student life — including subsisting on pizza and ice cream.
