I wasn't a programmer (finance background), and I learnt enough SQL to be useful in perhaps 20 minutes. Reading just one Date book [1] took me a further 3 days

I wasn't a programmer (finance background), and I learnt enough SQL to be useful in perhaps 20 minutes. Reading just one Date book [1] took me a further 3 days and allowed me to solve pretty much everything I've encountered since, with the occasional googling for syntax. Aside from perhaps statistical learning (reading through ISL [2] takes perhaps half a day to a day if you are committed, another day for the labs, and then you are immediately useful to most SMEs), I can't think of a field in computer science that has such a fast ROI. Both being able to query well, and being able to build simple but accurate statistical models, are valued quite highly by the marketplace right now and naturally lend themselves to a "contractor" relationship. The OP mentioned making money... SQL is declarative which means if you can word it in your head, you can write the query (unlike with OO where you need to define what happens to your record). If you learn it properly, from the set theoretic perspective (aka the relational model, not using the RDBMS as a data dump without FKs, and treating rows as records the OO way), you can keep working like that almost indefinitely, and the problem solving is a lot of fun - "how can I define my output in terms of my input in one go". Most importantly, you KNOW your code is correct (except logical errors) whereas the ORM does not guarantee as much (my first step when at a new company that uses an OO framework is enforcing all the implicit FK constraints and keeping track of the 1-3% of tuples missing bits). Most of the time it (sort of) doesn't matter (click through rate being off by 0.2% isn't going to change your life); when you're calculating how much money you donate customers via discounts or matching your orders with cash flow, it does, and this is when companies start paying good money. Unfortunately, based on interviewing 200+ applicants over a couple of years to data-related positions, I've started to think that the relational model is simply not taught anymore, and many popular frameworks actively encourage patterns that break the model (e.g. polymorphic associations in RoR [3]). I'm now happy just to see someone aware of why constraints might be useful, let alone being able to discuss 2 vs 3 or 4 valued logic or the usefulness of prenex normal form. [1] SQL and Relational Theory, C. J. Date 2011 [2] http://www-bcf.usc.edu/~gareth/ISL/ http://www-bcf.usc.edu/~gareth/ISL/ [3] http://stackoverflow.com/questions/922184/why-can-you-not-have-a-foreign-key-in-a-polymorphic-association http://stackoverflow.com/questions/922184/why-can-you-not-ha...