CodeClan week 7: learning how to unbox yourself from a corner

As my coding knowledge grows and develops, I've been building bigger things and finding interesting (and sometimes frustrating) corners to box myself into. Week seven is where I have finally been able to unbox myself from these curious little coding paradoxes, because we have learned about inheritance, polymorphism and interfaces.

These handy architectural concepts have allowed me to build larger programs without shooting myself in the foot or writing some horrible Frankenstein code to account for weird wee problems I had previously made for myself. As we have moved on to bigger programs, I've also realised how much I enjoy the architectural side of programming.

Forget the laptop, pen and paper is where it's at

Our instructor Sandy's mantra was more prescient than ever this week:

"One hour of planning will save you four hours of coding."

Our instructor Pawel also has a very nice little snippet, which I think is equally as true:

"Programming isn't on the computer, it's with pen and paper."

Modelling and understanding how my program's jigsaw pieces fit together have been the highlight of week seven for me. I wanted to work on how to construct programs without getting a paint-by-numbers set of instructions, so was set loose on a range of briefs that were top level and required a lot of thinking before building. Pen and paper to the rescue; a lot of doodling does wonders for your coding brain, and writing everything down, planning your moves and getting a to-do list sorted make a big difference.

How do you build stuff? Sometimes its takes more than one go

It turns out that a brief like "Build a fantasy text-adventure game, where characters can slay monsters and collect treasure from different rooms" takes a significant amount of planning to get right. If you model poorly, then things very quickly start to go wrong. We were given this brief on the Thursday of week seven, and I enjoyed partnering up with fellow student Jemma to model the game and start building it. The challenge was great, but I felt we didn't get enough time on it and wanted another go on the game. I decided to remodel it for my weekend homework.

Revisiting the brief was a super interesting learning experience. I paired up with Mike, another student who was also keen to remodel, and we spent the entire Friday planning out quite a deep inheritance tree and associated classes to get the game in reasonable fettle. We built in Java, using test driven development. We used random dice roll methods to give our game an element of chance, and it was a nightmare to test but great learning experience. We also decided to practice our Git, and collaborated on one repo with branching to see how we got on.

Collaboration for the win

Working in partnership for a bigger program was an excellent learning experience. Mike and I worked on separate branches so we were able to build way more, and could get onto juicier logic problems much more quickly than with solo efforts.

Mike also helped to squash some bugs that I managed to concoct for myself (tip: never code when you're tired - you're just magicking up bugs for your future self) and I enjoyed discussing our different approaches to how we'd solve a logic problem and architect the game.

In the end we changed quite a few things from our first efforts on modelling - a deeper inheritance tree (which has its own problems), several enums but weirdly no interfaces. This was very different from my first modelling attempt with Jemma, which included several interfaces and a shallower inheritance tree. See the code on GitHub if you're interested.

Key takeaways

• Pen and paper continue to be my friend. As programs become bigger, I'm not sure how I'll be able to build anything without these analogue tools to help me on my way.
• Sometimes problems seem to be too big to understand or tackle, but if you just keep breaking them down until they are bitesize then you'll get to your end goal. Writing a game with 20 classes felt pretty intimidating, until it was broken down into its constituent parts and then felt completely achievable.
• Don't code when you're tired. It's a waste of time. You'll write rubbish stuff that will just cause you problems further down the road.
• I am enjoying Java very much. I am still missing Ruby, but I do like Java's structured approach to things in comparison to Ruby's flexibility. They both have their strengths, and that's surely why there are a zillion languages out there. They all do something well, right?