6 ms·

I think a better title might be "A vast majority of programming is done at a level of abstraction that this author is slightly uncomfortable with". If you work

by rjbwork 12y ago

I think a better title might be "A vast majority of programming is done at a level of abstraction that this author is slightly uncomfortable with". If you work in Java or Ruby or Python or C#, or even C++ all day with say, an IoC container for argument's sake, you're certainly not constantly thinking "okay this interface will be resolved to this type, which has these dependencies which will be resovled to these types, which generate this byte code, which generates this JITed assembly code, which generates this machine code, which generates these executions of instructions on the processor and accesses these memories, which invokes these manipulations of these gates and flip flops on this particular part of the ALU". Doing so would be the mark of an unproductive madman.

ggchappell 12y ago
That's an interesting way of putting it. The issue is that we all have our own (more or less completely undocumented) abstractions that we mentally put on top of whatever language/library we're using. And sometimes these mental abstractions are out of sync with reality.
dandelany 12y ago
I don't think this is about abstraction. Abstraction implies having a deep understanding of the problem domain and encapsulating it in such a way that the implementation details can be ignored and the domain can be reasoned about at a higher level. I think a better title would be "A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors".
- rjbwork 12y ago
  Perhaps. One could argue that one of these init file templates is just a base class with parts of the implementation overridden. :D
- tjradcliffe 12y ago
  So an even better alternative title would be "The Author of This Essay Does Not Understand Engineering, Software, Technology, Medicine, Or Any of the Other Practical Arts Which Have Always Involved Shipping Imperfectly Understood Machines".
  - rwallace 12y ago
    If you read the full text of the original post, it becomes clear that the author does understand the practical arts because he acknowledges that it has to be this way even if it's not what we would ideally like.
- betenoire 12y ago
  I agree: layers of something != abstraction
  - Sir_Substance 12y ago
    I might keep that one.
- nostrademons 12y ago
  "A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors" Of course. Time spent fully understanding the code before it's shipped is time that it's not shipped. This is sort of a Gresham's-Law situation, where "bad code drives out good code". The code that is fully tested & debugged with all situations understood isn't available to the user at first. As a result, they go with the "good enough" solution, build stuff off of it, and by the time "the right thing" comes along, all the momentum has shifted to its crappy competitor. A bunch of crappy software gets built on top of that, and as a result, we end users get the worst thing that could possibly work. But work it does. Maybe it's worth a shift in perspective to be grateful for the stuff that works rather than worry about the stuff that doesn't quite work right.
  - Swizec 12y ago
    Anyone can build a bridge that stands up, but only an engineer can build a bridge that barely stands up. Good Enough is our main design goal. Anything more than good enough means you're wasting resources.
    - avmich 12y ago
      And that applies not only to engineers, but to managers - i.e., task definers. Managers aren't interested to ask engineers to build something which will withstand the test of time unless they are sure that time will be actually needed - and with limited information (and high speed of changes) you have today managers tend to think short term. So the whole civilization works along the principle of dog chasing the rabbit running from left to right - instead of predicting where rabbit will be in 10 seconds, let's run straight towards the rabbit and in half a second update the course. We win since rabbits don't usually run predictably along the straight line.
      - Swizec 12y ago
        It sounds like a good task definer (or engineer) should be able to know when thinking a bit further ahead matters and when it doesn't. For instance, you probably need to take a bit more care with defining your core database structure, than you do with positioning a button 20px to the left or right.
- engi_nerd 12y ago
  I don't think it's about the act of creating an abstraction, but rather, about using these abstractions with a deficient understanding of the limitations and implications of these abstractions. I agree with you that a significant amount of code is not fully understood by its authors. I see similar phenomena at work in many engineering projects. Relatively few engineers work at the component or board level, rather they work at the subsystem and system levels. They piece parts of systems together to make larger systems-of-systems (sound familiar, programmers?) often with a poor understanding of when the black-box abstractions they deal with can break down and cause havoc. Currently fighting against this in my own workplace, where it's become clear that many engineers do not understand the system we support in sufficient detail to properly troubleshoot faults with that system.
- roel_v 12y ago
  "I think a better title would be "A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors"." Well duh. Not a single program shipped today, no matter how small, is "fully" understood by its authors, because to do so, one would have to understand every implementation nuance and bug of OS layers, libraries used, other parts it interacts with, ... And even for less strict definitions of "fully" - for any program that took longer than say 2 weeks to write, how can anyone claim they really know the details of everything, at the same time? Including the nuanced differences between various of OS calls, and the effect some environment variable might have on your localization code, just to name one thing?
deleted 12y ago
[deleted]
keeperofdakeys 12y ago
Think of the times when you're using an unfamiliar api, and your browser tabs are split between documentation and stackoverflow posts. Eventually, you get something to work. If you just clean your hands, and say "I'm done", you've fallen into the trap that the article talks about. You might look at the code occasionally, and think "maybe I can clean this up?". However ,after a few minutes, you realise how much you don't understand what's going on. So you leave the code, in a sort of superstition - it works after all. After a few years, when you need to finally modify the code, you've got a problem. The code works, but you never took the time to understand why it works. If there were any superfluous calls, or side-effects that you don't want now, you'll need to take the time to understand how it all works. If you took the time to understand it originally, and wrote a few informative comments, you might have saved yourself hours of work. It must be said though, occasionally you do need to go deeper with your thinking. To figure out why some bug is occuring, or maybe some complex performance issue. So it is important to have some knowledge of how it all fits together, even if you don't need it all the time.

