Design Fundamentals

I’ve been working on a new side project with a friend of mine. I’m thrilled to have found something that’s both an interesting challenge and something good to have on the side. It’s already teaching me new things that I would probably never have the opportunity to explore at work, for various reasons.

One of these things I’ve learned is that there are many things that I use in my coding are things that I take for granted but that are not natural or obvious to initiate coders. My friend is a coder who’s got some experience of coding through College, but I’ve realized that going from initiate coder to Software Engineer takes a lot of experience and that there are many things I’ve picked up along the way.

I got my share of that experience by creating a game engine in a startup, and doing a lot of other mildly complicated things. I had the fortunate position of having a colleague with whom I could discuss all design decisions to the bitter end, and the time to make a fair few mistakes and figure out how to turn them into successes.

What your path to getting that experience is, I can’t tell. Only you can walk that path, but at least I can set up some signs along the way to help. I’ll be starting a new series of posts called Design Fundamentals, where I’ll explore design concept that are fundamental to wrap your head around. Hopefully even experienced coders can gain something from these posts.

The posts will try to gather in one place only what a given design technique or pattern means, but also how to use it, why it’s useful and various tips and trips.

I’ll be using C++ as the language for these posts, as it’s my language of choice. Much of the information may benefit you if you’re coding in another language, and in fact the only recommendations I have for you when it comes to languages is pick one, and make it your native one. Become an expert in one language, don’t try to go wide. There’s a good point in learning to code in a few languages — but don’t make it your focus to become as good in all of them.

This post will serve as an index — all future posts in the series will be linked from here.

• Design Fundamentals: Encapsulation
• Design Fundamentals: Abstraction

Programming Culture

I decided to learn Common Lisp.

After feeling like I’d somewhat gotten stuck in my programming development, I decided I needed to do something well outside my comfort zone in order to get off the plateau. So after a quick look around, I decided Lisp was probably a good target.

Then I decided not to learn Common Lisp.

Here’s why:

I’ve learnt a fair few languages in my days… some have been incredibly useful but scorned by others like Visual Basic, some are popular and have a great following like C++ or Perl. Some are small but surrounded by friendly enthousiasts, like Lua. Some are just generally strange but well documented, like tcl. All of these are different experiences to learn, because not only do the languages differ but their communities differ.

It’s a lot like learning to speak a new language and at the same time discovering the exciting culture that comes with it.

But some programming languages seem to have a more or less arrogant culture surrounding them. They tend to be small languages that claim to be revolutionary yet no one uses them. They’re small and they’ve been small for a long time. Lisp falls into this category. One article I read strongly asserted that after decades, the time for Lisp was just about to come. Soon, Lisp would be the mainstream choice. Pity the article was 20 years old, and the use of Lisp has hardly increased since.

It’s weird that this is the case, if the languages themselves are so revolutionary as their followers claim. I’ve seen it with both Lisp and Smalltalk, and after going through it a second time, I think can explain why: Their programming culture has confused teaching with preaching.

And learning new stuff is really important when it comes to programming… which means teaching is equally important.

Let’s back up a bit… I learned Lua. If you try it, your first move will probably be a google search and you’ll find books online and help pages that in a friendly tone go “here’s lua, have a try, plunge in”. But when you try to learn Smalltalk, the same method will get you pages on why Smalltalk’s design is great. Starting to browse forums about Smalltalk, most of the discussions I ended up reading were about how God Alan Kay certainly didn’t mean for object oriented programming to look like C++ (“lol, what a thought”).

The same thing happened to me when I tried to learn Lisp. Finding several books online was not a problem, Google kindly sent me to a site on learning lisp, and following the advice on that site I started reading through a book online, and in parallel started reading a couple of sample chapters of another book. The sample chapters gave me nothing — some code examples, some interesting stuff, but mainly the focus was on why Lisp is so much better than all the other languages.

