I also dislike unnecessary use of programming jargon. A type constructor is all the possible ways to make a value of that type.
For example:
type answer = | Yes | No | Maybe
The type is 'answer'. The constructors are Yes, No, and Maybe (these are actually called type variants but now we're getting into jargon). I presume an 'abstraction over type constructors' means you want to generalize that type, so you can use the constructors to produce an abstract type that works with any type but I've never heard that specific term.
So type constructors take types as their parameters and return new types you're saying, whereas the variant type in my example, the values are the constructors that make up the value of Type Answer
That's right. Type constructors are related to generics. For example if you have a generic type `List<A>` you could think of `List` as a type constructor.
In most languages, however, that's not a construct you can do much of anything with.
One is target your local job market for anything that will still exist post-pandemic. The second is target one of those online developer mills like TopTal, BiersDev, and that means implementing the 'mother of all demo apps' repeatedly from spec until you have a fully tested and optimized app ready for deployment in whatever language you think you will most likely find a job for (javascript/expressJS, React, etc). See https://n0x400.1mb.site/ for the MIT webdev crashcourse
If you read The Art of Computer Programming or Djikstra's writings they will tell you how this was done. They took a piece of paper, and they wrote down in a high level what their program should do. Then they took another piece of paper and they started to split up the first piece of paper into smaller subroutines. Then they took some more paper and split the small subroutines up into smaller and smaller subroutines.
Then they sat in front of a computer and they wrote the program from the simplest subroutine up the tree and at some point totally trashed everything realizing they didn't fully understand the problem because architecting a program is difficult until you actually implement it. So back to the paper they did the exact same design algorithm using the new experience they had from actually trying to implement whatever they were doing but this time with the added experience of knowing more about the problem they were trying to solve. Then when the chance came to implement their program on a likely shared computer with limited time, they wrote this program the exact same way from the bottom up testing all the way until it was finished. Everytime I've asked a question on stackoverflow/exchange I realized half way through preparing and formatting my question that my program is too complicated, I should break up the logic and then I don't need to ask a question. I swear this is why they make posting there so tedious where you need carefully format and search for existing questions before posting a new one because odds are, you'll figure out what you trying to ask before even asking it.
Sounds like the tried and true way. I'm always interested in learning about computing history and the people that set up the groundwork. The more I read, the more I find that tech doesn't learn much from its past and we're just stuck with many inferior iterations of the same things.
I found a copy of, Notes On Structured Programming, by Dijkstra. I'm going to start giving it a read tomorrow (it's a whopping 88pg essay).
It seems that Dijkstra did a lot of paper design work because he was programming for hardware that didn't exist in a programmable form yet.
This is how you transfer to a software role when nobody knows who you are and you have nothing in production to show for it. You learn everything about company app X, and then you start at the bottom as 'customer support engineer' or even lower as 'customer happiness' or w/e they call it these days.
When you are not putting out fires of angry customers, you learn everything you can from the developers that work there even starting to write features, starting to find bugs, optimizing the software, creating new tooling, whatever. It's simple to transfer around internally, impossible to get in externally. Then from there you transfer into a developer role because now you're not just some unknown guy they don't want to risk hiring. Once you are no longer junior, meaning you put in the work at that imaginary place moving around roles internally you jettison out of there to the higher paying positions because now you're an experienced developer and probably have a little network you can use, in other words no longer a risk.
The tool is called a schedule. You write what you should be doing at that time in the schedule. It does not run your life, instead it is the most optimized use of your time and it's up to you to follow it. After many false starts you will eventually adhere to the schedule, but only if you are truly interested in what you are learning and not learning it because you think you should. My personal method is take something I want to learn, and then all the boring pre-req parts become a research project instead of starting like everybody else does with the boring pre-req parts and failing before you begin.
However you should probably ask professors at your school what you should be doing in your free time, since they are the one's who will be determining said significant incentive so probably have a better idea what you should be doing than any of us.
For example:
The type is 'answer'. The constructors are Yes, No, and Maybe (these are actually called type variants but now we're getting into jargon). I presume an 'abstraction over type constructors' means you want to generalize that type, so you can use the constructors to produce an abstract type that works with any type but I've never heard that specific term.