I think the implication is that even though the technological landscape is evolving, it's not as if people born in the 60's couldn't foray into computer science because they arrived too late to study the ENIAC first.
I'm not sure why you're downvoted, but this is the right take IMO. I hate cheating and lying in general, but in any job posting you have to separate what are the actual requirement in term of knowledge versus what can be realistically learned on the job / doing a prototype in a weekend.
Of course don't fraud by like pretending you're a statistician when you have absolutely no mathematical background, but also don't take at face value the "Must have {x} years of experience in {y} tech" requirement when you know you have the necessary work experience to have a good grasp on it in a few weekend prototypes, and you also know that the job doesn't actually require deep expertise of that particular tech.
I did the same for my first React.js job, and I didn't feel bad because 1) I was honest about it and did not sold myself as a React expert, and 2) I had 10 years of front-end development, and I understood web dev enough to not be baffled by hooks and the difference between shallow copy vs. deep copy of a data structure, so passing technical test was good enough for it.
A few years ago there was a thread about "How complex systems fail" here on HN[1], and one aspect of it (rule 9) is about how individuals have to balance between security and productivity, and being judged differently depending on the context (especially being judged after-the-fact for the security aspect, while being judged before the accident for the productivity aspect).
The linked page in the thread is short and quite enlightening, but here is the relevant passage:
> Rule 9: Human operators have dual roles: as producers & as defenders against failure.
> The system practitioners operate the system in order to produce its desired product and also work to forestall accidents. This dynamic quality of system operation, the balancing of demands for production against the possibility of incipient failure is unavoidable. Outsiders rarely acknowledge the duality of this role. In non-accident filled times, the production role is emphasized. After accidents, the defense against failure role is emphasized. At either time, the outsider’s view misapprehends the operator’s constant, simultaneous engagement with both roles.
100% this. To this day the official website still describe itself as a library, and I'm convinced it's completely for marketing reasons, since 'framework' feels heavy and bloated, like Angular or Java Spring, while 'library' feels fast and lightweight, putting you in control.
Framework can be more or less modular, Angular or Ember choose to be 'battery included', while React choose to be more modular, which is simply choosing the other end of the spectrum on the convenience-versus-flexibility tradeoff.
React ostensibly only care about rendering, but in a way that force you to structure your whole data flow and routing according to its rules (lifecycle events or the 'rules of hooks', avoiding mutating data structures); No matter what they say on the official website, that's 100% framework territory.
Lodash or Moment.js, those are actual bona fide libraries, and nobody ever asked whether to use Vue, Angular or Moment.js, or what version of moment-js-router they should use.
In his "Power of Simplicity"[1] talk, Alan Kay had a great illustration of this specific phenomenon using astronomy:
Before Johannes Kepler had the insight of describing the orbits of the planets with ellipsis, peoples were using the (conceptually simpler) circles which didn't completely match the observed movement of celestial body such as Mars, thus resulted in complicated circle-within-circles orbits to try to model reality. By introducing a more complex basic shape (ellipsis instead of circle) which happened to match the underlying reality more, the overall description of orbits got greatly simplified.
It's a phenomenon I've seen a few time in my career so far: that while often there's complex code because there are actually complex hedge case to handle (essential complexity), sometime it's really because the data structure used to model the thing you're handling is slightly missing the mark, making things fit almost-but-not-quite, and many operation done around to handle data can be greatly simplified (if not avoided altogether) by changing the underlying data-structure.
(Also, Alan Kay apparently did another talk called "Is it really complex, or did we just make it complicated"[2] that seems pertinent to the thread, though I haven't watch it yet)
> Maybe we're just calling all forms of automation and computer vision "AI" these days because it's sexy.
Funny thing is, at first it was the other way around! 'Computer Vision' has always been a sub-field of AI, but the term was more widely used by academics during a previous AI winter as a way to avoid the tainted 'AI' label.
Passion, drive, and existential fulfillment can take many form, and "professional joy" can absolutely be one of them.
It's not about drinking the corporate kool-aid, but about taking pride in what you've put in the world (even potentially as a hobby), having a sense of craftsmanship, or even maintaining a certain work ethic.
Even the "making money" part can be tied to a very deep sense of providing for your loved ones, and a sense of personal responsibility.
I'm a bit surprised at reading that. I've tried both, Next left a bad taste in my mouth, but Nest was kinda neat. Didn't used it for anything too complicated though, so I'm curious about what sort of grievances people have against Nest.
reply