Well, I didn't really troll my teachers because I told them I was gonna do the project in C++ and they agreed, but normally, they want you to do everything in C#.
Yeah, that one is not trolling but just good impression and showing initiative but with right people some slight trolling can apply too, e.g. sending a Pascal program instead of a C one (it was a simple assignment since it was a contest style question where the real task is translating the problem into right algorithm, not implementation itself) to a teacher who you know for sure knows Pascal (but most students these days don't or think it's old/dead language, I happen to know it from high school and use it for one personal program - linked in my forum footer) and getting called a 'connaisseur' jokingly as a result.
Once a teacher even thought and asked if I'm testing our faculty's staff by putting small mistakes into my programs because one of my == was replaced with = in a way that never showed up in the program behavior (it was an actual accident but it was pretty funny and proof I was thought of highly to get asked that).
About SFML.Net, we currently have a project at the ETML where we need to create an algorithm that can generate mazes and solve them. We were supposed to make it in the Console only (which I did), but I managed to finish the algorithm pretty quickly, so I used it to make a game with SFML.Net and C# eheh 
There are many fun algorithms for that depending on what you need. What did you use? I once used Kruskal's minimum spanning tree algorithm (I found it really neat and wanted to use it in a simple retro style game) but with randomly (instead of by weight) sorted edges to generate a random 2D tree on a tile map for this game (exe in last post):
https://en.sfml-dev.org/forums/index.php?topic=20228.0And I was kinda hoping to learn how to write good code at the ETML, but the teachers here don't seem to really give a damn about "good practices", to them it's simpler : It works or it doesn't.
That kinda happens in reality too for various reasons (some good, some bad). And there are some competitive (group) programming contests (I even took part in like 3 or 4 of them, including ACM ICPC CERC like twice and few national ones here) where this is actually how it works (either your program passes or not, and limits and input format and such are known up front so if your program exploded, segfaulted, printed false results, etc. at n + 1 input lines but limits in the task said max n lines - it's okay but in reality you'd of course try to fail gracefully).
And I'm not sure how it is at your specific university but computer science and 'programming' are often lumped together and that causes this gap. There's lots of in between stuff too, like cryptography is kinda math but no one would ever use something like RSA or AES without a program to do it but writing your own requires both math and programming skills to not have either kind of holes in the implementation. Or languages like Haskell and maybe some ML dialects which have some super interesting properties for practical use but are very math-y in their background, related to the entire 'Lambda calculus' thing, etc. Lisp, Prolog and F# have more science-y roots too.
Your not giving a damn teachers might be Ph.D.s who never programmed professionally and are better at theoretical CS, math, know enough C, Pascal, C++, C#, Java, Python, etc. to get by or use for their papers (they might even be Ph.D.s of physics or math, not even CS, I had few like that). Even though I'm a programmer (and that's why I studied) I'm still a (roughly translated) 'master of engineering of computer science' and had tons of theoretical, math and so on classes too (and one physics one) in addition to all the practical and programming ones and my master paper was a 100% math-y CS paper about Petri nets (but my engineering one was a practical one about Lua's implementation) with 0 lines of code in it.
I kinda ended up appreciating the differences too after getting my master's even though they were frustrating at the time, maybe you'll too.
