1) Algorithmic complexity: Study why naively adding to the end of an array or the end of a string results in O(n^2), while doubling the size when you increase the storage results in O(n). That one tidbit has comprised some embarrassingly large fraction of the "consulting" I used to do working for a language/VM vendor.
2) Graph theory. Study BFS and DFS and implement them a few times to do things like solving a maze. Get comfortable with those until you can "run" them in your head when looking at a problem specified on paper containing a graph, and you can see uses/consequences. This will both keep you out of trouble and can be a starting point for further study.
3) Concurrency. Learn about race conditions and deadlock. Figure out some tools and patterns for dealing with them. Use them to write a chat server and figure out how to automatically QA it until you can break it.
4) Transactions. ACID. Read up on why you have ACID transations, and what can go wrong.
That right there is good for some huge percentage of what could really get you into deep trouble.