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.
​