But what should my friends and I do if we want to become gamedevs(Programmers, we use C#)?

Go make some games.

Is it good to learn alot of basic and advance programming?
Should we for example learn different sort algorithms and such things? To have a good background before jumping into gamedev?

No. Learn those things on the way, while you make games. Things you learn because you have a practical application for them have a tendency to stick better in your memory, and you tend to understand their purpose, pros, and cons much better. They become better-understood tools in your toolbox. There are lots of things that might be useful to you, but only some of those will be useful to you and the games you actually make. There's not a lot of sense in putting off making games to learn some intricacies of the math involved in isometric tile picking if you never make an isometric game.

Math is always good... I am one of those programmers that loved programming but hated most math, and I curse myself often today because when I run into a task that has to be solved with Math, I either need to learn some Math that I should have learned ages ago or (bad idea, but it seems so easy at first) try-and-error my way to the correct solution.

That being said, I am with Josh when it comes to programming AND math. Instead of reading theoretical literature for years and not really getting it, try your hands at a real project, no matter how small, and see what programming and math problems come up with it. Try to find a solution yourself, see how others solve the problem. Learn from it. Do it better the next time the problem comes up.

This way you learn new things, get expirience in real game development (as opposed to "ivory tower knowledge" which never translates to how it works in real life), and you might just get some awesome finished games to show your skills with.

Also make sure you know what you want. Is it programming, art, game design, project management, the business side? You might be able to wear many hats, but you will limit your abilities to become a specialist this way.

Depending on your future goals that might be a problem (you are either employed as programmer, artist or game designer in a bigger studio, not as a Jack-of-all-trades)... it might be a good idea if you want to stay small and get into Indie development though. Be clear to yourself and others what your plans are, and stick to it.

Game development is an extremely iterative process. You can't possibly learn to make viable games without trial and error, thus understanding why/how the things you're doing is right or wrong. Think of it as becoming an engineer, cook or martial artist. Studying it only takes you so far, you must practice it to become better and the best executions are usually not derived from great ideas, but rather great prototyping, iteration and continuous microadjustments. That's not to say that you should never come up with great ideas, just have in mind that you're usually your own worst critic. As for being a great game designer, that's a continuation of being good at development, and both are crucial for your game to succeed.

You first need to be fluent in a language (e.g. C# as you mentioned) and then learn about proper (conventions of) programming methodology. Then you need to be comfortable enough with your coding skills that, every time you want to have something created on screen, you know exactly how to do it properly, efficiently and fast. Structure your code in such a way that each project is little more than a concrete feature in your game, and game test these features to figure out if they work well together (prototyping). With enough projects created and linked together, you will eventually have your game ready for either public testing or ship.

I like to think that you're never really "making a game". What you're making are chunks of functionality - projects or "functionality tropes" that work well on their own. Whenever you add new functionality, you need to fit it into existing design. Sometimes, you even may need to redo your previous features if they make it hard for you to add more stuff. You need to be able to "kill your babies".

You're really engineering a set of "interconnected programs" that cowork within the same user interface and eventually emerges into a game with time, love and a deep understanding of what makes games interesting, ontologically speaking. (Which in and of itself has nothing to do with programming and everything to do with psychology).

So on one hand, game development is extremely iterative. On the other hand, game development is also extremely emergent. "Great" initial ideas usually end up (1) on the chopping block because it fails to execute well in reality or (2) as a feature that works differently or even better than you ever imagined as you thought it up.

Anyways, my two cents. I hope it helps.