I don’t think “when” is as important as “why,” though this piece doesn’t actually answer either question. But hey, we use clickbait titles because they work :) My response: people are flocking to this field –development specifically, and technical vocations in general– because it’s the grim reaper that’s marking so many other fields and vocations for death, and they’re hoping to get in on the high salaries before labour supply saturates and salaries stagnate.
With regards to what the article actually talks about… the entire article is about the pitfalls that new learning developers face, and how they are different from the pitfalls faced in earlier decades. I don’t think most of these pitfalls are new. I suspect the author just has the benefit of past experience informing his view of the present, and hasn’t taken a (long, pensive) trip down memory lane yet. I’ll grant that complexity has increased across numerous technical fields, but then again, the field was more complex two generations ago than it was three or four. This ever-increasing complexity necessarily lengthens the gestation period between “noob” and “competent” with every generation, but it’s only ever “new” in the sense that “hey, it takes longer to learn now” will likely always be a valid statement to make in the present.
As an aside, I really think that a thorough understanding of your field’s history should be prerequisite before you start diving into the deep end, if only because there’s so much hard-earned wisdom to be gleaned from realizing that typically, what’s new is actually old.
There were these kids see, making junk out of their parents garage doing this computer thing, and they became RICH! I mean richer than VEGAS rich. That’s why it’s so cool.
Now, some people always thought programming computers, and doing math, and peering through telescopes, and tinkering in the garage on their hot rod was cool. I don’t think their number has increased, though.
“how journey implements routing in rails with finite automata instead of regexes” sigh
To elaborate on your comment’s relevance, regexes can be implemented using finite automata, so the “instead of regexes” doesn’t have to be that way. As that 2007 paper by Russ Cox shows, finite automata can make regexes dramatically faster in certain cases.
According an article from 2012, Ruby still hasn’t changed its algorithm to Thompson NFA, the one discussed in Cox’s paper. So Ruby developers who need performant string matching must implement that algorithm themselves.