7 ms·

> The fact that a library discourages you from learning it's internals is how you know it's well done. If you needed to understand it, you could. The reason you

> The fact that a library discourages you from learning it's internals is how you know it's well done. If you needed to understand it, you could. The reason you don't is because you've never had a compelling reason to. I don't think we need to protect people from learning internals, they do that just fine on their own. I know many situations where we failed to understand internals even in the presence of compelling reason. With apologies for continuing to quote myself: "I want to carve steps into the wall of the learning process. Most programs today yield insight only after days or weeks of unrewarded effort. I want an hour of reward for an hour (or three) of effort." -- http://akkartik.name/about http://akkartik.name/about

marktani 5y ago
what is an hour of reward? I understand reward in terms of some form of a joyful/insightful/... experience, not in terms of time
- akkartik 5y ago
  I think an older version said, "an hour's worth of reward." Does that seem clearer? Thanks.
- coldtea 5y ago
  Parent talks about how fast you get back results from effort (learning, fiddling, etc) spent: "Most programs today yield insight only after days or weeks of unrewarded effort. I want an hour of reward for an hour (or three) of effort." So they want to be rewarded with at least an hour of saved time, or more productive time, for one (or few) hours they put in, instead of spending weeks to reap rewards.
  - akkartik 5y ago
    I was just alluding to a subjective sense that you got something reasonable for your trouble and efforts. You could do something, or you learned something, or you were entertained. My argument doesn't depend too much on the precise meaning, I think.
hinkley 5y ago
I’ve been coming around to the conclusion that some coding patterns, especially overuse of delegation and mutation of inputs, make code hard to learn. I talk occasionally about viewing your code from the debugger but that is kind of hand wavy. I wonder if there’s a ‘linter’ one could write that looks at coverage or trace reports and complains about bad patterns.
- tlarkworthy 5y ago
  yes, lately the Butler Lampson quote echos round my head "All problems in computer science can be solved by another level of indirection" The problem is, we have been adding layers of indirection for 80 years, and each is leaky. So now it's very difficult to do basic stuff, and people are ok with software thick with abstractions. The next stage should be removing unnecessary layers of indirection, as, like you said, things are much easier to understand and maintain that way.
  - randallsquared 5y ago
    It's very easy to do basic stuff. It's hard to do basic stuff (or anything) well, since you end up having to solve problems that should have been solved by layers you're building upon.
  - tejtm 5y ago
    The remainder of the quote Butler quoted matters; "All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection." -- David Wheeler
    - hinkley 5y ago
      And performance. You speed things up by removing a layer of indirection.
  - eternityforest 5y ago
    We haven't been monotonically stacking layers steadily. In fact sometimes we collapse layers into monoliths. Sometimes we rebuild layers and make them bigger. But we don't have 900 layers or anything. Performance is... usually pretty darn good, except for uneccessary disk writes. It's trivial to do basic stuff because of those layers. What's hard is doing low level things from scratch in a way that doesn't conflict. But at the same time, there's less and less need for that. I think things are way easier to maintain with a bunch of layers than the old school ravioli code. Most layers are specifically meant to make it easier to maintain, or they just formalize a layer that was already effectively there, but was built into another layer in an ad hoc manner.
