Author: FiddlersCode

Software Engineer & Violinist

on by
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!

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

on by

Originally published in April 2017.

In the music industry, we have a saying: RTFS, which stands for “read the f***ing schedule”. It’s mostly used on tour, when you roll down to the hotel breakfast after a late night concert and ask your equally tired colleague, “When does the coach leave?” “RTFS!”

Well, I have a new version for myself in coding: RTFI, or “read the f***ing instructions.” 
I spent 90 minutes this morning working on a Code Wars kata. I skimmed the instructions a couple of times, and was pretty confident I knew what I was supposed to do. So I built my own TDD tests, and proceeded along my merry way writing the code.

Before too long, I had passed all my own tests and was satisfied with the code so I ran it through Code Wars. Failed one test, ok, no problem, can fix that. Then I failed another test. Now this particular kata had you build your own tests so I couldn’t tell what argument my code was being passed that caused it to fail in so many different and spectacular ways.

I thoroughly ignored the advice of my cohort pal (sorry, Rob!) who rightly insisted that the order of the elements in the array mattered, because I was convinced I understood the (in my defence, rather poorly written) instructions.

After more tests failed, I went to look at the instructions again and lo and behold, I had been building the wrong thing. Needless to say I was by now too frustrated to get any useful work done so I’m writing this blog post instead as a warning to future Paula:

RTFI!

A random photo of me in a cowboy hat.

on by

Originally published in April 2017.

The view from St John’s College, Cambridge — taking a tea break from a rehearsal

This week 3 blog is coming out in week 4 because I turned a corner in coding this week: it was the week I started preferring to write code over blogging.

This may not seem like a big deal, but it is — I LOVE writing and for the first two weeks, I would have much preferred to write about my coding than to actually code. Now it’s reversed, and although I still love writing, I’m actually kind of irritated that I’m writing now instead of coding.

But I think it’s also really great to document what’s going on, so here goes.

My week 3 experiences:
1. It was much easier than week 2 — I was able to put into practice a lot of what I’d learned in week 2 and it all made sense.

2. Each day is so full of new coding knowledge — I was looking back at week 2 programs and they seemed laughably simple. This is encouraging, because at the time, they felt hard.

3. I was pretty disciplined about not working too hard! I know the course is about to get intense, so I made sure to get all the work done that I needed to do, but I also made sure to enjoy walking around, getting time in the sun, and chatting with friends. All of this is really important to give my brain time to rest from all of the intense learning I’ve been doing.

4. My FitBit is still great — it’s making me walk more, and walk the long way round to things, just to get in all those steps.

5. My violin recital went really well! It was super fun to play my own piece (Yankee Doodle Variations for Solo Violin, which I wrote last summer after an ice cream truck drove by my house every day for two months playing Yankee Doodle) and, despite not having played a solo recital in a few years, I wasn’t nervous at all. My pianist Tim was great to play with and we’ll definitely play some more recitals. So it’s wonderful that I will still be playing violin for fun as I become a programmer.

6. Also in violin/book news, I did 8 hours of recording sessions on Saturday in London. My train was quite delayed so my planned 20-minute excursion to Daunt Books en route to Air Studios at Belsize Park had to happen in three minutes. In a beautiful meta-comment, I bought a book on split-second decision-making (“Blink”, incidentally the title of one of the scariest Dr Who episodes). The only problem is that I am now reading eight books simultaneously, all of which are fascinating. Need to focus!

Ok, now I think I have earned some coding 🙂

cheers
​Paula

The lush grounds of Madingley Hall, where I played my recital and also had an excellent roast lunch.

on by

The River Cam

​So I’ve finished the second week of Makers Precourse. Not gonna lie, this week was a lot harder than last week. I have finally dragged myself through the 40th chapter of Learn Ruby the Hard Way and a kicking back with a well-earned Franziskaner. FYI, LRTHW is hard, and I just bought Chris Pine’s Learn to Program on Amazon, in actual book format which I shall mark up with a highlighter, because I think I need more practice. I even went back to Code Academy to have a look at their explanations for things — boy is anything easier than LRTHW.

My thoughts from this week:
– Fixed growth mindset is so important: our coach shared this fantastic Ted Talk which you should all watch.
 https://www.ted.com/talks/carol_dweck_the_power_of_believing_that_you_can_improve .

The phrase “effort + difficulty = new neural connections” really resonates with me. Programming is hard, but I look back on this week and I think of all the things I’ve learned that I couldn’t do before and that’s pretty cool.

— Some katas on Code Wars are easy and some are beasts. Choose wisely, and take an ally.

– Pair programming is great. I did my first pair session today and having another head on a problem is really helpful.

— It’s really important to understand what a piece of code does, rather than just call it blindly. Thanks to Gus, who spent two hours explaining arrays over Slack to me to make sure I REALLY understood everything before calling a function to do the dirty work for me.

— However, why not take the programming outside and work through with a pen and paper while being surrounded by daffodils?

​ — I might have given myself a pep talk as though I were a Starfleet officer.

— I’m trying not to go too crazy on the Precourse, simply because I know the course is going to be MEGA intense. So stopping when my brain says enough and making sure to have fun is important!

— My FitBit is totally getting me out of the house!

Until next week
​Paula