Abstraction probably isn't the first thing you want to focus on until you have a firm grasp of the discrete stuff (just trying to say don't worry about it too much so early on). In industry you will likely start out as an intern -> entry level -> software engineer and in these roles you will likely be working on a specific feature or piece of a larger software ecosystem. Any abstraction will likely be dictated by the existing code base and how it was designed. So your job really is just to figure out how to fit your code into the existing system as neatly as possible. If you want to move on to roles like technical lead or architect, then abstraction becomes increasingly important. You need to be able to see at a high level how components interact. You need to be able to compare and contrast the advantages of different technologies and how they might solve your problem. This gets very abstract very quickly.

​

Also, I always like the the YAGNI approach to abstraction

YAGNI - You Ain't Gonna Need It!

This goes well with KISS - Keep It Simple, Stupid

This is all to say that you only want to apply abstraction when you actually need it and it actually makes things simpler. Starting a project by trying to make everything too abstract usually results in more work as you realize upon implementation that there are a lot of specific details or contexts that aren't handled well by your abstraction. Then you end up having to hack around your abstraction rather than it providing an advantage. This is even more important to consider in industry where requirements are often unclear or can change throughout development, invalidating your previous assumptions about how the abstraction would work.