4 ms·

I know a few good developers that don't even know how a computer works. Everything is so abstracted you never really have to know.

toomuchtodo 11y ago
As a devops/infrastructure guy, this drives me nuts. You abstract everything away, but then are shocked when you don't understand what's happening when the underlying layers fail or break down in unexpected places ways.
- api 11y ago
  It's rapidly becoming a two tier world with two types of programmers: those who are well trained in coding within known environments, and those who are like the folks in The Matrix films who ate the red pill-- they know what's really going on.
  - jpatokal 11y ago
    It's been like that for decades. Or do you really know what assembler your program compiles down to?
    - djcapelis 11y ago
      For some of them, absolutely. I change the assembly output and reassemble to verify that the atomics are necessary and fixing the cases I think they do. As far as I'm concerned, if you're not removing the atomic instructions to make sure the breaks happen that you expect to happen, you're not really testing your code.
  - joezydeco 11y ago
    I'm an embedded systems engineer. It's always been that way for me: I own and compile the bootloader, kernel, filesystem, runtime libraries, and the application code. I have the schematics and gerbers for my boards. I have the reference manuals for every chip. What's weird is watching people play with stuff like Raspberry Pi and they expect things to just apt-get and launch like it's always been done for them. And most of the time it does just work that way. Except when it doesn't.
    - louithethrid 11y ago
      many development enviroments would do good with some graphics representation of how much of the plattforms capabilitys is actually used up during a test run, how cache friendly the code is, and how much your latest changes affected this. And this coloured columns need to show in every svn/git commit message. Profiling needs to be not something that the embeded guy does after you messed it up. Jerry Commited: +25% more time spend in function xy, due to chace unfriendlyness.. If you see it, and your colleagues see it, it becomes a issue. If it becomes a issue the perpetrator will look into it.
- Drdrdrq 11y ago
  I understand your frustration, but the field has become too big for a single (average) person. When problems arise , you team up with someone who knows more about the issue or you learn on the spot. Nothing wrong with not knowing everything.
  - toomuchtodo 11y ago
    That's not my problem. My problem is the illusion presented that you don't need to understand the underlying infrastructure. Far too often I see infrastructure as an afterthought, secondary to the code.
    - deleted 11y ago
      [deleted]
    - voltagex_ 11y ago
      What kind of organisations have you worked in? I've been lucky (?) to work in an organisation with a dedicated network/infrastructure team. My work life got a lot better when I gained more understanding of how the network was put together (vis-a-vis load balancers, DNS, data center locations etc). I still don't have a "low level" understanding of the network I use.
      - toomuchtodo 11y ago
        I've always managed or been on infrastructure teams at other orgs; my latest gig is at a startup, and I'm the only infrastructure guy. Perhaps that is the problem.
        voltagex_ 11y ago
        Good chance to educate others? I know I'll be looking for an opportunity to work with an infrastructure guru at some stage in the future.
        toomuchtodo 11y ago
devnonymous 11y ago
You don't really have to know the internals but I personally think you ought to know the abstactions themselves at the very least. To be more specific, you need not know say the internals of your compiler but you ought to know how compilers in general work. Same with protocols, filesystems, OS {vm,scheduler} ...etc.
sklogic 11y ago
A good developer must know at least about the standard latencies and about the memory hierarchy. Otherwise it is a really bad developer who is going to keep annoying the innocent users.

toomuchtodo 11y ago

As a devops/infrastructure guy, this drives me nuts. You abstract everything away, but then are shocked when you don't understand what's happening when the underlying layers fail or break down in unexpected places ways.

api 11y ago
It's rapidly becoming a two tier world with two types of programmers: those who are well trained in coding within known environments, and those who are like the folks in The Matrix films who ate the red pill-- they know what's really going on.
- jpatokal 11y ago
  It's been like that for decades. Or do you really know what assembler your program compiles down to?
  - djcapelis 11y ago
    For some of them, absolutely. I change the assembly output and reassemble to verify that the atomics are necessary and fixing the cases I think they do. As far as I'm concerned, if you're not removing the atomic instructions to make sure the breaks happen that you expect to happen, you're not really testing your code.
- joezydeco 11y ago
  I'm an embedded systems engineer. It's always been that way for me: I own and compile the bootloader, kernel, filesystem, runtime libraries, and the application code. I have the schematics and gerbers for my boards. I have the reference manuals for every chip. What's weird is watching people play with stuff like Raspberry Pi and they expect things to just apt-get and launch like it's always been done for them. And most of the time it does just work that way. Except when it doesn't.
  - louithethrid 11y ago
    many development enviroments would do good with some graphics representation of how much of the plattforms capabilitys is actually used up during a test run, how cache friendly the code is, and how much your latest changes affected this. And this coloured columns need to show in every svn/git commit message. Profiling needs to be not something that the embeded guy does after you messed it up. Jerry Commited: +25% more time spend in function xy, due to chace unfriendlyness.. If you see it, and your colleagues see it, it becomes a issue. If it becomes a issue the perpetrator will look into it.
Drdrdrq 11y ago
I understand your frustration, but the field has become too big for a single (average) person. When problems arise , you team up with someone who knows more about the issue or you learn on the spot. Nothing wrong with not knowing everything.
- toomuchtodo 11y ago
  That's not my problem. My problem is the illusion presented that you don't need to understand the underlying infrastructure. Far too often I see infrastructure as an afterthought, secondary to the code.
  - deleted 11y ago
    [deleted]
  - voltagex_ 11y ago
    What kind of organisations have you worked in? I've been lucky (?) to work in an organisation with a dedicated network/infrastructure team. My work life got a lot better when I gained more understanding of how the network was put together (vis-a-vis load balancers, DNS, data center locations etc). I still don't have a "low level" understanding of the network I use.
    - toomuchtodo 11y ago
      I've always managed or been on infrastructure teams at other orgs; my latest gig is at a startup, and I'm the only infrastructure guy. Perhaps that is the problem.
      - voltagex_ 11y ago
        Good chance to educate others? I know I'll be looking for an opportunity to work with an infrastructure guru at some stage in the future.
        toomuchtodo 11y ago

devnonymous 11y ago

You don't really have to know the internals but I personally think you ought to know the abstactions themselves at the very least. To be more specific, you need not know say the internals of your compiler but you ought to know how compilers in general work. Same with protocols, filesystems, OS {vm,scheduler} ...etc.

sklogic 11y ago

A good developer must know at least about the standard latencies and about the memory hierarchy. Otherwise it is a really bad developer who is going to keep annoying the innocent users.