5 ms·

> all the while ignoring that such usage actively keeps them from improving their own coding skills That's an opinion not a fact backed by any data. In fact i

> all the while ignoring that such usage actively keeps them from improving their own coding skills That's an opinion not a fact backed by any data. In fact it feels like "you hurt your hacking skills by using an IDE rather than a simple text editor, or higher level language than assembly, or managing your memory manually rather than using GCs". Also, maybe coding skills will become more and more irrelevant for most developers the same way knowing how memory or CPUs work is largely irrelevant for all but a tiny part of the industry. In fact, if AI assistants will keep getting better, the best skills to have will be ability to direct those assistants and overseeing their output while meeting business and product needs.

sgbeal 2y ago
> That's an opinion not a fact backed by any data. It's a well-demonstrated fact that, for the overwhelmingly large majority of people (mainly those without eidetic memory), copying someone else's answers, rather than coming up with them by applying one's own problem-solving skills, hurts one's ability to advance their own related knowledge/skills. There's a _reason_ we're taught not to cheat in school.
jebarker 2y ago
> the same way knowing how memory or CPUs work is largely irrelevant for all but a tiny part of the industry. This is not true. A large part of the industry just _thinks_ these things aren't relevant to them and that's why we have such terrible software everywhere.
- epolanski 2y ago
  I don't buy this, at all. In my industry experience software is slow because: - time to market is overwhelmingly more important than performance so the pressure is to have something that works, not something that works smoothly. You can fix performance or bugs later (Notion is an easy example of such evolution). - the industry keeps being largely understaffed so finding resources to allocate to performance is hard - most of the industry is managed by people that are neither good at product nor tech, but think they understand products and tech
  - jebarker 2y ago
    The point is that if you understand how the high-level code you write gets translated to what runs on the actual CPU and memory then you write more performant high-level code by default the first time round. So you can get to market just as quickly. Doesn't mean there's not more speed or memory optimizations you can make later but you just raise the bar generally.
    - epolanski 2y ago
      please make a general simple example of how knowing memory and cpu applies to overwhelming majority of people out there glueing APIs together.
      - jebarker 2y ago
        I'm not ignoring your request, but I need to think about it a little as my day to day work isn't just pasting together APIs. If the only thing an engineer is allowed to do is paste together a fixed set of APIs then they may well be completely limited.
      - fragmede 2y ago
        Knowing how the underlying system - CPU ram network db - works is the difference between using an ORM or SQL query to do SELECT * FROM db across the network, and filtering it locally with program code, and using a WHERE clause in the SQL, a pattern I've fixed for multiple startups.

sgbeal 2y ago

> That's an opinion not a fact backed by any data. It's a well-demonstrated fact that, for the overwhelmingly large majority of people (mainly those without eidetic memory), copying someone else's answers, rather than coming up with them by applying one's own problem-solving skills, hurts one's ability to advance their own related knowledge/skills. There's a _reason_ we're taught not to cheat in school.

jebarker 2y ago

> the same way knowing how memory or CPUs work is largely irrelevant for all but a tiny part of the industry. This is not true. A large part of the industry just _thinks_ these things aren't relevant to them and that's why we have such terrible software everywhere.

epolanski 2y ago
I don't buy this, at all. In my industry experience software is slow because: - time to market is overwhelmingly more important than performance so the pressure is to have something that works, not something that works smoothly. You can fix performance or bugs later (Notion is an easy example of such evolution). - the industry keeps being largely understaffed so finding resources to allocate to performance is hard - most of the industry is managed by people that are neither good at product nor tech, but think they understand products and tech
- jebarker 2y ago
  The point is that if you understand how the high-level code you write gets translated to what runs on the actual CPU and memory then you write more performant high-level code by default the first time round. So you can get to market just as quickly. Doesn't mean there's not more speed or memory optimizations you can make later but you just raise the bar generally.
  - epolanski 2y ago
    please make a general simple example of how knowing memory and cpu applies to overwhelming majority of people out there glueing APIs together.
    - jebarker 2y ago
      I'm not ignoring your request, but I need to think about it a little as my day to day work isn't just pasting together APIs. If the only thing an engineer is allowed to do is paste together a fixed set of APIs then they may well be completely limited.
    - fragmede 2y ago
      Knowing how the underlying system - CPU ram network db - works is the difference between using an ORM or SQL query to do SELECT * FROM db across the network, and filtering it locally with program code, and using a WHERE clause in the SQL, a pattern I've fixed for multiple startups.