There seems to be a fundamental misconception in this entire dialog between "Computer Science" (as define by the ACM/academic folks and their curriculums) and learning the skills needed to be useful as a Software Engineer in industry. These are very different things. The proponents should be clear exactly what it is they think all kids should be learning: do we want to train them to do research in Computer Science, or do we want them to get a more vocational education for the vast number of non-academic jobs?

The only possible interpretation of any research whatever in the 'social sciences' is: some do, some don't. -- Ernest Rutherford

Being among the shadiest companies with aggressive policies on squeezing their customers for everything they can, this is a surprise?

I would not suggest sacrificing salary earning years for a temporary career change, which is what I see as the summary of the situation. To do anything for an entire career and be happy requires that your are extremely passionate and interested in the field. I am not sensing that sort of level of interest, and that the priorities here are to be winding up doing something other than engineering in the long term.

I can understand feeling bad about not being able to contribute a certain way in your current environment, but everyone is limited in the things they can contribute in some way. It is a bit of the maturing process to be able to settle for not being able to do everything (as much as many of us would like to).

If the desire to program is deeper than I am giving credit for here and you are willing to sink significant time into, I suggest viewing the language/programming environment as the tool, and the problem as the focus. If your goal is to set out to "learn ruby-on-rails", you'll not get much out of it. If you goal is to solve a particular problem, and you happen to choose ruby-on-rails as the way to realize the solution, that is the way to learn something the most important skills you need as a programmer (and what will be relevant when the technology trend-du-jour changes).

There's all the resources you need on-line at your fingertips to learn as much about programming as you want, so it is all a matter of how much you are willing to sacrifice your free time and energy to dive into it.

One last tip: If you focus on real problems that interest you and not academic exercises, you will learn the important skills faster.

I am surprised to see people even thinking this is a debatable issue. Discrete math and graph theory: hands down. Sure, if you are going to be doing signal processing and special-purpose projects, then differential equations can help, but what percentage of programmers actually wind up working in those areas?

Most ACM-based CS curriculum do a big disservice to 95% of the students, but those where Discrete Math and Graph Theory are requirements do les harm than most.

Choice of language begins with the problem being solved. not the OS you happen to be developing on.

Are you just looking to tinker in the GNU/Linux world, or do you have a specific problem?

Simple Web/DB dev? -> php/js
Heavier Web/Server dev? -> Java
OS-related dev? -> C/C++
Heavy string processing? -> perl (or python is speed does not matter)
System admin-type problems? -> bash/perl

The most important part pointed out here: how can you look for "creativity" until you first define it?

The simplest thought could be creative for a given person given their experiences and the exact same thought for someone else would not be deemed creative due to a different set of experiences. How then can anyone judge the "creativeness" of a thought without having a complete knowledge of the entire past experiences of a person?