1.) Be curious. Stay curious. Experiment, play with things. Your time during university is likely the best time for this and it will likely get harder later on

1.) Be curious. Stay curious. Experiment, play with things. Your time during university is likely the best time for this and it will likely get harder later on when you're on the job and there's much more emphasis on finished work than on learning experiences. Also, I'm quite sure that it will be beneficial for you if you familiarize yourself with different ways of thinking (obviously programming languages, environments and paradigms, but that will likely apply to anything non-technical, as well). I gained this perspective from dealing with people who didn't really do that, but also from knowing that I personally also did this way too late (and from the benefits it brought me nonetheless). If you're only familiar with Windows, try Linux. Try BSD. Try OS X, if you want to. Try working in the terminal. Familiarize yourself with different editors (especially Vim and Emacs, maybe also newer ones like Kakoune). Learn bash, have a look at AWK and sed. Maybe learn Perl. Try out functional programming, logic programming (like Prolog) and so on and so forth. If you're feeling adventurous, play with niche systems like Haiku[1] or TempleOS[2], just to gain new insights on how things could work. Maybe try the ACME editor[3]. [1]: https://www.haiku-os.org/ [2]: https://templeos.org/ [3]: https://wiki.c2.com/?AcmeProgrammingEnvironment Of course, there might be courses that will nudge towards some of those tools. If you visit some of those: Cool! But if there are no such courses (I didn't encounter many of them myself), try to explore these things nonetheless. Even if you won't be using them day-to-day, they will all provide you with new insights and you will likely profit much more from them than only looking at one established way of developing during your studies. Also, don't think you have to get good at any of them. You even might really not like some of them. But still, try them and see what sticks. For example: Give Vim a real shot. If you think that it's really not for you after a couple of days/weeks, at least you're sure now. :) As food for thought: A language that doesn't affect the way you think about programming, is not worth knowing. -- Alan J. Perlis 2.) Really try to become "computer literate". This is orthogonal to whether you are good at software development and/or computer science or not. I mean that you should want to be able to solve small problems quickly with the help of a computer. Make no mistake: I work with experienced, well-educated developers that aren't (at least in my book). If they encounter small problems, they won't solve them nonetheless, because it would be a chore both if done manually as well as done with the only tools they know. For example: When it comes to a lot of plain text things, knowing how to use the UNIX chainsaw [4] is a huge benefit. For things like dealing with data and numbers, it might be Excel, R, Julia or various Python libraries. Bryan Cantrill explains this beautifully here[5]. There are many problems where you want a properly developed solution that will be absolutely correct. But when your problem isn't one of those, you can only lose if you try to approach it as one. In his book "How to Measure Anything"[6], Douglas Hubbard laments the tendency of humans to say "I cannot measure this perfectly, so I won't measure it at all". The same problems also exists with many one-off tasks in IT: People who aren't "computer literate" either do them by hand (a giant waste of time) or not at all (because doing them in Java or the like would take days). And this often includes programmers that (for example) never had a look at AWK or Perl. [4]: https://www.youtube.com/watch?v=sCZJblyT_XM [5]: https://www.youtube.com/watch?v=S0mviKhVmBI&t=450s [6]: https://www.amazon.de/How-Measure-Anything-Intangibles-Business-ebook/dp/B00INUYS2U