geofft 5y ago
The difficult part about having opinions about the industry of software engineering is that it is, somehow, a largely enjoyable job. But those two things are never going to be perfectly aligned. Enjoyment of the process does not guarantee working results that people want to pay for, and the thing that people want to pay for may be deeply unenjoyable. You can choose to tackle a subset of the problem space that happens to be both enjoyable and worthwhile, but you ought to admit that you are looking at a subset of the problem space. I do a lot of other things with my time that are also near the confluence of enjoyable and marketable. I sing, for instance, and choir rehearsal and individual vocal practice are both a lot of fun. But any professional musician will tell you that if you want to be world-class at it, you occasionally have to wring the fun out of it. I've chosen the other option: I'm a volunteer singer with my church choir. I sing because it is fun, and only insofar as it is fun. We do new and not-very-difficult music each week, and an hour of effort is inherently an hour of reward. If my choir director said we're going to spend six months drilling some difficult measures and perfecting our German pronunciation, we'd all leave. (In that sense, a volunteer church choir is rather like hobbyist open-source development. If it produces an enjoyable result for the public, great, and we do find that rewarding. But there is an upper bound on just how hard we're going to try and on the complexity of what we commit to doing.) If you want an hour of reward after an hour of programming effort, that's fine! But the employment contract I've signed promises a year of payment after a year of effort. Occasionally, I want to work on things that are immediately rewarding because that helps with motivation. And it's important that such work is available. But I have a job that ultimately demands specific products, some of which just aren't going to be immediately rewarding, some of which do actually take a lengthy learning process, and - most importantly - many of which require building on top of other people's work that I could understand if I wanted but there is no business value in doing so up front. (Incidentally, in the other direction, there are cases where I want to tackle problems that promise years of reward only after multiple years of effort, and figuring out how to get time to work on those problems is actually hard, too.) We share almost all our code internally and leverage lots of open-source code so that we all have the option of understanding the code if we need it - but we rely on division of labor so that we have the option of building something on top of the existing base today, if we need that, which is more often what we need. If you want to work on a hobbyist UNIX-like kernel for enjoyment's sake, great, I'm genuinely happy for you. But my servers at work are going to keep running a kernel with millions of lines of code I've never read, because I need those servers to work now.
eternityforest 5y ago
I probably should be more clear, i don't think we should make it hard to learn how they work, or do anything to stop them, and we should probably even make easier, but at the same time, we should make in unnecessary, so we can get stuff done with maximum reuse and minimum monkey patching and custom stuff.

marktani 5y ago

what is an hour of reward? I understand reward in terms of some form of a joyful/insightful/... experience, not in terms of time

akkartik 5y ago
I think an older version said, "an hour's worth of reward." Does that seem clearer? Thanks.
coldtea 5y ago
Parent talks about how fast you get back results from effort (learning, fiddling, etc) spent: "Most programs today yield insight only after days or weeks of unrewarded effort. I want an hour of reward for an hour (or three) of effort." So they want to be rewarded with at least an hour of saved time, or more productive time, for one (or few) hours they put in, instead of spending weeks to reap rewards.
- akkartik 5y ago
  I was just alluding to a subjective sense that you got something reasonable for your trouble and efforts. You could do something, or you learned something, or you were entertained. My argument doesn't depend too much on the precise meaning, I think.

hinkley 5y ago

I’ve been coming around to the conclusion that some coding patterns, especially overuse of delegation and mutation of inputs, make code hard to learn. I talk occasionally about viewing your code from the debugger but that is kind of hand wavy. I wonder if there’s a ‘linter’ one could write that looks at coverage or trace reports and complains about bad patterns.

tlarkworthy 5y ago
yes, lately the Butler Lampson quote echos round my head "All problems in computer science can be solved by another level of indirection" The problem is, we have been adding layers of indirection for 80 years, and each is leaky. So now it's very difficult to do basic stuff, and people are ok with software thick with abstractions. The next stage should be removing unnecessary layers of indirection, as, like you said, things are much easier to understand and maintain that way.
- randallsquared 5y ago
  It's very easy to do basic stuff. It's hard to do basic stuff (or anything) well, since you end up having to solve problems that should have been solved by layers you're building upon.
- tejtm 5y ago
  The remainder of the quote Butler quoted matters; "All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection." -- David Wheeler
  - hinkley 5y ago
    And performance. You speed things up by removing a layer of indirection.
- eternityforest 5y ago
  We haven't been monotonically stacking layers steadily. In fact sometimes we collapse layers into monoliths. Sometimes we rebuild layers and make them bigger. But we don't have 900 layers or anything. Performance is... usually pretty darn good, except for uneccessary disk writes. It's trivial to do basic stuff because of those layers. What's hard is doing low level things from scratch in a way that doesn't conflict. But at the same time, there's less and less need for that. I think things are way easier to maintain with a bunch of layers than the old school ravioli code. Most layers are specifically meant to make it easier to maintain, or they just formalize a layer that was already effectively there, but was built into another layer in an ad hoc manner.

geofft 5y ago

The difficult part about having opinions about the industry of software engineering is that it is, somehow, a largely enjoyable job. But those two things are never going to be perfectly aligned. Enjoyment of the process does not guarantee working results that people want to pay for, and the thing that people want to pay for may be deeply unenjoyable. You can choose to tackle a subset of the problem space that happens to be both enjoyable and worthwhile, but you ought to admit that you are looking at a subset of the problem space. I do a lot of other things with my time that are also near the confluence of enjoyable and marketable. I sing, for instance, and choir rehearsal and individual vocal practice are both a lot of fun. But any professional musician will tell you that if you want to be world-class at it, you occasionally have to wring the fun out of it. I've chosen the other option: I'm a volunteer singer with my church choir. I sing because it is fun, and only insofar as it is fun. We do new and not-very-difficult music each week, and an hour of effort is inherently an hour of reward. If my choir director said we're going to spend six months drilling some difficult measures and perfecting our German pronunciation, we'd all leave. (In that sense, a volunteer church choir is rather like hobbyist open-source development. If it produces an enjoyable result for the public, great, and we do find that rewarding. But there is an upper bound on just how hard we're going to try and on the complexity of what we commit to doing.) If you want an hour of reward after an hour of programming effort, that's fine! But the employment contract I've signed promises a year of payment after a year of effort. Occasionally, I want to work on things that are immediately rewarding because that helps with motivation. And it's important that such work is available. But I have a job that ultimately demands specific products, some of which just aren't going to be immediately rewarding, some of which do actually take a lengthy learning process, and - most importantly - many of which require building on top of other people's work that I could understand if I wanted but there is no business value in doing so up front. (Incidentally, in the other direction, there are cases where I want to tackle problems that promise years of reward only after multiple years of effort, and figuring out how to get time to work on those problems is actually hard, too.) We share almost all our code internally and leverage lots of open-source code so that we all have the option of understanding the code if we need it - but we rely on division of labor so that we have the option of building something on top of the existing base today, if we need that, which is more often what we need. If you want to work on a hobbyist UNIX-like kernel for enjoyment's sake, great, I'm genuinely happy for you. But my servers at work are going to keep running a kernel with millions of lines of code I've never read, because I need those servers to work now.

eternityforest 5y ago

I probably should be more clear, i don't think we should make it hard to learn how they work, or do anything to stop them, and we should probably even make easier, but at the same time, we should make in unnecessary, so we can get stuff done with maximum reuse and minimum monkey patching and custom stuff.