I have heard of companies that are counting how much you spend on AI in your performance review (higher = better). I'm not at one of these, but upper management is pushing it hard, and I'm lucky that my team has a technical manager who understands the limitations. So I'm not using it either.
I recommend you read the post because that's a really bad misunderstanding of the mindset, and like the comment at the top of this chain says, the post explains it well.
I read the post. I don’t agree with the “people are born to do one thing” mindset. There’s a lot of possibilities out there for everyone. I do identify with this OP fellow somewhat, except that I usually don’t code for fun on nights and weekends (also sunday code sesh can be fun)
I believe you're using the scientific definition of "sentience", while everyone else is using the common understanding of of the word (which should be called "sapience", but thanks to sci-fi's usage of the word "sentience" is largely not).
I think it ended in the late 2010s, when streaming took over:
Over the 2000s and early 2010s, writers were perfecting the style first experimented with by the great shows of the 90s and earlier, where seasons were mostly episodic but led into serial plot. Several of those early ones have been mentioned in these comments, and often alternated episodic and serial, while the later ones were figuring out how to mix the overarching plot into the episodic ones, advancing it slowly as something extra so viewers could miss one or two episodes without getting lost. Then at the midseason and season finales it'd be a big event for the larger arcs, bringing it all together.
Streaming no longer had to worry about viewers missing an episode, so all the episodic filler started getting dropped in favor of streamlining the overarching plots. Unfortunately, what we lost along with it was things that were less filler and more character and world building. Getting to know the characters through action instead of summarizing it with narration, making the setting feel more real, laying out events and actions in a more natural way instead of it feeling contrived.
The backstory that makes this scene work so well was almost all in those episodic character and worldbuilding episodes we don't really get nowadays. We actually watched these characters develop and grow and change over years before this scene. I don't really think modern TV in its serial format could have a scene with as much impact - all that "filler" makes them feel like three dimensional people rather than plot devices.
There were ones before that, my mom had one. Apple added polish and used a capacitive touchscreen instead of a resistive one, then amped up the hype in their commercials, so everyone forgot these existed.
Possibly a Palm Treo, introduced in 2002, or a Windows-based PocketPC, introduced in 2000.
I always felt that Apple basically reimplemented PalmOS with the benefit of ~10 years newer technology and a wildly efficient Chinese supply chain.
I definitely wouldn't say that these devices were mainstream. They were very much targeted toward business people and hardcore nerds. The iPhone definitely revolutionized the market, with its vastly more desirable aesthetic and approachable interface.
It may have been a 2005 phone or something. I think it was a Nokia, Motorola, or Samsung phone (our whole family was on those at the time), but whatever it was it had just about the complete form factor and an app store - mostly a screen with a grid of apps on home, with a couple of buttons at the bottom (more Android than iPhone). Maybe it had a slide-out keyboard? Can't remember that part for sure.
> those keyword lists often include, in my experience, proficiency in specific tool use
This used to be called "buzzword bingo" and was pretty much required. It was how you got past the initial automated filtering step before a human even saw your resume.
I don’t know whether it was ever effective strategy for candidates, but I will simply say that as a hiring manager for over 12 years, I have never been interested in anyone’s resume when I see that.
The problem is that the candidate doesn't know, its not even good proxy either way just like everything on the resume besides the list of companies the person worked on.
Most applicants have no idea about your internal HR procedures and what's the pipeline before the resume even gets from you so they might as well optimize for what generally seems the most "successful" approach. Maybe they actually think writing metrics and keywords is a good idea, maybe they think its stupid and resent it but can't get any interviews without it, its really impossible to tell without other variables..
As someone who's been a hiring manager for around 7 years, I agree with you, but note that the people who screen resumés before they even _get to you_ very well may be looking for those references.
For my own resumé, I include the stack used at each job which I feel strikes a fair balance.
That's what I always did too. Then I removed it because I wanted to focus more on the kind of problems I solve rather than the languages I've worked in, and recruiters complained, so I put it back in.
Most HR departments have been filtering resumes (or LinkedIn) based on things like keywords for years before they got to you. So your reaction to resumes that heavily use those may be reactionary to being presented with tons of those (by whoever filtered them before you)
No used to be. It still is standard. Large companies that do not use external recruiters still use keywords and skills matching to find candidates and it drives me nuts.
This is itself a skill people need to learn, that I'm not sure is possible with pseudocode and no prior experience. Too easy to gloss over details without actually running it to learn where your blind spots are.
I did this workshop a decade or so ago where I learned my co-workers don't do this, and never did learn how they understand code otherwise. One of them mentioned he didn't even realize this was a thing.
> never did learn how they understand code otherwise.
This particular statement interested me.
In code review, I always am a stickler that "if I need to run the code in my head to prove something about it for me, I want to see that in a unit test - I shouldn't have questions about the code that aren't already answered by the tests"
reply