I'll start with something that happened a while ago — I met an old colleague of mine over a cup of coffee. Ten years ago he came into game development as a student, but objectively he couldn't cut it at programming, and in the end we had to part ways. We split fairly amicably; let's call him Kesha — he first went into mobile, then into game marketing at a neighboring company, where over the years he rose to become the boss of a squad of workaholics on the galley, but out of some inner motivation he decided to return to big gamedev, which is, in fact, why we crossed paths at the cafe. Over the past while the industry hasn't exactly leapt forward, but it has shuffled a noticeable distance toward a bright future in the embrace of AI; the standards changed a bit, various assistants were added, and life on the whole got more cheerful, in places even without crunch. But Kesha came back essentially with the knowledge of a final-year student, yet with a lot of gamedev experience in how to sell an already-made game on the last mile — but this article won't be about that, rather about how a young or not-so-young specialist gets into development.
And this gives a reason to talk about a situation that directly concerns many of us — game and game-adjacent developers, forgive me, I'll be praising my own swamp — and even now, when we have all sorts of smart AI assistants like ChatGPT or Claude that are supposedly meant to simplify everything, the problem hasn't gone anywhere and has even become more obvious, because if you look at it from the outside, you get just some theater of the absurd, and a rather sad theater, to be honest.
On the one hand, an engine, animation and gameplay programmer is literally one of the most scarce professions in the industry right now; to give you an idea, on average the shortage across studios is more than 20% of mid and senior positions, i.e. at least one specialist is missing in every team, wherever you poke. And the folks from Epic Games, Unity, CD Projekt and other major studios constantly complain that they can't find decent specialists who can really work with modern engines, and they're ready to pay insane money (insane by US standards, of course; in the old world everything is more down-to-earth, but the trend is the same) to those who get graphics or can write multithreaded code that won't fall apart in production, or know how to squeeze a couple of extra frames out of the hardware — but there still aren't enough people, and that's despite the fact that there are very, very many who want to work in gamedev.
On the other hand, and this is the funniest part, no one actually teaches proper programming anywhere, and if you walk into any programming department at an average university and look at the lecturers, you'll very likely discover that most of them never worked on real projects themselves. That is, they may know — and probably know well — algorithm theory by heart and can tell you about sorts and search trees, but they've never sat until morning before a deadline hunting a memory leak that crashes the game only on a specific hardware configuration, never dug through someone else's million-line legacy where there's no documentation and never will be, and half the comments are in "Chinese," because reading those English verses is impossible, and never optimized a renderer to squeeze out a stable sixty frames per second from the potato that console folks call a devkit. And ChatGPT, Cursor or Claude are blocked for many by the infosec folks, because of NDA, and you can simply be asked to leave your job if you're caught "AI-cheating."
It's clear where the roots of this situation come from: if a person can really write code at the level where you get paid decent money for it, then in our reality they'll most likely go work at "Smart Cat" rather than teach at a university, where the salary is several times lower, and you want to eat and want a new PC and generally need to live somehow. So you get this vicious circle where those who can — do it and earn, while those who teach mostly never did it in combat conditions, which sounds rather sad.
It's not always like that, and I personally know lecturers at Stanford, at our ITMO, SpbSU and MIPT who really made top games and continue to consult for companies; you come across folks who built a career in big tech and then decided to teach. But even that doesn't really save the overall picture, because here another problem crawls out: finding people who are simultaneously cool programmers and also able to explain complex things in simple words — that's roughly like meeting a hedgehog in the middle of an IT office; theoretically possible, but in practice a very rare situation.
The thing is that a good developer and a good teacher are two completely different sets of skills that often don't overlap at all, and when you come across a person who can write efficient code and also explain it so that a humanities major understands, who senses the audience and knows where to slow down and chew it over in more detail, then that's a truly unique specimen, and you can count them on your fingers. Here I fibbed a little, because I also know many good developers and game designers who are humanities types — yes, they're bad at math, but they offload all the math to others while creating very complex game systems and mechanics.
But even if you're lucky and have such a golden lecturer, he alone still can't change the established system, because around him is an academic environment with its own rules, bureaucracy, standards, and even if he were Alexandrescu or Meyers himself, but the whole department lives in the paradigm of twenty years ago and considers it normal to teach students forty-year-old languages (although C++ was also born in 1984), then one sensible lecturer won't break this behemoth, no matter how he tries.
And there's another moment, when schoolkids come to enroll in programming majors with no idea at all what they'll have to do, because at school either programming isn't taught at all, or they're shown some Scratch and taught to print Hello World in Python, believing that this is programming — though it's roughly like teaching a person to write the letter A and saying he's now a writer, well, you get it.
And it turns out that programming isn't at all the kind of activity you can teach anyone who wants it; here you need specific abilities and a certain cast of mind, and, to be honest, all the developers I know are slightly strange people in a good sense, because they get some unknown buzz from a process that to most normal people seems like torture — I mean when you have to sit for hours and think over the code, or look for why your game crashes only on one model of video card and only when the player turns the camera at a certain angle, or when you spend the third day catching a race condition in multithreaded code that reproduces once in a hundred runs; an ordinary person after that would go study to be a blogger, but a programmer for some reason gets a kick out of the process itself.
The saddest part is that it's practically impossible to tell whether programming suits a person at the entrance exams, especially when the basic exams are math and physics but not programming at all (honestly — physics interests me now only in terms of how much it slows down the engine), and even if you conduct some interview, a seventeen-year-old applicant won't be able to demonstrate whether he has an aptitude for this or not, and it becomes visible only when a person starts digging into non-trivial problems on his own, figuring out someone else's code, working with large systems, and usually this shows up somewhere around the second or third year of real work — yes, you heard right, the person has already finished university and stewed in real problems. In the West, by the way, they at least partly solve this problem by letting students relatively freely change their specialization and have practice at university-affiliated companies as early as the second year. You spend half a year, realize that programming isn't your thing, switch to something else without losing time and without being expelled, which creates a natural selection, and only those who enjoy it remain.
With us, though, once you've enrolled in a major, that's it, you're tied for five years; theoretically you can transfer (I myself moved from networks to software development this way), but in practice it's such a quest with obstacles that most simply keep suffering in a major they don't like, and in the end only about five to ten percent of students in programming majors actually go into programming, if you're lucky; the rest go into management, into analytics, or into a different field altogether. And I observed this in my own group at the computer engineering department of ITMO, and that's despite our university being considered one of the top ones for training programmers.
Here we come to the most interesting part, namely that there are serious grounds to think that teaching programming within ordinary university education is generally impossible by the very nature of this occupation. That learning programming differs greatly from studying academic disciplines — it's not theory you can learn and pass an exam on; it's more like mastering a practical skill where constant hands-on work matters.
The analogy that fits better here is when you learn to play the guitar: you can read books about chords and watch videos with song breakdowns all you want, but until you YOURSELF take the instrument in your hands and start pressing the strings until your fingers hurt, you won't learn to play. Even that is sometimes not enough, and very often you also need someone who shows how to hold your hand correctly, what movement to make with the pick, how not to mute the neighboring strings, and all of this is transmitted only through direct observation and practice under the guidance of someone who has already walked this path.
In gamedev this is especially noticeable, because there's an established practice that when a newcomer comes to a studio, he's attached to an experienced developer, and for the first months the junior (or even mid and senior) mostly reads code, watches how the mentor solves problems, and does simple bug fixes and small features. They're let near production about three months in, or even later, unless of course it's a startup. Meanwhile the mentor checks the commits and teaches the careless apprentice some sense: why this architecture isn't great, why this code will be slow, why it's better to use this crooked code here rather than a beautiful idea with frills out of Meyers. And through such a system of mentorship a person grows into the team over half a year to a year, starts to understand not just the syntax of the language but the nuances, the culture of writing and how the code actually works.
Try to reproduce such a model at a university, where a lecturer has a hundred students in a stream and simply physically can't give each one personal feedback. Where there are no real combat projects to learn on, but there are training exercises that are as far from reality as the Moon is from the Earth.
So my conclusion, which I've observed throughout my career, is this: programmers are made mostly through self-teaching, when they themselves look for information, themselves figure out the documentation, themselves write their own projects, themselves find bugs there and themselves learn to fix them. The university here plays the role rather of a place where you can find like-minded people and chat with fellow fans, exchange experience, but real growth begins when a student, after a class, goes and sits down to make his own engine, or contributes to open source, or makes a mod for a favorite game, or solves problems on various platforms.
In gamedev there are plenty of examples of people without higher education becoming legendary developers — take John Carmack himself, who created the engines for Doom and Quake and became a genius of graphics programming without finishing university at all, or look at the indie developers who taught themselves everything from tutorials and the Unity or Unreal documentation and released successful games. Because in programming a diploma is just a pass to the interview — or rather it used to be, but the suits broke everything again — and at the interview itself they'll grill you on algorithms, ask you to write code, look at your portfolio on GitHub, and everyone will be deeply indifferent to which university is on your diploma and what your GPA was. Everyone is interested in only one thing — can you solve problems.
So this is the picture we get, where the university is more of an environment and an opportunity for self-teaching than a transfer of ready-made knowledge, and if you understand this and take responsibility for your own learning, then you have every chance of becoming a good developer; but if you wait for someone to teach you everything and chew it all over for you, then at the end you'll get a piece of paper, a GPA and disappointment, because the industry expects real skills from you, and all you have is the knowledge of how to write a bubble sort in Pascal from textbooks that managed to go stale before they were even printed.
← All articles