A picture of Dragsö across the water from the university (image borrowed from Svetlana Zivanovic).
This is a post about the talk that I gave in Sweden, 11th November 2015, with programming advice for students from experienced game programmers; Niklas Lundberg, John Romero, and Ivan-Assen Ivanov. Slides: pdf pdf with presenter's notes.
The talk was for about 60 3rd and 5th level students taking engineering, games, and technical artist courses, as well as staff, from the Department of Creative Technologies at Blekinge Tekniska Högskola in Karlskrona, in the south-east of Sweden. I was hoping to be a bit provocative and start an argu-scussion by being a bit challenging, but they just kind of liked it in the end.
I used to work at BTH and I know the staff involved in the programme are very good. I made a note in the preface of my OpenGL tutorials book that I actually learned shader programming there when working with the graphics course. So, I felt my go-to topic of graphics programming was covered very well already, and I scratched my head thinking of another good topic that I'd given a lot of thought to and might be interesting.
I was introduced to programming in my second year of university which means that I've been programming for 13~14 years. I really enjoyed the subject right away and found myself spending a lot more time with it and fancied myself pretty good at the topic. Then came the years in the wilderness. I wrote a lot of code, a lot of grossly over-complicated code, and tried all of the design stuff that was in vogue. I suppose around the 10-years threshold I could see the gulf between where I was in terms of experience and where I wanted to be. So I consciously (and very critically) re-evaluated the way I was working. I could see that high talent and achievement didn't come from some innate ability but from thousands and thousands of hours of experience - far higher than what I'd earlier expected. I started putting in a lot more hours. About 4 hours coding a day at work, then 2-8 more every evening during the week, and some weekends for game jams and the like. I spend more time programming than anybody I know (and I work in Computer Science departments). That amount adds up really quickly over a couple of years. During this time I wrote the e-book of OpenGL tutorials which has sold about 3000 copies, and taught the graphics course for a semester at Trinity College. Teaching and explaining seems to double the skill value of your hours of experience. I think I'm about 13k hours of coding at this stage.
There has been a return to simplicity in my code - weekend game jams taught me to code very, very quickly indeed. I challenged myself to make an entire game from scratch in these game jams (some of them are playable online here) - WebGL and OpenGL, not using some game maker toolkit or engine like everyone uses. OpenGL and WebGL taught me to master memory organisation and addressing, parallel programming, asynchronous programming, and respecting low-level hardware operation and pipelines. These kinds of tasks are enormously time-intensive and if you want to finish anything at all then there is no room for whimsical on-paper designs, abstract factories, UML, methodical wrappers and interfaces, etc. none of which actually line-up to the kind of abstractions we use at this level of programming (or any good programming, really). Everyone learning graphics starts making some forced, awkward class wrapper functions framework-engine three-ring circus that eventually gets all tangled and catches on fire before they give up and write in blocks of plain code. I felt like I'd broken through a plateau anyway, (if you'll allow me to appropriate an analogy which we use in physical training) because I was making huge bounds forward in progress again. I had rediscovered the early joy of spending all my time writing the actual logic of the problems I want to solve, and none of it on the laborious structure and refactoring that we're taught to do.
I have completely thrown out all the advanced design [bullshit] that my university made me spend approximately 1/2 ~ 3/4 of my degree learning. One gets the impression that academics create these over-engineered fantasy subjects as an intellectual safe haven from scary and hard pragmatic programming topics. It's really annoying for me to find this out after a huge amount of learning-the-hard-way time because they were really damned expensive and we have to mortgage our futures on good faith against these courses - I've been in really deep student loan debt since I was 18. Experience has not been kind to their evaluation as financial investments. One thing that nags me is that these subjects are seldom challenged - they are all taught as law. Perhaps I would have changed degree if I had an authoritative source challenge these things early. The fact is that people get their feathers majorly ruffled if we so much as dare to question the tenets of orthodox software design - how ridiculous!
Of course, we students and programmers are not blameless - our own obsessions with needlessly organising and adding complexity are central to our problem, and it seems deeper insight must really be learned from experience, and can not be taught, but perhaps I could at least suggest early on that these tendencies are a problem. So this was my idea! This was something genuinely valuable I could impart - I could be that dissenting voice that introduced some different thinking - Programming I Didn't Learn in School.
I was happy styling myself as the one eccentric Luddite programmer in department, but it seems to be a common phenomenon. I discovered a lot of very interesting talks and articles by game programmers on the same topic of getting to this point of experience where you realise it's all overcomplicated and simplify, or that there's some threshold period of time before you are ready to write good software. I heard Brenda and John Romero talk at Dublin Institute of Technology, and one of John's remarks stuck with me - that the fresh-faced students in the audience should be spending four hours a night coding in addition to their studies. That they would need ten years experience before they could break through - I could see from the look on their faces that that wasn't their plan or expectation! I read Masters of Doom and found that actually, those early 20-somethings had all been coding for ten years before they got together to make games. I will link a few more interesting sources at the bottom of this post.
To reduce my personal bias and avoid just presenting a rant of my latest academic's opinions (as above) to students interested in the game industry, I decided to rather ask some very experienced, active game programmers for their views on the topic of keeping it simple, on working expediently, and for advice that students wouldn't get at school. I tried to ask programmers I knew would have somewhat different, yet strong, opinions weighted with some industry experiences.
I've been working on a hobby game called "Crongdor the Barbarian" for about 5 years as my kind of deep-learning background project, so I tried to shoehorn in a few barbarian-related bits for a bit of theme. I recited (in my best James Earl Jones impression) a scene from Conan the Barbarian (1987 movie). I made a very tenuous talk subject connection to Thulsa Doom (Jones' character) condescending to Conan, who he sees as a foolish young upstart "Ah, it must have been when I was younger!" I liked the idea of comparing the quest for the philosophical Riddle of Steel from the movie to the quest for the ultimate over-complicated structure of programming that we have in our hot-headed university years, and this older character saying that it was all folly - "What is steel compared to the hand that wields it?" "That is strength boy, that is power!"
So the central point I wrapped around my mini-interviews was that programmers are very vulnerable to getting "carried away" with sorting and ordering - in fact that's part of the buzz we get from programming - but that it isn't necessarily productive work, and we should rather try to get that same buzz from simplifying and reducing the complexity our code, rather than adding to it.
The class representative asked if I would do another talk for their society! It takes a whole day to get to Karlskrona from Dublin unfortunately, but it was a fun trip.
I'm sure I've forgotten something - if I find more interesting links to thought-provoking stuff I'll add it to this page later.