It’s been a month since I last wrote a proper coding blog, and in that time, so much has happened! I learned JavaScript, did a project week, and now this weekend have come back to my Ruby roots as the entire cohort works as a team to use rails to build a replica of Facebook.

Regarding my initial experience of JavaScript, I can do no better than to quote Makers Academy coach Roi Driscoll:

“Javascript week is a very special time at Makers. For me it was the first time I wanted to throw things at the projector and scream ‘HERESY’. It was not my beloved Ruby, and I was not happy about it.
I felt strangely codeblind — unable to make sense of all the curly brackets, parenthesis, semicolons and the damn word ‘function’ here there and everywhere. My reaction was to fill my soul with a deep and passionate hatred of Javascript as a language, and anyone involved with it was the Devil. I was wrong.”
I did eventually learn to do cool things in JS, but what a sweet relief to be back in the land of Ruby, where there is a useful method for anything we could possibly want.

This weekend’s challenge was a delight: called Ruby Refresher, it was simply a list of about 40 puzzles we had to solve using Ruby methods. I did panic at one that asked for the square root of a number — thinking I was in JavaScript land where there are no methods — sorry, functions — and was imagining creating the method from scratch. A quick Google search reminded me of what I already knew: ‘sqrt’ is a handy Ruby method.

So I had a lovely romp in the park with my old, dear friend Ruby this weekend and now forward to making as many puns on the word rails (“keeping it rail”, “the holy gRail”) as I can possible manage.

Me as a kid atop my brother’s car.

Originally published in April 2017.

Makers Academy day 1 of 60 (not counting weekends) is finished. It’s 8:45pm and I am in bed absolutely exhausted and very happy.

We had orientation this morning, learning about how MA functions. It was great to see their intelligent approach to learning and even better to hear from Dana, our Chief Joy Officer (meditation/yoga/life coach). I’m so glad MA encourages us to take care of ourselves!

Then I had a fantastic Alexander technique lesson over lunch, which really helped with some left shoulder issues I’ve been having.

And finally, spent 4.5 hours pair programming. It was an intense experience! Learning to work in close proximity with another human being is always a learning curve but years of playing chamber music have really helped to train me in listening and communicating. We both thought our pair session went really well, we had a good feedback session, and are going to chat on Slack tomorrow morning about what we learned.

The actual coding itself was pretty easy, which is good — the focus was on learning to pair effectively. Am looking forward to some deeper coding challenges!

As soon as we hit 6pm my brain just shut off. While I wanted to do another 5 hours and totally finish the week’s challenges on day 1 (afternoon 1 even!) all of the sudden none of the words on the page made any sense to me so I had to call quits on the session 🙂 .

I then went on a walk for an hour to appease the FitBit gods (while chatting on the phone to a friend, conveniently), came home and ate bacon and porridge for dinner (yum!) and now am struggling to stay awake till 9pm.

So what have I learned from today?
 — I need to read instructions, code, and error messages slowly. I read far too quickly and get away with it a lot, but what’s the rush? Where’s the race? Better to do it slower and more mindfully. Hm, mindful code reading…
– I am very much eyes on the prize — complete the challenge the recommended way before finding other ways to do it. I do think this approach is borne out by Bloom’s Taxonomy — master the apply stage before moving on to the analyze stage.

– I really can’t sit still. In 4.5 hours of pairing (including breaks), I moved from the desk to the floor to lying on the floor (not great for typing but ok for navigating), back to sitting on the floor and ended up at the desk again. I apologise to everyone I am pairing with that I will be roving around.
– I need to wear more comfortable shoes when walking.

​Bye for now!

Cambridge is beautiful in the springtime.

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.