13 ms·

> 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 ju

> 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.

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.