AJ Dyrbye

Web Developer and Digital Humanist

Tag: learning to code

Revisiting JavaScript

I first took a crack at learning JavaScript a year and a half ago. I was fresh from defending my Masters, and eager to constructively fill my time between sending out reams of resumes.

It didn’t go so well.

Looking back, it’s not hard to see why. I bought a book, went through Codecademy’s JavaScript modules, and charged right in with a project that swiftly proved far too big and complex for my limited skills. I came out of it thoroughly discouraged.

I decided at the beginning of the year that it was time to come back to it, and do it right this time. 

What does ‘doing it right’ entail, though?

For me, it means taking it slow. Building an understanding of the language. Seeking out instruction and insight into its ‘real world’ applications. Developing a plan for how to apply it in my own work, scaled down to a manageable proportion.

The first part of this new approach has been to go back to that book I mentioned, Marijn Haverbeke’s Eloquent JavaScript: A Modern Introduction to Programming. Instead of just reading it like I did the first time, I’ve been making myself treat it like a course and taking extensive notes.

Reframing the concepts in my own words, and writing out the code longhand, has been the best thing for my understanding of the language. It’s forced me to break down the book into small chunks, which means building up my comprehension slowly with reinforcement and regular, often daily, reminders of the concepts that a given chapter is exploring. It’s drilled syntax and conventions into my head by ensuring I’m writing out expressions over and over. And, by writing out the explanations in my own words alongside the code examples, I’m finding that it’s much easier to actually read through the code with an attention to detail, building my understanding of how all the parts actually fit together.

At this point, I’m on Chapter 11 of 12 of my edition after three weeks of work devoting at least an hour a day. I’m already much happier with my progress. While it’s been hard to resist the urge to start developing code, my grasp of what JavaScript can do and how to work with it is far better than it started out.

I’m feeling well prepared for the next stage, which will begin this coming weekend: actually working with and applying code. On Saturday, I’ll be attending my local Ladies Learning Code chapter’s jQuery for Beginners workshop.

The great thing about the LLC workshops is not just that they provide an inclusive, beginner-friendly space to learn new concepts, it’s that they’re explicitly designed to be a jumping off point for further learning. I’m looking forward to getting a practical grounding in the concepts I’m already working on, and getting pointed to a whole oodle of resources for carrying it further.

The book and I aren’t quite ready to part ways – there’s a second edition with additional materials and a companion website to go through yet – but as of this weekend I’ll be at a point where I’m able to work with the language in a knowledgeable fashion.

I have ideas I’d like to try out, and a website to work on, and I’m excited to see where it all goes from here.

Hackathon, Day 2

As I write this, it is the morning of the second day of the Hackathon. I’ve been able to pursue my idea, but, as these things tend to go, it hasn’t played out at all how I’d planned. I spent last night turning over the first day in my mind, and now I find myself reassessing.

Here were the goals I had set for myself before the Hackathon:

1) Nail down the character, items, NPCs, areas and basic mechanics such as accessing inventory, exploring a room, combat, conversation, levelling up and so forth. Mechanics will be governed by functions and may be simplified further if required.

2) Build a simple, linear game using each major element and mechanic at least once.

3) Build a web interface over the game.

4) Playtest.

5) Expand game, if enough time remains

As of this morning, I’m still on point one, with no realistic way to move past it in the time remaining. The first room is in place, as is the player-character, some plot items and a sample creature. I’ve also roughed out the combat function and the examine item function, and identified where I need to write other functions to ensure those two behave as I need them to.

To be honest, I’m not terribly surprised. The game mechanics I was hoping to implement prove more complex to build than is realistic for the timeframe, even with additional simplifications. I’m thinking I’ll have to go back to the drawing board at the end of this and decide what, specifically, I hope to accomplish, and how I might more realistically carry that out.

I’m not particularly upset about all this. I ended up working with only one other person, Jacqui. Her strength is in project planning and documentation, and she ended up putting together an impressively through document mapping out all the object relationships a game like this needs. It’s given me some serious food for thought. While it would have been nice to have an experienced coder working with me, planning of this kind is so important, and I’m no doubt better off for it. I’m still happy with how much the two of us accomplished, given our respective skill sets.

