5 ms·

Don't think about how a library works - until you have to

by ape4 5y ago

WJW 5y ago
How do you know when you have to? There might be dozens of libraries in just the current project that we could be using more effectively if only we'd taken the time to read the source.
- Jtsummers 5y ago
  We have this wonderful organ called a "brain". It appears to be the center of reasoning. We apply that to the situation and end up drawing a line where we say, "Beyond this point, I will not look. I may learn what it does, but I will not dwell on how it does it, neither in principle (conceptual model) nor in fact (actual code). Because if I were to investigate this, and every other such system, I would find that it is turtles all the way down and I will never actually complete my objective. Unless I choose to freeze all these dependencies at this one moment in time and never permit them to change. If, in the course of my work, I find that this particular area is a source of trouble or a possible source of solution, then I will investigate further. On my own, with my team, directing a team member, or contacting the responsible party." It's a noble goal to make systems that are comprehensible, and one that should be striven for more often. It's also a noble goal to try to fully understand the stack of dependencies. But short of freezing time (this subsystem will never be permitted to change after I have studied it, except by my own hand), spending a lifetime on a more narrow field, being in the top 0.0001% of intellects, or working on relatively simple systems, it's infeasible in the general case. Once you try and do something even as "simple" as build out an avionics system for an aircraft, it will quickly explode into too many domains for any one person to truly comprehend every detail.
  - WJW 5y ago
    You are certainly much smarter (or more inexperienced in aircraft software design) than me if you think avionics systems are simple. But yes, I also have a brain and can reason with it. You don't have to restate the obvious as if it is some deep wisdom. But parent comment made the point that you should only look at library code when you have to and I countered that you cannot know when you have to without looking. Your counter-counter that you must think about what you have seen does not help with deciding when to start looking in the first place.
    - TameAntelope 5y ago
      Why do you think there's some algorithm you should run that will, in some determinate sense, tell you how to behave here? The comment you're replying to was poking fun at you for assuming there would be some objective set of criteria, when in reality there isn't anything of the sort. There are a lot of heuristics I use when picking out a 3rd party library, but I'm an engineer and these heuristics are practical, so I doubt you'll enjoy thinking in those terms, if your prior comments are any indication of what you're looking for here.
      - WJW 5y ago
        As a fellow engineer, I would indeed like actual reasons for why to pick one library over another. Even if that reason is as simple as "profiling shows we spend 99% of a request in this single library". Falling back to experience, heuristics and "just use your brain" can work in some circumstances (and with sufficiently experienced developers), but it is not how an engineering discipline matures.
        TameAntelope 5y ago
        ...do you seriously not know how to evaluate 3rd party libraries? I can help you if you want, but honestly if this is a challenge for you, I'd be worried about whether or not this is the right career for you. Engineers get shit done, first and foremost. If that's not your primary concern, you're going to spend a lot of time frustrated by your bosses priorities and confused about why your peers value things you don't.
        WJW 5y ago
        This goes back to the discussion we had on https://news.ycombinator.com/item?id=29998868 https://news.ycombinator.com/item?id=29998868, about whether sofware developers are really engineers or not. If you think "getting shit done" is the only or even the primary concern for an engineer, I think it is best if you stay in software (and please far away from any safety critical code).

Don't think about how a library works - until you have to

by ape4 5y ago

Don't think about how a library works - until you have to

WJW 5y ago

How do you know when you have to? There might be dozens of libraries in just the current project that we could be using more effectively if only we'd taken the time to read the source.

Jtsummers 5y ago
We have this wonderful organ called a "brain". It appears to be the center of reasoning. We apply that to the situation and end up drawing a line where we say, "Beyond this point, I will not look. I may learn what it does, but I will not dwell on how it does it, neither in principle (conceptual model) nor in fact (actual code). Because if I were to investigate this, and every other such system, I would find that it is turtles all the way down and I will never actually complete my objective. Unless I choose to freeze all these dependencies at this one moment in time and never permit them to change. If, in the course of my work, I find that this particular area is a source of trouble or a possible source of solution, then I will investigate further. On my own, with my team, directing a team member, or contacting the responsible party." It's a noble goal to make systems that are comprehensible, and one that should be striven for more often. It's also a noble goal to try to fully understand the stack of dependencies. But short of freezing time (this subsystem will never be permitted to change after I have studied it, except by my own hand), spending a lifetime on a more narrow field, being in the top 0.0001% of intellects, or working on relatively simple systems, it's infeasible in the general case. Once you try and do something even as "simple" as build out an avionics system for an aircraft, it will quickly explode into too many domains for any one person to truly comprehend every detail.
- WJW 5y ago
  You are certainly much smarter (or more inexperienced in aircraft software design) than me if you think avionics systems are simple. But yes, I also have a brain and can reason with it. You don't have to restate the obvious as if it is some deep wisdom. But parent comment made the point that you should only look at library code when you have to and I countered that you cannot know when you have to without looking. Your counter-counter that you must think about what you have seen does not help with deciding when to start looking in the first place.
  - TameAntelope 5y ago
    Why do you think there's some algorithm you should run that will, in some determinate sense, tell you how to behave here? The comment you're replying to was poking fun at you for assuming there would be some objective set of criteria, when in reality there isn't anything of the sort. There are a lot of heuristics I use when picking out a 3rd party library, but I'm an engineer and these heuristics are practical, so I doubt you'll enjoy thinking in those terms, if your prior comments are any indication of what you're looking for here.
    - WJW 5y ago
      As a fellow engineer, I would indeed like actual reasons for why to pick one library over another. Even if that reason is as simple as "profiling shows we spend 99% of a request in this single library". Falling back to experience, heuristics and "just use your brain" can work in some circumstances (and with sufficiently experienced developers), but it is not how an engineering discipline matures.
      - TameAntelope 5y ago
        ...do you seriously not know how to evaluate 3rd party libraries? I can help you if you want, but honestly if this is a challenge for you, I'd be worried about whether or not this is the right career for you. Engineers get shit done, first and foremost. If that's not your primary concern, you're going to spend a lot of time frustrated by your bosses priorities and confused about why your peers value things you don't.
        WJW 5y ago
        This goes back to the discussion we had on https://news.ycombinator.com/item?id=29998868 https://news.ycombinator.com/item?id=29998868, about whether sofware developers are really engineers or not. If you think "getting shit done" is the only or even the primary concern for an engineer, I think it is best if you stay in software (and please far away from any safety critical code).