I’ve been doing quite some thinking about things, and considering the interpretations my post from the other day has got, and some of the speculations going on I’ve decided to take it and the followup post offline. I’ve tried explaining my viewpoint on it, but it hasn’t seemed to make much of a difference.
I love being able to communicate with fans of the games I make, and I certainly won’t stop communicating on how to make the best games possible for all of you guys.
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.
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.
We do code reviews of all code that’s about to be checked in. It’s interesting to see the different approaches to code reviews different coders have. Many (especially junior) programmers tend to lack the self confidence required to go about a code review in an effective manner.
Let me explain that — why would a code review require self confidence? Well, a code review will go over a large amount of code at times, and your job as the reviewer is to find any question marks that might possibly cause any kind of trouble. This is, apparently, a problem for many programmers when they review the code of another (usually more senior) programmer, since pointing out potential errors or problems is seen as somewhat sensitive. I know many coders get very emotionally attached to their code.
You would think this should be something which happens only to junior programmers, but I’ve seen this happen with relatively senior programmers as well. It’s more about character than it is about experience I guess. The reasoning is “I don’t understand this, but this guy’s smart so it’s fine” or something similar, sometimes connected to how much code there is to go through and how long that would take.
However, the quality of a code review is directly proportional to how much you can disconnect your own respect for others. Your task is to understand everything you get shown, and to be the most nitpicking, hard-to-please obsessive-compulsive asshole the earth has ever seen for as long as the code review lasts.
Sound like something you don’t want to do? I hope so. But remember, you’re doing a service here… if there are bugs, someone is going to find them. We have QA people who specialize in finding bugs and piling them up on your desk, producers with a great attention to detail, and if nothing else you can bet someone will find it and it’ll end up on youtube. I don’t know about you, but at least I’d want to see my errors pointed out to me before I check them in.
So here are my tips for doing a code review:
- Understand everything. If you don’t understand something, make the reviewee explain it again in a different way. Chances are, you aren’t understanding because there’s something strange going on, or because what’s been done is unnecessarily complicated. Either way, if you don’t understand something you can’t guarantee that it’s right. Part of the purpose of a code review is for the reviewee to explain his thinking, and while doing so make for a possibility that he or she discovers errors as well.
- Be picky. Point out all details, from naming convention errors to coding standard misses to comment spelling errors. Whenever something gets checked in, the cost of changing it is a lot higher. Often the details may be the things that are wrong, and being picky forces you to notice such things.
- Look at everything. Resist the temptation to skip files where only small things have changed, but like I mentioned above, the details can often be what’s wrong. I can’t begin to count the amount of code reviews I’ve done where we’ve found inverted if conditions and equally dangerous things. The relevant code is simply a missing exclamation mark, but the consequences are far reaching, and if you had skipped the file because it had almost no changes in it, then you would have missed it.
- Endure. If you feel like you’re being a pain in the ass, think of it as a great favor since the amount of potential bugs you’re stopping is high. It’ll also act as an incentive for the reviewee to focus more on code quality for next time.
Think of yourself as the guardian of quality, personally responsible for the quality of the code you’re reviewing. Imagine that you’ll be the one yelled at if the code is broken, or the one who’ll be put to fix it.
The end result will be much higher quality code.
I’ve been asked a fair few times how to get into the games industry. It’s one of those job sectors where there’s tons of people who want to work, but still a shortage of people due to the lack of actually qualified people. Some of this is because there’s been a lack of education, some because it’s a somewhat harsh business to be in with a high turnover. Either way, it means there should be openings, if you’re interested.
So how do you get in?
The answer is very dependent on what you like, and what you do. The lack of education for designers has been solved lately with game design schools popping up like mushrooms all over the place. That creates a new problem though, as some of these schools aren’t exactly viewed as top notch by game studios. If you choose to go that route, be very careful about what school you pick.
If you’re a programmer, however, do not go anywhere near specialized “games” schools. What you need is a regular Software Engineering / Computer Science college. Don’t make the mistake of thinking that game coding is some special form of coding, that doesn’t abide by the normal rules of code. When choosing classes, go for anything in connection to games — graphics courses are common. Take anything they have with low-level programming and hardware. And take at least one programming project course.
Regardless of what education you end up in and what field you’re in, I have two generic pieces of advice that should apply to just about everyone:
- Have a side project.
- Put your heart into it.
I’m not going to claim this is the only way you can do it — but I’ll offer you a way that’s very effective if you’ve got the energy to stick to it.
And by side project, I don’t mean “implement space invaders”, I mean make something about two levels above your own experience and ability, and a lot larger than anything you’ve ever made before. Get at least one other person on board in the project, and work hard on it, reworking it and trying to perfect it.
The point of doing this is not the project itself, though it certainly helps to have a major project to show as a demo when talking about getting that job, the point is the experience you get while doing it. There’s a range of vital skills that nothing in any formal education will teach you, so you better get those skills for yourself.
I teamed up with a classmate and started writing a game engine while I was in college. It turned out to be a project that lasted four years, and that with a bit more luck could have led to something more than just a side project. The experience was invaluable.
Trying to tie your courses and your side project together is also a worthwhile enterprise. We ended up doing a number of home works in several 3d graphics courses in our game engine, and even made a game prototype as a software project course.
Put Your Heart Into It
Lots of students seem to go to college more for the college parties than for the college studies. That’s fine, in a general sense, but if you want to get yourself set to get any highly sought-after job, really, you’ll want to do everything you do with a sense of perfection.
Make it a goal to do well even on the difficult and boring things, and to excel on the interesting things. Take one step further than you really need to, and if things are interesting, keep walking even if it seems silly. Far too many people stop when they’ve completed an interesting task because that’s as far as they needed to take it, even though they were interested in the subject and could learn more by just keeping at it.
If I were to describe my method of doing things in college in one word, it’d be “Overkill”.
An Exceptionally Stupid Idea
Let me illustrate the above with a story.
In a course on mechanics we were making differential equation solver calculations on a housefly walking across a surface — calculating how the limbs and body moved while keeping the feet steady. The calculation application we were using was fancy enough to include a 3d visualization of the process. Cool idea, but to someone used to working with 3d graphics engines it was brutally ugly.
So the afternoon on the day before we were due to present it, we got an exceptionally stupid idea: “Let’s render this thing to a movie instead — it’ll look sweet”. The presentation was the morning after, we had the Solaris environment on the Sun boxes in the computer rooms to toy with, and my incredibly underpowered PC laptop… not much to cheer for, when looking for 3d graphics tools on a tight notice — but we did have POVRay on the Solaris boxes.
We looked at the file format of our calculation tool, looked at the povray file format, and set off writing a converter. A number of hours, a break for pizza and lots of fiddling later, we had a converter and something that key-framed each frame into a separate povray source file. By now it was evening and the place was near-empty.
We ray traced the first frame. It took a disheartening amount of time. We had a couple of minutes of video to render, which turns out to be several thousand frames. I don’t remember the exact numbers now, but at the speed we were going, we’d be done a few weeks later. Give up, go home time?
Not for us. We had a near-empty room full of Sun workstations, and a way to run remote commands. So we tried to build frames remotely, but had no way to make a direct copy to the computers. Home directories were on a tight quota, which meant we couldn’t work online.
So we set to work creating a script that set up packages of work, copied them onto the home directory, started a remote job which copied the package to a local temp drive on the remote computer and rendered the frames.
We shipped packages to every free computer in the room, which was basically all of them by that point. Midnight came and went with a frightening speed. Still not good enough. A scan of the computer net confirmed that the rest of the rooms were as empty as the one we were in — so a list of computers with no-one logged in later we’d shipped off packages to every available computer on 3 floors, and 100+ computers were happily chugging out frames for our video.
By sunrise the next day we’ve got thousands of frames of video data spread out across every computer on site. An epic struggle of sending off remote jobs to copy these onto the network home drive started, moving them down onto my laptop as soon as they were online. We managed to get them all copied in time, and set the laptop on encoding them all into a video file.
Encoding videos isn’t the quickest thing you could do, and on a laptop at the time it was painfully slow. It was still building by the time the class started. Clock’s ticking, and the progress bar’s hardly moving… but our presentation was scheduled for the second of two hours of class, so we let the laptop encode as the first presentations were held.
In total, working all through that night, we managed to get the video together with 15 minutes to spare. And it did indeed look sweet. People went “ooh” when they saw it.
So what was the point of the entire thing? We had been done with the actual assignment before this story even started. We had the idea at about the same time anyone else would have stopped because the assignment was done. It didn’t give us any academic benefits. But we learned a lot. We took on a challenge and grew with beating it.
By the time we were forced to give up the development of our game engine, and I went to work on Battlefield: Bad Company for DICE, we’d already created a fully networked multi-player hovercraft racing game with fully scriptable game modes that had error-correcting network transfer, could automatically send you any maps or game modes you were missing when you joined a server and worked on Windows, Linux, Mac OS X and Solaris.
With that kind of experience and track record, getting a games industry job won’t be hard, and performing far above everyone’s expectations will be something that comes naturally.