I'm still in the industry and I am currently straddled between the past and the future. Part of my work is designing systems that will accommodate mainframe migration from proprietary systems to linux, thus the past. The other part of my work is scoping out use cases for the FPGA's that Intel is baking into our current generation CPU sockets, which is the near term future.
Today's programming opportunities are certainly not constrained by tools of 10 years ago. However, going Biblical on you, "There is nothing new under the sun". The "tools" and particular applications are fads which come and go. But there are underlying principles which re-occur over and over again.
Thus, my appeal to the book: Designing Data-Intensive Applications. It describes principles which I have seen in myriad systems during the last 40 years. Just going out and learning "Big Data" isn't going to get you the background you need. It will get you a job.
The industry itself has a habit of throwing the baby out with the bath water. When "relational databases" hit the scenes in the 1980's, everyone turned their back on CODASYL, network databases. The appeal was that the programmers didn't need to know the structure of the databases anymore AND the database administrators had some ability to change the structure without reprogramming the applications.
However, relational gave up some important data relationships which really were necessary; e.g. the idea that if one instance of a record type existed, then there must be one or more of a particular second record type. They spent a lot of effort adding data design semantics back into relational that had been in CODASYL on day one. Some of it isn't pretty.
Now, there is an outright recognition that some data should not be kept in relational stores, thus, we see products called nosql and we see non-relational in-memory datastores like Redis (great product).
A person can either be "above the fray" looking down on what is going on and helping direct the traffic. Or a person can be a cog, with their head down taking directions to find out what the next project will be.
The first person is an engineer with a lot more education that computer science.
>> FPGA’s that Intel is baking into our current generation CPU sockets
That’s cool. I suppose you’ll be getting some IP with that?
>> “There is nothing new under the sun”.
Perhaps the same but different...
Over the last 40 years, We’ve seen software tooling evolve with both greater complexity and simplicity broadening the opportunities for a wider range of contributors. Just consider the unique skill sets required to support FPGA development and Cloud computing — two completely distinct engineering areas with dozens of development domains in between. And not to exclude the emerging Model Driven Development which is now used in manufacturing & research, and will eventually extend into general use over the next 10 years.
These are exciting times for software development. But unfortunately, there’s a shortage of young adults in training. It’s a problem, and the Department of Energy is hoping to awaken the education sector.