I watched this pilot last week and had similar feelings about the "computer science" questions (a friend had sent me the call for participants, since I'm in Portland). I had a pretty strong...
I watched this pilot last week and had similar feelings about the "computer science" questions (a friend had sent me the call for participants, since I'm in Portland). I had a pretty strong reaction to it too.
From the first few minutes it becomes abundantly clear this is content marketing. The purpose of the game show is to appeal to customers of companies targeting web developers. While I resonate with the evergreen premise that context is lost when newer generations enter the scene, "devrel" media tends to be even more disconnected because its incentives aren't always aligned with reality.
It's true and interesting that the solutions we cooked up in 2010 have shaped reality for engineers working now -- to the extent that the original problems they solved are obscured. In my professional life I have the honor of working with some truly phenomenal developers, who are often now 10-15 years younger than me. They're very much rooted in the real world and understand the difference between computer science and web frameworks. I wouldn't worry or project too much from a marketing project that slightly missed the mark in a few places.
My conclusion after watching the full pilot was that it misses the mark in a different way: it reduces skill and mastery to memorizing little factoids or having seen a piece of code before. Coding (at least for humans, still) is a creative art. While I think the quiz show is a fun concept, the knowledge it showcases is easily the least interesting or fun part of making things with computers, and I don't think we need to create more content that lionizes it.
However, if anyone wants to make long form content breaking down cool strudel.cc tracks, I'd watch that all day...
My browser deleted a longer, rantier comment. Probably for the best; this one is pretty bad too … I got into the industry because taking apart complex machines was fun, and building them even...
My browser deleted a longer, rantier comment. Probably for the best; this one is pretty bad too …
I got into the industry because taking apart complex machines was fun, and building them even moreso. Being paid never felt like it diminished the enjoyment; rather, that came from realizing that my cohort desperately hated the parts of the work that I enjoyed. The fiddly bits in ECMAscript, which show off its weird prototypal heritage. How distributed systems fundamentally break sequentiality. All the little details which one can grasp to make a “thing” that works as well as it can, given the material circumstances, and our knowledge of mathematics.
I recognize that everyone needs to be paid, and software development has historically been extremely easy work for the pay. Thus the hordes of people who don’t care about the machine, since actual understanding is wasted effort if your interest stops at 5pm.
It’d be nice to surround myself with people who want to care, and will dig deeper to understand — for example — “how” React works, instead of just assuming its existence. But understanding isn’t a job prerequisite, which will only get worse with AI. RIP to the author and me, I suppose.
Here's the rub - I am a software developer by trade and by hobby and I will never care or dig into how React works. Front end stuff does not interest me. React is roughly the 45th web framework...
It’d be nice to surround myself with people who want to care, and will dig deeper to understand — for example — “how” React works, instead of just assuming its existence. But understanding isn’t a job prerequisite, which will only get worse with AI. RIP to the author and me, I suppose.
Here's the rub - I am a software developer by trade and by hobby and I will never care or dig into how React works. Front end stuff does not interest me. React is roughly the 45th web framework that I have seen and worked with. I just accept that it currently is a thing that exists and will continue to exist until the next thing comes along.
This week I have stood up some APIs on my home server to allow some Twitch streamers to play some games between their channels, one in Python and one in Rust just to keep sharp. The other week I wrote a NFC token reader to make my kid a media player for her room on a raspberry pi. I am actively involved in decompilation of some Nintendo 64 games. I have a project for a friend trying to figure out why one of his boards from 1993 is not working.
It would be incredibly unfair to say that people don't care about the deep dive when it's far more likely that they only care about a different part of the machine. Almost every developer I have ever worked with has had their own little niche topic of interest, be it streaming (and setting up a super overkill plex server and understanding how to do that effectively) or game design or retrocomputing or something.
For me, it's not that I don't care how React works. Rather, I find I have a mostly-automatic inference about how it should work. If it is well-designed (which many frameworks are), then I don't...
Front end stuff does not interest me. React is roughly the 45th web framework that I have seen and worked with. I just accept that it currently is a thing that exists and will continue to exist until the next thing comes along.
For me, it's not that I don't care how React works. Rather, I find I have a mostly-automatic inference about how it should work. If it is well-designed (which many frameworks are), then I don't need to stress about the details as long as I stay in the common use cases.
That’s very cool! Also please never dig into how React works; it’s not terribly important, and I only brought it up as an example because the article did :) and I’m surprised that N64 games were...
That’s very cool! Also please never dig into how React works; it’s not terribly important, and I only brought it up as an example because the article did :) and I’m surprised that N64 games were even compiled; I’d thought that that was still the era of mostly handwritten assembly! TIL!
it's far more likely that they only care about a different part of the machine. Almost every developer I have ever worked with has had their own little niche topic of interest […]
My coworkers have interests such as sports, alcohol, and travel. I’m glad that you’ve been able to find people who have similar interests as you — having had that before, it’s a fantastic experience! — but please understand that it’s not universal. A lot of people are in this career because it was both easy to get into and very lucrative.
For context I’m not saying that the above is the case for every developer on planet earth, just that chasing a decent salary inevitably removed the selection bias of shared interest from my cohort, which was both sad (for me) and predictable.
I'm in my late 30s and I definitely started off like this as I was learning and began working for small, local web dev agencies. Then as soon as I entered the corporate world ~10 years ago, it...
It’d be nice to surround myself with people who want to care, and will dig deeper to understand — for example — “how” React works, instead of just assuming its existence. But understanding isn’t a job prerequisite, which will only get worse with AI. RIP to the author and me, I suppose.
I'm in my late 30s and I definitely started off like this as I was learning and began working for small, local web dev agencies. Then as soon as I entered the corporate world ~10 years ago, it just became impossible for me to be like that. I don't have time within my working hours to get philosophical with my stack. All projects need to be done yesterday. There are half a dozen meetings that should've been an email or slack message. If I dare slow down to make sure I fully understand the how of the code I'm writing, I get labeled as "slow" and get lapped by code camp junior devs who just write code carefree with little understanding of the longterm impacts. Or I don't do enough code reviews or get enough commits in and then the stats looks funky when my annual review comes along.
The best I can do at work is rapidly start building things with new tech and learn what works, rather than how it works. And I'm not willing to sacrifice time with my family or my own mental health by digging into these things outside of work hours.
I am not a professional developer; and I barely consider myself an amateur developer, but I think I agree with your take. But I have never worked in a software dev job, so let me know if I am off...
I am not a professional developer; and I barely consider myself an amateur developer, but I think I agree with your take. But I have never worked in a software dev job, so let me know if I am off base.
These things are just tools. You don’t need to know why a tool works, you just need to know how it works. A car mechanic doesn’t need to know how a compressed air motor works, or how a hammer and anvil on an impact wrench works. All they need to know is that they hit the trigger and the nut comes off.
Can knowing how your tools work improve your efficacy? Maybe. But is it required to be effective? Nope. I find it interesting to learn about how things work, but it doesn’t appear to be required to me.
Yep, and agreed (except I’m not sure what you mean by “philosophical”; for context, I’m saying that you could throw a dart and hit a coworker who doesn’t know mechanically understand what a packet...
Yep, and agreed (except I’m not sure what you mean by “philosophical”; for context, I’m saying that you could throw a dart and hit a coworker who doesn’t know mechanically understand what a packet is).
I’m a decade into my career, and I spent the first half of it working for smaller, local businesses, where there was a selection bias for people that would trade pay for interesting problems. I (correctly, imo) decided that retiring was more important than job satisfaction, so I switched to a role at a larger company … hence this conundrum.
And yeah, very much agreed re. deep understanding vs. hitting deadlines. I wouldn’t want anyone to sacrifice time outside of work to build up understanding, it’s that this is my “hobby” (as it was for several coworkers of jobs gone past), so they (and I at the time) didn’t view it as a sacrifice — it was fun, at the time.
Er, in sum, sorry that you’re in a similar position, I think. Hope the AI nonsense doesn’t chase you out of the job.
So far the AI nonsense isn't bothering me too much. It's more the people that are doing that (mainly project managers, middle management, etc.) and the "politics" of work. Maybe it's just my...
So far the AI nonsense isn't bothering me too much. It's more the people that are doing that (mainly project managers, middle management, etc.) and the "politics" of work. Maybe it's just my company, but getting yourself lined up for promotions is basically a part-time job in and of itself. All this career planning nonsense, ever-moving goalposts, vague requirements, and buttering up stakeholders. I just want to write some god damned code, ya know?
I've actually found AI to be very useful when migrating from one framework to another (eg "How do I do [thing in Angular] in React?") and then it gives me a brief breakdown of why it's completely different and some code samples. Or when I was learning Typescript I'd just give it an object and ask it to spit out a type for me. I'd use it, learn from it, and eventually stopped needing to ask CoPilot. Obviously it doesn't teach me everything, but it's a lot less friction than the "old" way of just googling it and clicking through people arguing on Stack Overflow.
I have no doubt though that as it evolves and weaves its way more and more into the industry that I'll get sick of it. They'll start using AI to assess your commits and analyze readiness for promotion. Or check your work against AI solutions and penalize you somehow for not being as efficient as a robot that stole other people's code. sigh
Ah ... yeah, no, that sounds similar. n=2 but I get the impression that's just large companies ... That's definitely cool! I've also found it useful for picking up new libraries and whatnot,...
So far the AI nonsense isn't bothering me too much. It's more the people that are doing that (mainly project managers, middle management, etc.) and the "politics" of work. Maybe it's just my company, but getting yourself lined up for promotions is basically a part-time job in and of itself.
Ah ... yeah, no, that sounds similar. n=2 but I get the impression that's just large companies ...
[utility of AI]
That's definitely cool! I've also found it useful for picking up new libraries and whatnot, although when I last tried the tools (a couple months ago briefly, then more thoroughly a year ago), they really struggled with any library that couldn't be found on Stack Overflow. Ultimately it wound up more useful to look through those automated search results which steal code samples from GitHub and boost their SEO.
I have no doubt though that as it evolves and weaves its way more and more into the industry that I'll get sick of it. They'll start using AI to assess your commits and analyze readiness for promotion. Or check your work against AI solutions and penalize you somehow for not being as efficient as a robot that stole other people's code. sigh
I'm looking forward to code review bots that tell me to do something incorrect, then having to justify ignoring the comment to management! Ah, and having to review AI generated code, or to assist coworkers when the AI gives them something that doesn't work.
Unrelatedly I'm trying to get out of tech in the next several years to find something else to spend my life on hahaha
haha, yeah I feel you. I can't tell you how many times I've googled "Jobs a developer can easily transition into". None of them sound appealing, except for Developer Advocate, but those seem very...
Unrelatedly I'm trying to get out of tech in the next several years to find something else to spend my life on hahaha
haha, yeah I feel you. I can't tell you how many times I've googled "Jobs a developer can easily transition into". None of them sound appealing, except for Developer Advocate, but those seem very hard to come by without existing experience with the role!
In the first few seconds of the video the host goes over a sponsor message pushing WebStorm. I think it's pretty clear this is just a naming issue. Technically it should be a show specifically...
In the first few seconds of the video the host goes over a sponsor message pushing WebStorm. I think it's pretty clear this is just a naming issue. Technically it should be a show specifically claiming to be for web developers. But web is one of the biggest, if not the biggest, platform for software development. So it's not crazy to have someone effectively make it the "default" mode of development in a game show.
As another oldster operating in this space, I can relate. It’s perplexing when I encounter colleagues who are proficient in TypeScript + React JSX idioms but have no real understanding of HTML and...
As another oldster operating in this space, I can relate. It’s perplexing when I encounter colleagues who are proficient in TypeScript + React JSX idioms but have no real understanding of HTML and CSS, browser or HTTP fundamentals, or the specific functions of the bundlers, compilers, linters, formatters, and package managers their projects rely on. I’m constantly surprised how effectively a dev can operate at one layer of abstraction while being oblivious to all the others. Maybe it’s just because most of the other layers didn’t exist when I was getting started, but personally I feel like I have to grok it all otherwise none of today’s stacks will make any sense to me.
people saying "vanilla JS" when talking about Node
I agree with most of the post but this bit not so much. Arguably JS in a Node context is even more “vanilla” than in a browser because it’s divorced from all the window and document cruft, etc. Modern frontend workflows blur the lines between what code is executing where, so I guess some devs might be confused about what Node even is (“oh, you mean yarn start?”) …but some of my favorite pure JS development is building CLI tools to run under Node, it really doesn’t get any more “vanilla” than that.
Node has its own API’s and any non-trivial app probably depends on them, at least indirectly through libraries. So do other environments like Deno and CloudFlare workers. Vanilla JavaScript is...
Node has its own API’s and any non-trivial app probably depends on them, at least indirectly through libraries. So do other environments like Deno and CloudFlare workers.
Vanilla JavaScript is relevant for library code that has to be portable (runs in all these places), but that’s its own specialty that many people can ignore.
There are many types of people in any profession. Some are better at the job than others. In programming, I often see two main types of people who end up being the most effective. Ones that just...
There are many types of people in any profession. Some are better at the job than others.
In programming, I often see two main types of people who end up being the most effective.
Ones that just learn most things on their own.
Ones that can be very effective if mentored
I've mentored quite a few people. The thing that seems to work the best is to give people context and explain a bit about how things work. Otherwise you end up with people being surprised when things are inefficient and the disconnect that is discussed in the article.
I think a problem with modern frameworks is that they hide a bit too much of the underlying behavior of a computer. And frameworks are released or updated very frequently. And most workplaces do not pay people to learn, they pay people to produce. So you end up with a situation where people are "writing" code by copying a block from a website, or copying from another program, or having copilot write it.
An example of how things go: My team started using React a lot lately. Previously we had used Angular or something else. We all just started using it. I see a lot of strange code of course. One common source of strange or bad code comes from the hook useEffect. My own journey with Effects went like this:
I see an example of useEffect to make something happens once when the page renders. That must be what it's for. Maybe to make a loading animation or something.
Then I need to add an event that happens in one component when a different component changes value. So I can add the 2nd component to the dependencies. That must be what useEffect is for.
Then I need to draw something on the page after an async call is made. Oh, that's really what effects are for!
So we should have had training and mentoring before anyone started typing. And my company gives access to Udemy courses but we didn't even do that.
Later we may finally read something like You might not need an effect. What, are we supposed to go back and rewrite the old stuff? We have new stuff to write and we have a bunch of other urgent security findings to resolve.
I find LLMs are especially useful when jumping from one framework to another - because they’re all trying to solve the same problems and generally have the same solutions as each other but with...
I find LLMs are especially useful when jumping from one framework to another - because they’re all trying to solve the same problems and generally have the same solutions as each other but with slight differences. You can have them port code and then explain each section, or ask it how to do X in framework Y given what you would have done in framework Z.
Also I noticed that they are good for writing unit tests. Nobody likes doing that but copilot doesn't complain. It mostly makes pretty reasonable ones too, but if it messes up something it doesn't...
Also I noticed that they are good for writing unit tests. Nobody likes doing that but copilot doesn't complain. It mostly makes pretty reasonable ones too, but if it messes up something it doesn't seem to be able to correct so you still have to write some things by hand.
It doesn’t cover all cases. I think an LLM loop that checks for coverage would be pretty nice. And I still find myself going back and adding a couple extra cases. But still a big win in my opinion.
It doesn’t cover all cases. I think an LLM loop that checks for coverage would be pretty nice.
And I still find myself going back and adding a couple extra cases. But still a big win in my opinion.
I watched this pilot last week and had similar feelings about the "computer science" questions (a friend had sent me the call for participants, since I'm in Portland). I had a pretty strong reaction to it too.
From the first few minutes it becomes abundantly clear this is content marketing. The purpose of the game show is to appeal to customers of companies targeting web developers. While I resonate with the evergreen premise that context is lost when newer generations enter the scene, "devrel" media tends to be even more disconnected because its incentives aren't always aligned with reality.
It's true and interesting that the solutions we cooked up in 2010 have shaped reality for engineers working now -- to the extent that the original problems they solved are obscured. In my professional life I have the honor of working with some truly phenomenal developers, who are often now 10-15 years younger than me. They're very much rooted in the real world and understand the difference between computer science and web frameworks. I wouldn't worry or project too much from a marketing project that slightly missed the mark in a few places.
My conclusion after watching the full pilot was that it misses the mark in a different way: it reduces skill and mastery to memorizing little factoids or having seen a piece of code before. Coding (at least for humans, still) is a creative art. While I think the quiz show is a fun concept, the knowledge it showcases is easily the least interesting or fun part of making things with computers, and I don't think we need to create more content that lionizes it.
However, if anyone wants to make long form content breaking down cool strudel.cc tracks, I'd watch that all day...
My browser deleted a longer, rantier comment. Probably for the best; this one is pretty bad too …
I got into the industry because taking apart complex machines was fun, and building them even moreso. Being paid never felt like it diminished the enjoyment; rather, that came from realizing that my cohort desperately hated the parts of the work that I enjoyed. The fiddly bits in ECMAscript, which show off its weird prototypal heritage. How distributed systems fundamentally break sequentiality. All the little details which one can grasp to make a “thing” that works as well as it can, given the material circumstances, and our knowledge of mathematics.
I recognize that everyone needs to be paid, and software development has historically been extremely easy work for the pay. Thus the hordes of people who don’t care about the machine, since actual understanding is wasted effort if your interest stops at 5pm.
It’d be nice to surround myself with people who want to care, and will dig deeper to understand — for example — “how” React works, instead of just assuming its existence. But understanding isn’t a job prerequisite, which will only get worse with AI. RIP to the author and me, I suppose.
Here's the rub - I am a software developer by trade and by hobby and I will never care or dig into how React works. Front end stuff does not interest me. React is roughly the 45th web framework that I have seen and worked with. I just accept that it currently is a thing that exists and will continue to exist until the next thing comes along.
This week I have stood up some APIs on my home server to allow some Twitch streamers to play some games between their channels, one in Python and one in Rust just to keep sharp. The other week I wrote a NFC token reader to make my kid a media player for her room on a raspberry pi. I am actively involved in decompilation of some Nintendo 64 games. I have a project for a friend trying to figure out why one of his boards from 1993 is not working.
It would be incredibly unfair to say that people don't care about the deep dive when it's far more likely that they only care about a different part of the machine. Almost every developer I have ever worked with has had their own little niche topic of interest, be it streaming (and setting up a super overkill plex server and understanding how to do that effectively) or game design or retrocomputing or something.
For me, it's not that I don't care how React works. Rather, I find I have a mostly-automatic inference about how it should work. If it is well-designed (which many frameworks are), then I don't need to stress about the details as long as I stay in the common use cases.
That’s very cool! Also please never dig into how React works; it’s not terribly important, and I only brought it up as an example because the article did :) and I’m surprised that N64 games were even compiled; I’d thought that that was still the era of mostly handwritten assembly! TIL!
My coworkers have interests such as sports, alcohol, and travel. I’m glad that you’ve been able to find people who have similar interests as you — having had that before, it’s a fantastic experience! — but please understand that it’s not universal. A lot of people are in this career because it was both easy to get into and very lucrative.
For context I’m not saying that the above is the case for every developer on planet earth, just that chasing a decent salary inevitably removed the selection bias of shared interest from my cohort, which was both sad (for me) and predictable.
I'm in my late 30s and I definitely started off like this as I was learning and began working for small, local web dev agencies. Then as soon as I entered the corporate world ~10 years ago, it just became impossible for me to be like that. I don't have time within my working hours to get philosophical with my stack. All projects need to be done yesterday. There are half a dozen meetings that should've been an email or slack message. If I dare slow down to make sure I fully understand the how of the code I'm writing, I get labeled as "slow" and get lapped by code camp junior devs who just write code carefree with little understanding of the longterm impacts. Or I don't do enough code reviews or get enough commits in and then the stats looks funky when my annual review comes along.
The best I can do at work is rapidly start building things with new tech and learn what works, rather than how it works. And I'm not willing to sacrifice time with my family or my own mental health by digging into these things outside of work hours.
I am not a professional developer; and I barely consider myself an amateur developer, but I think I agree with your take. But I have never worked in a software dev job, so let me know if I am off base.
These things are just tools. You don’t need to know why a tool works, you just need to know how it works. A car mechanic doesn’t need to know how a compressed air motor works, or how a hammer and anvil on an impact wrench works. All they need to know is that they hit the trigger and the nut comes off.
Can knowing how your tools work improve your efficacy? Maybe. But is it required to be effective? Nope. I find it interesting to learn about how things work, but it doesn’t appear to be required to me.
Yep, and agreed (except I’m not sure what you mean by “philosophical”; for context, I’m saying that you could throw a dart and hit a coworker who doesn’t know mechanically understand what a packet is).
I’m a decade into my career, and I spent the first half of it working for smaller, local businesses, where there was a selection bias for people that would trade pay for interesting problems. I (correctly, imo) decided that retiring was more important than job satisfaction, so I switched to a role at a larger company … hence this conundrum.
And yeah, very much agreed re. deep understanding vs. hitting deadlines. I wouldn’t want anyone to sacrifice time outside of work to build up understanding, it’s that this is my “hobby” (as it was for several coworkers of jobs gone past), so they (and I at the time) didn’t view it as a sacrifice — it was fun, at the time.
Er, in sum, sorry that you’re in a similar position, I think. Hope the AI nonsense doesn’t chase you out of the job.
So far the AI nonsense isn't bothering me too much. It's more the people that are doing that (mainly project managers, middle management, etc.) and the "politics" of work. Maybe it's just my company, but getting yourself lined up for promotions is basically a part-time job in and of itself. All this career planning nonsense, ever-moving goalposts, vague requirements, and buttering up stakeholders. I just want to write some god damned code, ya know?
I've actually found AI to be very useful when migrating from one framework to another (eg "How do I do [thing in Angular] in React?") and then it gives me a brief breakdown of why it's completely different and some code samples. Or when I was learning Typescript I'd just give it an object and ask it to spit out a type for me. I'd use it, learn from it, and eventually stopped needing to ask CoPilot. Obviously it doesn't teach me everything, but it's a lot less friction than the "old" way of just googling it and clicking through people arguing on Stack Overflow.
I have no doubt though that as it evolves and weaves its way more and more into the industry that I'll get sick of it. They'll start using AI to assess your commits and analyze readiness for promotion. Or check your work against AI solutions and penalize you somehow for not being as efficient as a robot that stole other people's code. sigh
Ah ... yeah, no, that sounds similar. n=2 but I get the impression that's just large companies ...
That's definitely cool! I've also found it useful for picking up new libraries and whatnot, although when I last tried the tools (a couple months ago briefly, then more thoroughly a year ago), they really struggled with any library that couldn't be found on Stack Overflow. Ultimately it wound up more useful to look through those automated search results which steal code samples from GitHub and boost their SEO.
I'm looking forward to code review bots that tell me to do something incorrect, then having to justify ignoring the comment to management! Ah, and having to review AI generated code, or to assist coworkers when the AI gives them something that doesn't work.
Unrelatedly I'm trying to get out of tech in the next several years to find something else to spend my life on hahaha
haha, yeah I feel you. I can't tell you how many times I've googled "Jobs a developer can easily transition into". None of them sound appealing, except for Developer Advocate, but those seem very hard to come by without existing experience with the role!
Already there at my job! Though we can dismiss them whenever we like (assuming the required human reviewers don’t want those changes made).
In the first few seconds of the video the host goes over a sponsor message pushing WebStorm. I think it's pretty clear this is just a naming issue. Technically it should be a show specifically claiming to be for web developers. But web is one of the biggest, if not the biggest, platform for software development. So it's not crazy to have someone effectively make it the "default" mode of development in a game show.
As another oldster operating in this space, I can relate. It’s perplexing when I encounter colleagues who are proficient in TypeScript + React JSX idioms but have no real understanding of HTML and CSS, browser or HTTP fundamentals, or the specific functions of the bundlers, compilers, linters, formatters, and package managers their projects rely on. I’m constantly surprised how effectively a dev can operate at one layer of abstraction while being oblivious to all the others. Maybe it’s just because most of the other layers didn’t exist when I was getting started, but personally I feel like I have to grok it all otherwise none of today’s stacks will make any sense to me.
I agree with most of the post but this bit not so much. Arguably JS in a Node context is even more “vanilla” than in a browser because it’s divorced from all the
windowanddocumentcruft, etc. Modern frontend workflows blur the lines between what code is executing where, so I guess some devs might be confused about what Node even is (“oh, you meanyarn start?”) …but some of my favorite pure JS development is building CLI tools to run under Node, it really doesn’t get any more “vanilla” than that.Node has its own API’s and any non-trivial app probably depends on them, at least indirectly through libraries. So do other environments like Deno and CloudFlare workers.
Vanilla JavaScript is relevant for library code that has to be portable (runs in all these places), but that’s its own specialty that many people can ignore.
There are many types of people in any profession. Some are better at the job than others.
In programming, I often see two main types of people who end up being the most effective.
I've mentored quite a few people. The thing that seems to work the best is to give people context and explain a bit about how things work. Otherwise you end up with people being surprised when things are inefficient and the disconnect that is discussed in the article.
I think a problem with modern frameworks is that they hide a bit too much of the underlying behavior of a computer. And frameworks are released or updated very frequently. And most workplaces do not pay people to learn, they pay people to produce. So you end up with a situation where people are "writing" code by copying a block from a website, or copying from another program, or having copilot write it.
An example of how things go: My team started using React a lot lately. Previously we had used Angular or something else. We all just started using it. I see a lot of strange code of course. One common source of strange or bad code comes from the hook useEffect. My own journey with Effects went like this:
I see an example of useEffect to make something happens once when the page renders. That must be what it's for. Maybe to make a loading animation or something.
Then I need to add an event that happens in one component when a different component changes value. So I can add the 2nd component to the dependencies. That must be what useEffect is for.
Then I need to draw something on the page after an async call is made. Oh, that's really what effects are for!
So we should have had training and mentoring before anyone started typing. And my company gives access to Udemy courses but we didn't even do that.
Later we may finally read something like You might not need an effect. What, are we supposed to go back and rewrite the old stuff? We have new stuff to write and we have a bunch of other urgent security findings to resolve.
I find LLMs are especially useful when jumping from one framework to another - because they’re all trying to solve the same problems and generally have the same solutions as each other but with slight differences. You can have them port code and then explain each section, or ask it how to do X in framework Y given what you would have done in framework Z.
Also I noticed that they are good for writing unit tests. Nobody likes doing that but copilot doesn't complain. It mostly makes pretty reasonable ones too, but if it messes up something it doesn't seem to be able to correct so you still have to write some things by hand.
It doesn’t cover all cases. I think an LLM loop that checks for coverage would be pretty nice.
And I still find myself going back and adding a couple extra cases. But still a big win in my opinion.