Why work hard for a STEM degreee -- your pay is half that of the idiot managers who undercut your work with incredibliy bad decisions and generally make your life miserable. The smart folks are majoring in management or finance, and the rest aren't bright enough to get through the technical program. Although in my experience, liberal arts courses are much tougher than STEMs.

We did this for a family (~20) of Visual Studio solutions. We called them "base" and "child" solutions. Any child solution could also be the base for other solutions, so you could have chains and trees of solution dependencies. We created a Visual Studio add-in that would import a selected version of some base solution (we versioned the solution builds) and put its exported assemblies in a solution folder in the child solution. Projects in the child solution would then reference (using the Browse tab) these base assemblies. As part of the import, we generated and maintained in the child solution a manifest that noted the imported solution's version (including the assembly versions it contained). A custom MSBuild task would verify that the assembly versions matched the manifest at build time. In base solutions, projects marked as exportable were copied to an export folder. This way, we could keep e.g. unit test projects or application projects in the base from being brought down during import. It worked very well, not only supporting the solution dependencies, but also rolling updates: one child solution could import an updated base, while another could wait until a appropriate time to make the upgrade. The only icky part was when a child had multiple parent solutions that themselves inherited from the same base (a diamond-shaped dependency tree). In that case, both parents had to update their base solution version at the same time or else the child could not be built. The process also supported import of the debug compile during development and then import of the release compile on the build box. There was also a temporary import that allowed you to import a base solution on your own dev machine (for when you're making updates to the base and need to get them to the child to complete testing). It did not take all that much work to get this set up. Not sure why Visual Studio/TFS doesn't have support for it or something similar. unfortinately, i don't own what code there was, so can't share it. But I think it's the concept that's significant.

The following refers to the US, and may or may not correlate well to conditions in your part of the world. In the late 90's, the number of women in software programs was trending upward. This halted and even reversed in the early noughts. This coincides with 2 other trends: (a) outsourcing and (b) higher numbers of women college grads, more now than men and this trend continues. My theory is that women have recognized that the software field really is not much fun anymore, at least as practiced in the typical US business, is far less lucrative than it once was, and that there are now lots of other options for women in fields that used to be male-dominated but no longer are. I.e. we have found better things to do.