Today, I’m going to keep plugging away at functions. If I’m really productive, I might be able to start testing one or two. Jacqui, alas, is down with a back injury, so I’m flying solo.

While it’s clear that the task is much bigger than I expected, I’d like to keep going for a bit longer before I decide whether it’s worth continuing this development path. I’ll have to decide once the even wraps up. I want to continue with the idea, and I still think it’s going to be a great way to learn more about how JavaScript works.

The Learning Process in Fits and Starts

As the Hackathon approaches, I’ve been reminded of a few things important to my learning process:

  1. Having something concrete to work on is important to my learning process. Picking up a skill without a clear application or need is lousy way to develop a true understanding of it, at least for me.
  2. It’s okay to walk away for a while, as long as I prioritize coming back. I lost momentum for a week due to Thanksgiving and other demands on my time, and picked my JavaScript lessons back up over this last weekend.
  3. Sometimes it’s best to come back to a problem. This week, I’ve had a string of days where I’ve been stuck on one concept, and instead of beating my head against it, I stopped for the day once it was clear the concept wasn’t gelling. When I came back the next day, I would usually be able to see where I was hung up right away and then move on.
  4. It helps to talk to people already using what I’m trying to learn. A programmer friend was in town last week, and at dinner, he asked me to describe how I was planning to construct my text adventure at the Hackathon. The resulting conversation pointed me toward concepts I wasn’t yet familiar with. When I got to that point in my instruction a few days ago, remembering that conversation really helped me understand the purpose, value and applications of those concepts

It remains to be seen how the Hackathon itself will go. I suspect I understand more than I think I do, but at the same time I’m certain there are still huge gaps in my knowledge. The experience will educate me in both, and likely point me toward a few more things beside.

On CodeAcademy as a learning tool

So, today I finally got back to my CodeAcademy account. I’m pleased to be making progress again, as I’d stopped in the middle of one of the later PHP modules, but I completed two steps before it reminded me of why I ended up stalling last time.

I’ve been using the site as a refresher and alternate perspective. I completed their HTML and CSS modules in short order; while it taught me a few things, it ended up mostly being a reaffirmation that I’ve at least got the basics down. The PHP modules have been a slightly different experience. The introductory modules almost entirely tread familiar ground, but I began noticing that I was having a harder time identifying and correcting problems than I was used to.

Once I was a few modules deep, I realized what was going on: I could have the problem solved correctly, but still produce an error because I wasn’t writing a string or variable name or whatnot exactly as the module had been programmed to expect. Human teachers aren’t hung up on these things, as it’s consistency that matters more often than not, so it took me a bit to realize when I was being failed for writing $somevalue rather than $someValue.

This wasn’t a big deal during, say, the Arrays modules. However, once I started getting to material that was new to me, particularly the Object-Oriented Programming section, a few concepts became exercises in frustration. I would get stuck trying to figure out where I’d messed up my code when I’d actually just used a letter case in my variable they hadn’t expected, or substituted my own string for their suggested wording where they were string-matching to ensure I’d echoed the right text. It began to drive me a little nuts, as I was often naming the relevant variables and whatnot consistently. The code would work, but not according to the lesson. Once I’d slogged through a handful of lessons with these types of snags, I took a break, and the break became weeks while I shifted focus first to my impeding thesis defense and then to post-defense finalization.

But, I still want to learn this stuff. Now that I’m no longer funneling most of my energy toward the university, I’m better equipped to persevere. I’m getting enough out of the modules that they’re worthwhile despite the occasional maddening extra layer of troubleshooting to contend with. I aim to go through at least the JavaScript and Python modules before I’m done with the service.

That said, I’m glad that I’m not coming to programming as an entirely new set of concepts. Getting classroom and work experience first has made it easier to work with the site’s quirks and the odd instructions that lack clarity.

© 2014 - 2016 AJ Dyrbye

Up ↑