The point is that all tools are hard if you don't have context about why they work the way they do. All of the tutorials are aimed at engineers, walking them through problems that they have and workflows that they'll want to use. Git Immersion is probably the best one I've ever seen and it's still aimed at budding Ruby developers.
Has anyone thought about doing this for content/marketing/design people? The tools that they use are hard too, but they know how because they were sufficiently motivated to learn them.
It's a big mistake for engineers to think that their jobs and the tools they use are significantly harder than in other fields.
> It's a big mistake for engineers to think that their jobs and the tools they use are significantly harder than in other fields.
I completely agree with everything you state in this comment, especially your last sentence. I have a strong sense that we have similar opinions but different ways of stating them.
It's a big mistake for engineers to think that their jobs and the tools they use are significantly harder than in other fields.
Hmmm... ok, I'd agree it's a mistake to simply assume this. But I'm not going to dismiss the possibility, either. Consider this thesis: there is a constant degree of churn in software development that adds significant complexity to the task of software development relative to many other fields.
Is keeping up with javascript framework churn par for the course in other fields? It's very difficult to make that call, since few of us have worked in a wide variety of fields in a meaningful way (I worked in a law firm right after college, but I wouldn't say I can meaningfully comment on the practice of law). But I have a sneaking suspicion that our jobs actually are pretty difficult. We deal with what I feel comfortable calling a hellacious degree of technical complexity at times.
Outside of JavaScript frameworks, which is just one area of dev, there is _significantly less_ churn. You do not have to keep up with this churn to be a developer.
There's been a decent amount of change on the backend, too. I hesitate to call it churn because not all of it deserves to be characterized this way. I started working with backend technologies in the late 90s, and there was a lot of talk about building data warehouses, mainly with distributed SQL databases, often in Oracle or another high cost private solution. Because my work involved industrial engineering, we also did a lot of analytics and prediction - collaborative filtering was one interesting approach to recommendation systems back then.
Since then, the "noSQL" movement occurred, and while I'm delighted to see a resurgence of interest in SQL, mongo, Cassandra, various graph databases, and other non-sql data stores do have valuable uses (I think some people just went too far against SQL and the relational model, which also remains exceptionally valuable). I didn't name all of them, but while there was value in there, some of it was churn and adopting technologies for the hell of it. But even when it wasn't churn and was legit, that's still a lot to learn.
Also, spark, hive, Hadoop, and a lot of storage and infrastructure has moved to a cloud environment (AWS is the biggie, plenty of others). Again, not necessarily bad tech, but a lot to learn.
Also, in my own particular field (this may not apply to all backend developers), machine learning did become a big factor in work, especially prediction systems. I did a lot of math in undergrad and grad school, but there was still plenty to learn there, including dusting off the old math books and re-learning how gradient descent works for neural nets, logistic regression, and then other approaches like bayesian methods, random forests, and so forth.
Also, in this time, the middle tier technology you needed to know also changed - to a large extent for the better, but C++ gave way to Java, which grew in to a mountain of a mess with EJB and other crap, then ruby and python, rails and Django (for the record, I loved ruby and rails but don't work in it much anymore). If you want to do distributed computing, you can use python, but you really might want to consider learning Scala.
Now, obviously you don't have to learn all this, you can specialize, and I wouldn't call it all churn (then again, I wouldn't call all the javascript framework stuff churn, either). But to work on the backend, you probably did have to keep up with a lot of that.
And like I said, I couldn't tell you what it's like to keep up with other fields... but yeah, I'm pretty comfortable saying that keeping up is pretty hard on the backend as well, and that learning these tools is no easy thing.
I don't see that the underlying concepts have changed very much from your examples, or that there are even many (any) new (as less than 25 years) old ideas are in there.
The tool isn't the skill, and honestly I don't want to work somewhere that values "x years using y" over "thoroughly understands concepts behind/around y".
I've been in IT since the late 90s, only development the last 5 years, but knowing how protocols work and what makes systems/architectures reliable gets way more play in my day to day job than knowing whatever the current tech is.
Has anyone thought about doing this for content/marketing/design people? The tools that they use are hard too, but they know how because they were sufficiently motivated to learn them.
It's a big mistake for engineers to think that their jobs and the tools they use are significantly harder than in other fields.