File.open(“third_post”, “r”)

So, week 3 is now over and I’d say it has been the most enjoyable and productive one yet. I will admit to slacking off a little on Monday/Tuesday — snuggled up in a nest of blankets, drinking tea, watching Star Trek, and playing with Codewars. I did manage to do some 4kyu katas though, which I was pretty proud of as I was rank 6kyu at the time. I also got to make some more of those funky regular expressions — I know you get a mini-victory feeling whenever your code works as you hoped, but I swear I get an extra boost when I nail one of those things.

After spending more time on Codewars, it has become clear that you can gain a real advantage on there by selecting well-worded katas. Because the katas are user-made some of them can be a little difficult to understand, perhaps through poor descriptions or an expectation that you can comprehend difficult mathematical algorithms. But every now and then you stumble across one that makes perfect sense — the problem is clear and now you just need to fix it. The fixing part may not be so easy, but at least you can clearly visualise your goal, and that helps a lot. It makes me wonder what life will be like once I begin work as a developer — having to create code to suit a customers needs, which may not be articulated as well as they could.

Anyway, the main workload this week was to create a student directory — a list of students at a fictional school which can be edited, displayed with various filters, saved, and loaded, all within the command line. MA provided us with detailed instructions for how to do this, which eased us into the whole thing very gently. Whilst my file ended up containing ~250 lines of code, it started with only 13 strings. Admittedly, the instructions were a little dull at first. It feels like every single week we’re going back to page one of Ruby for Dummies — this is a string, this is an array, this is a variable, this is my will to live etc. It’s not the most fun in the world, but at least everything is getting drilled in. The fun came when we were given sets of exercises to work through. It was back to Google and StackOverflow to solve some, and others I managed to solve by going back and looking at code I had written previously (e.g. as part of Ruby tutorials or in a Codewars kata).

I did encounter a few hiccups here and there, mostly with the new bits of syntax I was learning (opening/closing files and using a CSV library), but nothing got me stuck for too long. Overall I liked the steady pace of the instructions, only introducing one thing at a time. If I’d seen what I was going to make at the very start I would never have thought I could actually do it. Breaking down the program into a series of little steps made sure I understood every single line of code I had written. Nevertheless, once I was looking at the final product I had that familiar daunting feeling. The thought of writing something similar, without such guidance, still feels like a mammoth task. I guess it’s all just part of the learning to code adventure, but it’s one thing to learn some syntax — it’s another to learn the thought process you need to be a successful dev.

We’ve not really got to the point where we’re given advice from MA on how to approach tasks larger than a Codewars kata, but I have started reading Poodr and I get the impression that this book will help me a lot with the how-to-think side of learning to code. The first chapter actually paired really nicely with this weeks assignment, in fact I found myself writing notes on how to improve my code whilst I was reading it. For example, during the student directory work I spent some time wondering why my functions had to be refactored so that each one was just a few lines of code that only did one little thing — it wasn’t helping me learn the materials any better, and the code already worked anyway, why change it!? But after reading some object-oriented design (OOD) basics, it all made perfect sense. Each function having a single responsibility makes it so much easier to adapt and change the program at a later date, as I found when I reached the last exercises. This may seem like common sense to an experienced dev, but for a noob like me it’s valuable advice.

During the week I also went to a meet up with some of my fellow students. About 10 of us stormed the Barbican cafe and took all the power sockets we could reach. It was really great to put some more faces to names, and I get the feeling I’m going to leave this course with a few good friends. Everyone has been super friendly and I really enjoy looking at the different ways we approach the same tasks. I also feel like I learn so much more when I work with other people. Even if I’m helping someone with a task I’ve already completed, it forces me to really think about what I did and why I did it that way. The final week of the pre-course is centered around a pair-programming task, so I’ll be catching up with several of those new faces again soon.

Finally, this was also the week where I was forced to push the button and send most of the contents of my bank account over to MA. It was… a little scary. Course fees are fully paid and I’m in it until graduation day. But… what if I don’t have what it takes? What if I get half way through and realise this isn’t what I want to do for a career? It’s amazing how you can be so confident one minute, then the thought of making a commitment brings utter panic. So I just need to keep reminding myself of one thing — even when all of this sucks, when I’m frustrated, when I can’t fix a bug, when my mind won’t grasp a concept, and when I genuinely doubt whether I can do this — I don’t want to stop. I’ve traded in my evening gaming sessions for coding on the couch, not because I need to catch up, but because I enjoy doing it. And that’s a feeling I’ve never had with anything else I’ve done.