When I was halfway into chapter two of the book, it had still not finished motivating why Lisp was such a wonderful language, that the absence of a syntax really is the only way to extend a language and build bottom-up rather than just top-down and how you worked in a completely new way with Lisp and that all other languages were nothing but shallow copies and could your language really do this? And at that point I gave up.

The only feeling I get from this furious defense of the language is a feeling of uncertainty. Why do you need to tell me it’s so superior when all I want is to be shown how it works? Surely actually showing me would be the best way to convince me, especially once I’ve already taken the interest and initiative to go looking for a place to learn?

I have no doubt that Lisp is a good language. I’m still interested in functional programming languages. But I’d rather take on one where the culture and community is open-minded and busy doing kick-ass things with their language rather than telling others how kick-ass it is (or worse, how everything else is crap).

Oh well, F# looks interesting. In the meantime, I learnt a different language and did some really cool stuff.

Level Up

Good programmers continously learn. The defining characteristic about the top coders I’ve met is their complete and never-ending thirst for knowledge of almost any kind. The best way I can think of to describe them would be to say that they’re “interested“.

In the games industry especially, multi-talented people tend to be the ones that rise to the top. The people who essentially pulled Battlefield: Bad Company together during its darkest moments in production were the coder with an eye for game design, the ex-programmer designer, the artist with a feel for level design… and so on.

Looking at the famous people in the industry they tend to have been brilliant hackers that coded a game for the early PCs or Amigas in a basement somewhere, only to go on to become a lead designer for a massive latest-generation console game, not even touching the code. I firmly believe this is because of a never-ending desire to expand their skill set, explore new things, and as such not only aquire a view on how lots of things work, but also on how lots of people think.

Becoming a better programmer has a lot to do with a deep desire to learn, a thirst for knowledge. People often find me curious when I get stuck to a documentary about some esoteric subject like a World of Goo gooball to a cliff… but it’s yet another manifestation of this desire. It doesn’t have to even come remotely close to a subject about code or computers. So in a way, it’s no surprise that the best coders I know tend to also be musicians, artists or have other creative hobbies. World of Goo was made by just a few multi-talented people.

But a good programmer doesn’t stop at learning about things by passive reading or watching… they’ll inevitably have a deep desire to do stuff, and to keep exploring possibilities. And they won’t stop at doing stuff either, they’ll strive to perfect the art of whatever they’re doing.

At the same time, one of the first things one needs to learn is that perfection is ultimately unattainable. It’s this inherent conflict between “refactor” and “hack” that leads to systems improving in iterations, and each step towards perfection is a manifestation of the sum of the learning that’s happened this far.

On the flip side, one of the worst programmers I’ve ever worked with was a guy who (openly) refused to learn, and had lost all interest in learning. He said he just wanted to make cool games, and wasn’t interested in education. The result was that when the rest of the coding team would learn something about the system and advance a small bit, he’d remain behind.

The problem with programmer skill is that it’s incredibly hard to judge without at least peripherally working with the person in question and reading their code. The result of this was that this guy would be given a task, implement it quickly with no regard to all the rules and guidelines everyone else had learned to apply to prevent bugs — in essense he’d do what the rest of us would always consider as hacks. He was well regarded among designers and producers — almost seen as a miracle worker, because he was so quick at getting things done.

Then he left at 5 pm and the rest of us spent late evenings fixing his bugs by essentially removing what he’d done (which was always causing bugs that were hard to track down and pinpoint) and re-implementing the features.

What’s the lesson to take away from this story then? Well, first of all, keep learning! Don’t let yourself fall into a trap of thinking you’re pretty good at what you do, thinking that there’s no reason to learn C#, to look at functional programming or to learn to build levels or even that there’s nothing interesting about Penguins.

And, second, most of the people you work with have no idea whether the coders on your team are all excellent coders or if some are really bad. Shocking as it may sound, it’s up to you to tell them, because in the end you’ll inevitably be the one fixing the bugs at 11 pm as your ship date approaches.