by rjbwork 12y ago

ggchappell 12y ago

That's an interesting way of putting it. The issue is that we all have our own (more or less completely undocumented) abstractions that we mentally put on top of whatever language/library we're using. And sometimes these mental abstractions are out of sync with reality.

dandelany 12y ago

I don't think this is about abstraction. Abstraction implies having a deep understanding of the problem domain and encapsulating it in such a way that the implementation details can be ignored and the domain can be reasoned about at a higher level. I think a better title would be "A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors".

rjbwork 12y ago
Perhaps. One could argue that one of these init file templates is just a base class with parts of the implementation overridden. :D
tjradcliffe 12y ago
So an even better alternative title would be "The Author of This Essay Does Not Understand Engineering, Software, Technology, Medicine, Or Any of the Other Practical Arts Which Have Always Involved Shipping Imperfectly Understood Machines".
- rwallace 12y ago
  If you read the full text of the original post, it becomes clear that the author does understand the practical arts because he acknowledges that it has to be this way even if it's not what we would ideally like.
betenoire 12y ago
I agree: layers of something != abstraction
- Sir_Substance 12y ago
  I might keep that one.
nostrademons 12y ago
"A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors" Of course. Time spent fully understanding the code before it's shipped is time that it's not shipped. This is sort of a Gresham's-Law situation, where "bad code drives out good code". The code that is fully tested & debugged with all situations understood isn't available to the user at first. As a result, they go with the "good enough" solution, build stuff off of it, and by the time "the right thing" comes along, all the momentum has shifted to its crappy competitor. A bunch of crappy software gets built on top of that, and as a result, we end users get the worst thing that could possibly work. But work it does. Maybe it's worth a shift in perspective to be grateful for the stuff that works rather than worry about the stuff that doesn't quite work right.
- Swizec 12y ago
  Anyone can build a bridge that stands up, but only an engineer can build a bridge that barely stands up. Good Enough is our main design goal. Anything more than good enough means you're wasting resources.
  - avmich 12y ago
    And that applies not only to engineers, but to managers - i.e., task definers. Managers aren't interested to ask engineers to build something which will withstand the test of time unless they are sure that time will be actually needed - and with limited information (and high speed of changes) you have today managers tend to think short term. So the whole civilization works along the principle of dog chasing the rabbit running from left to right - instead of predicting where rabbit will be in 10 seconds, let's run straight towards the rabbit and in half a second update the course. We win since rabbits don't usually run predictably along the straight line.
    - Swizec 12y ago
      It sounds like a good task definer (or engineer) should be able to know when thinking a bit further ahead matters and when it doesn't. For instance, you probably need to take a bit more care with defining your core database structure, than you do with positioning a button 20px to the left or right.
engi_nerd 12y ago
I don't think it's about the act of creating an abstraction, but rather, about using these abstractions with a deficient understanding of the limitations and implications of these abstractions. I agree with you that a significant amount of code is not fully understood by its authors. I see similar phenomena at work in many engineering projects. Relatively few engineers work at the component or board level, rather they work at the subsystem and system levels. They piece parts of systems together to make larger systems-of-systems (sound familiar, programmers?) often with a poor understanding of when the black-box abstractions they deal with can break down and cause havoc. Currently fighting against this in my own workplace, where it's become clear that many engineers do not understand the system we support in sufficient detail to properly troubleshoot faults with that system.
roel_v 12y ago
"I think a better title would be "A significant amount of (shipped, so-called production-quality) code is not fully understood by its authors"." Well duh. Not a single program shipped today, no matter how small, is "fully" understood by its authors, because to do so, one would have to understand every implementation nuance and bug of OS layers, libraries used, other parts it interacts with, ... And even for less strict definitions of "fully" - for any program that took longer than say 2 weeks to write, how can anyone claim they really know the details of everything, at the same time? Including the nuanced differences between various of OS calls, and the effect some environment variable might have on your localization code, just to name one thing?

deleted 12y ago

[deleted]

keeperofdakeys 12y ago

Think of the times when you're using an unfamiliar api, and your browser tabs are split between documentation and stackoverflow posts. Eventually, you get something to work. If you just clean your hands, and say "I'm done", you've fallen into the trap that the article talks about. You might look at the code occasionally, and think "maybe I can clean this up?". However ,after a few minutes, you realise how much you don't understand what's going on. So you leave the code, in a sort of superstition - it works after all. After a few years, when you need to finally modify the code, you've got a problem. The code works, but you never took the time to understand why it works. If there were any superfluous calls, or side-effects that you don't want now, you'll need to take the time to understand how it all works. If you took the time to understand it originally, and wrote a few informative comments, you might have saved yourself hours of work. It must be said though, occasionally you do need to go deeper with your thinking. To figure out why some bug is occuring, or maybe some complex performance issue. So it is important to have some knowledge of how it all fits together, even if you don't need it all the time.