I'm on the same boat, negatively affected by AI. I'm the CEO and founder of an EdTech company and our B2C revenue has greatly decreased as a result of Gen AI.
But unlike the author of this post (or cited authors) I'm not sore. AI is providing a much better education model for students. So it's us that we have to adapt, not complain that the world is changing.
For example, in Machine Learning our projects are sometimes extremely long and repetitive. Because before AI, it was a valuable skill to be able to recall APIs quickly (what is the method to drop duplicates in a dataframe again?).
But today that's no longer the truth, and for the better. I am happy students don't have to go over the same repetitive low-value processes that I had to go to.
Students can now focus on more high level valuable tasks: understand the domain, compare evaluation methods, compare models, balance tradeoffs, present solutions/reports, etc.
It's like in the 50s when students had to memorize tables of logarithms. Nobody misses that.
We are in the process of recreating all our projects to adapt to the new world. We'll see how it goes.
>But today that's no longer the truth, and for the better. I am happy students don't have to go over the same repetitive low-value processes that I had to go to.
It's a real shame a leader of an education company doesn't value the actual learning process. Those "low value" processes are the building blocks to understand and master high level concepts. I'm not spending my day to day thinking about the low level memory allocation in my job, but that knowledge and work helps immensely in how I approach the higher level assignments and wider architecture. And I still kick myself because my assembly knowledge is is only 1.5 semester's worth.
And yes, I still look up how to construct an array in C++. Not really because my memory is bad (okay, kind of), but more for the practice of reviewing API's and parameters and maybe making new revelations. I probably knew internally some 12 years ago I could set an initial capacity in one of the array's constructors. I didn't really "understand" the value in that until one random work day 4 years later as I was working through some in-house container packages.
You can even say that doesn't matter if you know what resize() is, but it's those little bits of learning nuggets that builds you up from a "fine engineer" to a "great engineer". Less the knowledge and more the work ethics built to obtain it.
> before AI, it was a valuable skill to be able to recall APIs quickly
That’a the low value they’re talking about. And all of that stuff is accidental complexity.
To use their example, you need to know that dropping duplicates is a good idea (and why). Knowing what the syntax and api calls to do that is, in my opinion, unnecessary.
That's not accidental, anymore than human language itself is accidental. APIs are designed very intentionally, and a good API's parameters have architectural reasons behind what they include (or exclude).
Even your example has unintentional complexity. A 'duplicate'? What's that? Do we compare the memory it points to? Through use of a custom comparator function?by an id or tag? APIs and entire languages are designed around how we define such seemingly simple terms.
Ultimately a language, be it a programming language or human one, is about communication. I find there to be value in knowing how to communicate effectively, even if employers increasingly disregard the value of such knowledge. Without it, we'll quickly find out why it's fundamentall quickly.
“Computer add a filter that removes all duplicate entries from this data structure. Two entries are duplicates if they every value in their rows are identical.”
This is the same thing as pressing the power button on my computer; I want the thing turned on, I don’t want to have to know about memory training.
>I don’t want to have to know about memory training.
And then we wonder why apps are getting so much slower and bloated. That's fine if you don't want to think that low level, but someone needs to worry about performance. And others will need different needs for defining a duplicate in their different use cases.
I don’t think that lack of knowledge about memory training is a hill to die on when it comes to causes of app bloat.
The people who need to most think about performance are those making the frameworks and languages. Why are bloated electron apps so easy to make but building native cross-platform apps with similar ergonomics hard? Why are people choosing electron?
>The people who need to most think about performance are those making the frameworks and languages.
Yes. I am not a web dev, but I tend to fall into that category in my domain.
>Why are bloated electron apps so easy to make but building native cross-platform apps with similar ergonomics hard?
If you want to be blunt, it's political. Each OS wants to ultimately build its own moat, so there's less incentive to come together and make a standardized solution. Then Linux is a less centralized OS that makes theoretical cross platform support even harder. Cross platform applications get made despite that friction to fill the obvious demand.
The why's of which cross platform framework wins is hard to say. It only becomes obvious that whoever breaks out tends to win more, and it gets a massive flood of support, funding, and clients. So it snowballs up. Those who don't simply struggle to stay relevant.
Electron likely wins in the market aspect that bloat isn't enough friction to turn off a modern consumer with a modernish (10 years or younger) desktop. And it especially doesn't matter to phones (which tend to skew newer).
Then based on your own analysis, at least the electron bloat angle (that many people, at least many developers, hate and wish was native) has nothing to do with the low level knowledge of the developer. And I would argue that a good deal of other areas of slow software will have the same conclusion, i.e. the slowness is not due to lack of knowledge.
We've had encyclopedias, textbooks, and the Internet for decades. Being able to recall things quickly is still very valuable in most white collar jobs because the person with the quick recall is a lot faster than the person who has to look up the information every time.
santiagobasulto · · focus · HN ↗
But unlike the author of this post (or cited authors) I'm not sore. AI is providing a much better education model for students. So it's us that we have to adapt, not complain that the world is changing.
For example, in Machine Learning our projects are sometimes extremely long and repetitive. Because before AI, it was a valuable skill to be able to recall APIs quickly (what is the method to drop duplicates in a dataframe again?).
But today that's no longer the truth, and for the better. I am happy students don't have to go over the same repetitive low-value processes that I had to go to. Students can now focus on more high level valuable tasks: understand the domain, compare evaluation methods, compare models, balance tradeoffs, present solutions/reports, etc.
It's like in the 50s when students had to memorize tables of logarithms. Nobody misses that.
We are in the process of recreating all our projects to adapt to the new world. We'll see how it goes.
johnnyanmac · · focus · HN ↗
It's a real shame a leader of an education company doesn't value the actual learning process. Those "low value" processes are the building blocks to understand and master high level concepts. I'm not spending my day to day thinking about the low level memory allocation in my job, but that knowledge and work helps immensely in how I approach the higher level assignments and wider architecture. And I still kick myself because my assembly knowledge is is only 1.5 semester's worth.
And yes, I still look up how to construct an array in C++. Not really because my memory is bad (okay, kind of), but more for the practice of reviewing API's and parameters and maybe making new revelations. I probably knew internally some 12 years ago I could set an initial capacity in one of the array's constructors. I didn't really "understand" the value in that until one random work day 4 years later as I was working through some in-house container packages.
You can even say that doesn't matter if you know what resize() is, but it's those little bits of learning nuggets that builds you up from a "fine engineer" to a "great engineer". Less the knowledge and more the work ethics built to obtain it.
_aavaa_ · · focus · HN ↗
That’a the low value they’re talking about. And all of that stuff is accidental complexity.
To use their example, you need to know that dropping duplicates is a good idea (and why). Knowing what the syntax and api calls to do that is, in my opinion, unnecessary.
johnnyanmac · · focus · HN ↗
Even your example has unintentional complexity. A 'duplicate'? What's that? Do we compare the memory it points to? Through use of a custom comparator function?by an id or tag? APIs and entire languages are designed around how we define such seemingly simple terms.
Ultimately a language, be it a programming language or human one, is about communication. I find there to be value in knowing how to communicate effectively, even if employers increasingly disregard the value of such knowledge. Without it, we'll quickly find out why it's fundamentall quickly.
_aavaa_ · · focus · HN ↗
This is the same thing as pressing the power button on my computer; I want the thing turned on, I don’t want to have to know about memory training.
johnnyanmac · · focus · HN ↗
And then we wonder why apps are getting so much slower and bloated. That's fine if you don't want to think that low level, but someone needs to worry about performance. And others will need different needs for defining a duplicate in their different use cases.
_aavaa_ · · focus · HN ↗
The people who need to most think about performance are those making the frameworks and languages. Why are bloated electron apps so easy to make but building native cross-platform apps with similar ergonomics hard? Why are people choosing electron?
johnnyanmac · · focus · HN ↗
Yes. I am not a web dev, but I tend to fall into that category in my domain.
>Why are bloated electron apps so easy to make but building native cross-platform apps with similar ergonomics hard?
If you want to be blunt, it's political. Each OS wants to ultimately build its own moat, so there's less incentive to come together and make a standardized solution. Then Linux is a less centralized OS that makes theoretical cross platform support even harder. Cross platform applications get made despite that friction to fill the obvious demand.
The why's of which cross platform framework wins is hard to say. It only becomes obvious that whoever breaks out tends to win more, and it gets a massive flood of support, funding, and clients. So it snowballs up. Those who don't simply struggle to stay relevant.
Electron likely wins in the market aspect that bloat isn't enough friction to turn off a modern consumer with a modernish (10 years or younger) desktop. And it especially doesn't matter to phones (which tend to skew newer).
_aavaa_ · · focus · HN ↗
gamblor956 · · focus · HN ↗
_aavaa_ · · focus · HN ↗
I don’t have to remember assembly intrinsic since the compiler deals with that, I just describe the higher level goal and it implements it.