T w e n t y S i d e d

The procedural city project resulted in a lot of people emailing me who wanted to know how to get into programming. How to learn? What language? What books are most useful? How do you learn about graphics programming, specifically?

Those are all big questions. I guess the first thing I’d do is make sure you know what you’re getting into. Graphics programming is a very specific sub-discipline of general programming, and jumping right to the graphics stuff is a bit like trying to learn heart surgery before becoming a doctor. It can certainly be done if you really want to learn that way. (Unlike heart surgery, you don’t have to worry about being sued by bereaved next-of-kin for your newbie mistakes. You’ll just crash people’s computers. And Microsoft has proven you can’t go broke doing that.) But jumping into “graphics programming” before learning “programming” is probably not the smoothest route to knowledge. Learning programming isn’t quite the mental challenge medicine is (one assumes, judging by their relative salaries) but like any body of knowledge it does take time to acquire.

Aside from a few COBOL courses in school, I’m entirely self-taught. (The one language I was taught – twice – is the one language I don’t know. I couldn’t generate a single valid line of COBOL to this day.) I imagine the self-taught route is what you have in mind if you’re emailing me. If you were looking for formal education then you’d probably see your guidance counselor or shop for a college. Being an autodidact is fine for enriching your knowledge and understanding of the world, but slightly bad if you’re looking for a career. Even at 37, my earning potential is probably lower than someone with the same experience who can wave around a ~4 year degree. Whether or not that increased earning potential of a degree is worth the risk and expense of taking out loans to pay for one is a really complex question. I come down pretty firmly on the “no” side of the argument, but a lot of coders would argue with me. And the successful ones generally make a lot more than I do. QED.

Jumping in and learning a modern professional-grade language can be a bit much. In the 80’s, most kids were introduced to something much simpler, like BASIC, Logo, or (if they’re quite young) Turtle. I don’t know what kids are taught these days. The point of learning one of these simpler languages is to teach you the basic premise behind programming without getting too bogged down with technical details at the outset. Once you have your head around the idea that source code is a list of instructions that the computer will follow unerringly no matter how wrong they are or what you really intended, you have the basic tools to go learn something useful. It’s a bit like learning to play the piano before you learn another instrument. A piano provides an obvious and straightforward expression of the notes at your disposal, and you’ll usually have gotten a head full of music theory by the time you’ve learned to operate the thing. Then you’ll have a nice foundation to work with while you learn something less straightforward, like string instruments or anything powered by your lungs. In any case, this is a tradeoff: You’re reducing the steepness of the learning curve in exchange for making it longer.

So, assuming you want to learn some graphics programming, don’t mind investing time in generalized programming first, aren’t afraid of a steep learning curve, and aren’t looking to score a degree, then my advice may be of some use to you.

C++ is a good starting language, although there are enthusiastic adherents to many other languages. C# and Python are notable in that both of them can be used to write modern graphics programs. I still recommend going for C++, if for no other reason than the network effect will make it easier to find tutorials. Working in C++ also makes it easier to find unhelpful jerks who will offer snarky answers to earnest questions, which is a major improvement over the smaller languages where you won’t be able to find anyone at all.

I suggest starting with Teach Yourself C++ in 21 Days. Partly because it’s a great book (aside from some nitpicks with the way and the rate at which complex concepts are introduced) but mostly because it’s freely available online. You can also get a dead tree copy, which can be handy. Don’t be put off by the “21 days” stuff. You can blow through the first half-dozen lessons in an afternoon. Things will slow down after that, but the “21 days” stuff is by no means a hard figure and can vary a great deal on how much prior knowledge you have going in and how much time you put into it. I’ve purchased a few copies of the book and given them away to aspiring young programmers over the years.

Sadly, I’ve never found good books or tutorials that teach the concepts beyond language syntax. So, after your 21 days you’ll know how to write a program to balance your checkbook or play blackjack, but you’ll still have no idea how to structure your program by breaking it up into different modules. (That’s fancy programmer talk for putting the source code into different text files.) You’ll have learned nothing of the code formatting holy wars or the particulars of the 1,487 different ways to name variables, each of which has their own zealous adherents. You won’t know about LIB files, what they are, or how to use them. You won’t know about development environments, or MAKE files, or how to read a debug stack. You’ll probably have some idea of what a DLL file is (all windows users have those things floating around on their hard drives like so much driftwood) but you won’t know how to link to one. You won’t know how to really debug your program. (Although you’ll think you will.)

That stuff is 90% of the job, and all of the books and tutorials are focused on that first 10% of learning language syntax and knowing what to type. There are books for refining existing skills in some of those areas, but they’re very much deep-end books that will lose a newcomer in a few pages. We have lots of articles for turning people into programmers, but very little for making them any good.

Thankfully, you can pick up most of that higher-level stuff as you go. I did. (Although I still can’t make use of a debug stack, even after all these years. And it’s not for lack of searching for someone who can explain it in English.)

Once you have some basic knowledge of C++ programming, you’re ready for the graphics stuff. At this point, there is no better place to go than NeHe productions. This is where I went to learn OpenGL. The tutorials on NeHe are some of the best programming tutorials you’ll read. It’s true that most tutorials suck, but the ones at NeHe (particularly the early ones) are simple, compact, straightforward, generously documented, and fun. You can simply download the code and make use of it, or you can read through it on the site along with the instructor’s commentary and explanations. (I highly recommend the latter.)

