Another "please help with starting out" thread

Definitely stick with the course and see it through. I've known game programmers from all sorts of academic backgrounds besides CS - maths, engineering, signal processing, etc. When it comes to getting a job in the games industry, your ability to code and your personal projects will weigh far more than the title of your qualification. But leaving the course early will look bad, and as you said could also cause problems later if you decide the industry isn't for you.

Doing stuff with Unity etc. might seem attractive, but if you're looking to get into AAA as a programmer then you'll need good C++. That means lots of practice, making personal projects that you can show off (maybe with a public Git repository for example - shows you also understand source control). They don't have to be complete games either - it's more important to show what you understand rather than how good you can make something look. So something like a multi-threaded job scheduler or a C++ reflection system is going to look just as good as a complete fleshed-out game. Maybe even better - you won't be hired to write the whole game, you'll be hired to work on a specific part of it.

Have an think about what sort of programming role you'd like. There are many options - rendering, tools, engine, gameplay, networking, animation, physics, build systems, and more. If there's one specific one you like the sound of, tailoring your projects towards it will look much better at hiring time.

And by 'hiring time' I mean the 2 minutes somebody takes to look at your CV/website/repo to decide if it's worth spending any more time considering you properly. It's critical that you make everything as easy to access as possible. Provide executables - nobody's going to compile your code to run it - and make sure they run on multiple machines without any missing DLLs or any other problems. Make any demos short and to-the-point, showing what they do quickly and obviously. Simple is fine as long as it works and works well.

Write your code with the assumption that someone is going to judge you on it, because they will. If I came across a candidate with the most amazing qualifications but found his code to be a complete rat's nest of single-letter variable names and uncommented 1000-line functions, I'd have serious reservations. Make your code clear, concise, easy to read, well-commented and well-structured. Favour simplicity (readability & debuggability) over complexity. You don't have to write everything yourself (it's fine to use something like SFML for input/output), but make sure you understand the concepts behind any library you do use. For example if you're going for a rendering role and you used something like GLM as a vector libary, I'd want to see evidence in your own code that you already understand the maths being done in the library. Or if you use STL containers, be prepared to answer interview questions on how those containers work, what makes one container better than another for searching or inserting, their memory allocation patterns, etc.

If this all seems a bit daunting, ignore me! Initially anyway - just write a few simple games, and have fun while doing it. You'll end up learning a lot just by seeing them through. I always suggest Asteroids as a good starter - it will teach a bunch of different important aspects of game programming (object oriented programming, memory management, vector maths, 2d rendering, simple physics, collision detection - even some crude AI if you add the aliens), and is still small enough that you can finish it in a reasonable amount of time. It's a fun game too