The lessons look interesting from a high level perspective. And I think could help people guide their applications.
I think there's also a need for a very low level course in deep learning. I.e. on the level of someone who wishes to write their own deep learning library. Because from high up, sure it all looks like the chain rule, but down low, it gets messy quickly if you want to write a high performance library on your own.
I think the obvious "gotchas" are problem definition (Am I formulating the problem in a way that will allow me to create value? a concrete example: am I modeling churn correctly?), overfitting, target leaks, and model trouble shooting / improvement (i.e. the model is doing OK, can it do better? How much better? How do we get there? Remembering that small performance gains can mean big $ at scale). On the reporting side, how confident that what I'm reporting is real? This is where the "science" training is helpful. Programming experience is relevant in the sense that implementation is important, i.e. it's far too easy to introduce critical target leak bugs when engineering features.
Of course we can abstract the root argument; for a given job, among those qualified to fill that job, there exists at least one person who has auto-learned the skills required to perform the job. This is probably true.
The White Walkers of the data science field are out the box enterprise solutions. These are enterprise software, data science consulting and ops solutions in a package. The corporate customer need not hold in house a data science team. The ambitions of the enterprise solutions (think DataRobot, H2o, etc) are to effectively bring one click production ready solutions that even C-level can participate in.
I see this is as the greatest threat to the demand of the "in house" data scientist.
If this turns out to be the case, I see the greatest demand for those who can write production grade code (i.e. software engineers) and those who are effectively trained data scientists. We see this job often called research scientist or research engineer.
We aren't there yet. Successful projects are building protocols with the goal of developers using them to build next-gen products that people actually want. Current speculation (a16z, polychain, ...) is that it will take another few years for this rollout to really take effect.
I was logically onboard back then, but the notion of Proof of Work mining seemed ridiculous and wasteful, so I didn't bother. I didn't even consider its purchase, which in retrospect would've been a good idea?
I'm happy to hear the field is moving to Proof of Stake. I would've been on board from the beginning most likely.
That is true. And then we ended up with Facebook, Amazon and Google et al to handle the rest. I'll take micropayment schemes over centralized megacorps. At least for now.
And personally, I remember a simultaneous mix of excitement and disappointment from the internet of the 90s.
Protocol operators running "full nodes" are paid in tokens for performing the service outlined in the protocol. The protocols are ultimately developer tools for user facing apps. Most of the user facing apps aren't mature enough to be notable, just like the internet wasn't all that exciting in the early 90s.
Exactly. A huge amount of excitement about moving away from closed monolithic platforms to distributed protocol operators paid in tokens.
For example, the little guy might be able to make a small income from IPFS/Filecoin that would otherwise be strictly the domain of AWS and other giants.
The crypto people who claim to "get it" say it's a game theoretic hack to bootstrap the development of a global distributed ecosystem which will ultimately allow for internet technologies we haven't conceived of yet.