The site will let you learn by reading the commentary. Or you can learn by example through reading the code. Or you can learn by doing by playing around with (say) lesson 3 and seeing what happens when you plug different numbers in. NeHe isn’t just a collection of the best graphics tutorials around, it’s some of the best programming tutorials of any kind, period. It’s a site that focuses on teaching, rather then simply shoveling information in your direction.

Good luck.

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.

Allow me a rant on technical documentation. This has been bugging me lately, and I thought I’d lessen the irritation by inflicting it on you.

The stereotype is that technical people are bad at writing documentation. Technical people are supposedly inept at organizing information, bad at translating technical concepts into plain English, and useless at intuiting what the audience needs to know. There is a reason for this stereotype. It’s completely true.

From manual pages to tutorials, most prose intended to teach the reader something technical is so poorly written that it might as well be in MD5-hashed Cantonese. People have been emailing me for advice on how to learn X or Y in the field of programming. It’s a bit frustrating, because often there is no decent place to send them for the knowledge they desire.

Sometimes people say things like, “Ah man. I tried to learn [programming or scripting language] but it was too hard. I’m just not smart enough to figure that stuff out.” But in many cases I think the problem is less with the student and more with the teacher.

At my day job, I have a primary duty and eleven hundred secondary ones. One of those duties is writing documentation. I do not claim to be a master, but There is a pattern that should be followed when presenting information to a reader. You need to give them an overview of what this document is about so that they don’t waste five minutes reading the thing before they realize they’re on the wrong page. There needs to be a raw presentation of the knowledge (syntax, usage, that sort of thing) and then the in-depth details on the thing, followed by a few working examples. Finally, there should be some links to other related documents in case this isn’t what they were looking for.

Some of my pet peeves:

1. Assumption that the reader will have prior knowledge of some area not directly related to the tutorial. Under no circumstances should you require the user to have a grip on concepts more complex than the one you’re trying to teach. If you’re explaining how to use gas stove, don’t write directions that include “Step 3: Cook dark chocolate soufflé with raspberry sauce.”

2. Writing production-quality code to serve as an example. This is probably the result of someone having “good coding practices” beaten into their heads in college. They learn heaps of dogma about what you “never” do when writing code, and apply that thinking to tutorials. If they were asked to provide a working example of an internal combustion engine, their docs would be the blueprints for a Ford F-150 pickup with fuel injection, anti-lock brakes, power steering, and all the other complexities of modern vehicles. It might be a working example of an internal combustion engine, but it’s not a useful one. It’s much too bloated and complex for the purposes of teaching. A tutorial should be cut down to contain only the concept being demonstrated and the bare minimum of code needed to support it.

Windows interface programs are really bad at this. I once saw one that was supposed to show you how to implement a simple slider control. The full example was a working sound player that let you browse your computer, open wav files, and start and stop sound playback. It had to interface with special libraries for loading and playing sounds, and had lots of little control buttons to access the various features. All of that, just so it could show you a slider control that was used to govern the volume. (Or panning. I can’t remember now.)

3. Over-organization of code. It’s really annoying for someone trying to learn to have to track activity over several source files. Perhaps the tutorial is there to demonstrate how to calculate the distance between two points in three-dimensional space. They start at core of the program in main.cpp, which then calls something in distance.cpp, which references vector.cpp, which at last leads them to math.cpp and the four lines of code they care about:


float delta_x = x1 - x2;
float delta_y = y1 - y2;
float delta_z = z1 - z2;
return sqrt (delta_x * delta_x + delta_y * delta_y + delta_z * delta_z);


Thanks a lot, pal. Why didn’t you just say so in the first place!?!?

I messed around with the DirectX API in the late 90’s, and those example programs suffered from this. Example code should be reduced to the bare number of files possible (one, ideally) and have the minimum level of call depth. You’re trying to teach someone else, not add a shipped title to your resume.

4. Over-use of jargon. Many, many programming tutorials suffer from this. Supposedly there to introduce newcomers to the discipline, they throw words like “rasterization” and “frustum” at the user without the slightest explanation. The reader will need to know these things, but just tossing out these words instead of paraphrasing in non-technical terms (or taking the time to teach them) simply introduces the question of who exactly is going to read this? Anyone sufficiently knowledgeable to parse the text is likely past the point where they need the tutorial.

Terrible: Terms are presented without explanation, leaving the user to try to decipher what is being said; turning the whole thing into an exercise in cryptography.

Acceptable: Terms are defined within the prose, making the text longer and less readable.

Good: Terms are defined at the start of the document, where they can be skipped or studied as needed.

Ideal: Terms are presented as hyperlinks to definitions.

5. Mixing high and low level concepts together. If you’re explaining malloc (), don’t spend three paragraphs talking about memory management and portability issues before you get to the point. If you’re explaining the finer points of memory management, don’t inflict the nitty-gritty details of how to use malloc () on the reader.

What are the worst docs or tutorials you’ve ever been obliged to read?

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.