6 ms·

Joel Spolsky wrote an essay on "leaky abstractions," and from reading the interview with the Etsy CTO, the two seem related. Allspaw is making the distinction b

Joel Spolsky wrote an essay on "leaky abstractions," and from reading the interview with the Etsy CTO, the two seem related. Allspaw is making the distinction between engineers and developers this way. To him, an engineer is willing and able to get under the hood, if necessary; whereas a developer is limited to using libraries and frameworks as-is, and filing bug reports on them when things don't go as planned, or feature requests if he bumps up against some limitation. I think that's what he means when he characterizes the non-engineer as having a "not my job" mentality.

rqebmm 11y ago
Oh man, the Law of Leaky Abstractions is an amazing read, and an incredibly useful general theory. It's so applicable that I've taught my non-technical friends and family as it related to university structures, the insurance industry, management, technical support, etc. http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
cannam 11y ago
As someone who likes to "get under the hood", I'm used to grumbling about developers these days who just glue together existing frameworks. But the real cause of my dissatisfaction is that I find it harder to glue together existing frameworks -- I don't know where to begin, until I've dug in a bit to find out how something works underneath. Meanwhile other people whose approaches I think of as simplistic are able to leap in and get things done more quickly than I can. (Similarly I find it almost impossible to learn much of a foreign language without studying the grammar, while some other people can immerse themselves and become quite conversant without ever thinking about grammar.) Maybe the "non-engineer" developers are just working at a higher, and more immediately useful, level of interpretation.
- bphogan 11y ago
  I think that's part of it. I'm the kind of person you'd find frustrating at first. I don't want to know all the internals of what I'm doing before I dive in. I want a nice API and good docs, and I want to build some stuff right away. And if I can't do that, I give up and move on to something else. If I like it, and it gives me quick wins, then I'll dive into the guts of how it works. Because I'm a responsible developer. But I have learned that with all the things out there to learn and absorb, I don't have time to deep-dive a framework before choosing to use it. There's something else coming that I have to do next week that uses something I don't know. So the more I build stuff, the faster I get at picking it up.
Glyptodon 11y ago
I've always felt that in the various jobs I've held the degree to which I could "get under the hood" was determined by people higher up the chain of command than me. Run into a complex bug in library X? Well, we don't want you spending a week to debug it, write a patch and try to upstream it. Work around it for now instead. Or we'll defer that feature since we don't want you to spend that much time on "non-company" projects. Etc. I think this is usually all the more true when your employer expects you to be a generalist of some kind and I've become a bit jealous of people whose employers let them really dig into things and even deviate to ecosystem projects instead of focusing on keeping the internal hamster wheel spinning. On another tangent, one thing I found very frustrating early in my career and which I still feel is problematic in our field is that there's kind of a double standard when it comes to approaching things "under the hood." At my first job I'd always ask my supervisor when when things lead there and then get told not to go there (despite wanting to) while a coworker of similar experience hired at around the same time would constantly get everything done behind schedule because he just did the things under the hood I made the mistake of asking about, but he'd get applauded for it continually. (Perhaps I learned from this, but it was pretty frustrating and disheartening at the time.)
- strickjb9 11y ago
  I can relate to your last paragraph. I used to (and still) source dive to find good workarounds to library issues. But I never asked for permission, I just did it. I also delivered on time. Nowadays, I'm a team lead and I am guilty of telling people "not to go there" (about half the time). It's funny because it actually conflicts with my opinion that I want people to dig in! The choice to "dig in" is a personal risk/reward. It's a risk that an engineer must take while practicing good time management. Asking your manager is akin to making them take that risk for you (the risk of wasted time, passing deadlines, etc). My crappy advice is... ask for forgiveness, not for permission. If you're a good engineer, you'll come out on top!
  - Glyptodon 11y ago
    I don't disagree with you, but I also think there are situations where (particularly if you aren't privy to the big picture) it's a good idea to have some kind of sounding board to run things off of before diving/jumping in, though that may be a bit tangential to the point at hand. Maybe more to the point, I don't think my behavior at the time was an attempt at pushing the risk up the chain as much as it was a manifestation of fear/anxiety that I'd somehow be outside of company expectations/norms or would end up spending a bunch of time working around/fixing something that had already been solved in a way that I, as a newer employee, just didn't know about.
nogbit 11y ago
I agree, and it gets worse every year "The Law of Leaky Abstractions is dragging us down." - Joel Spolsky (2002)

rqebmm 11y ago

Oh man, the Law of Leaky Abstractions is an amazing read, and an incredibly useful general theory. It's so applicable that I've taught my non-technical friends and family as it related to university structures, the insurance industry, management, technical support, etc. http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...

cannam 11y ago

As someone who likes to "get under the hood", I'm used to grumbling about developers these days who just glue together existing frameworks. But the real cause of my dissatisfaction is that I find it harder to glue together existing frameworks -- I don't know where to begin, until I've dug in a bit to find out how something works underneath. Meanwhile other people whose approaches I think of as simplistic are able to leap in and get things done more quickly than I can. (Similarly I find it almost impossible to learn much of a foreign language without studying the grammar, while some other people can immerse themselves and become quite conversant without ever thinking about grammar.) Maybe the "non-engineer" developers are just working at a higher, and more immediately useful, level of interpretation.

bphogan 11y ago
I think that's part of it. I'm the kind of person you'd find frustrating at first. I don't want to know all the internals of what I'm doing before I dive in. I want a nice API and good docs, and I want to build some stuff right away. And if I can't do that, I give up and move on to something else. If I like it, and it gives me quick wins, then I'll dive into the guts of how it works. Because I'm a responsible developer. But I have learned that with all the things out there to learn and absorb, I don't have time to deep-dive a framework before choosing to use it. There's something else coming that I have to do next week that uses something I don't know. So the more I build stuff, the faster I get at picking it up.

Glyptodon 11y ago

I've always felt that in the various jobs I've held the degree to which I could "get under the hood" was determined by people higher up the chain of command than me. Run into a complex bug in library X? Well, we don't want you spending a week to debug it, write a patch and try to upstream it. Work around it for now instead. Or we'll defer that feature since we don't want you to spend that much time on "non-company" projects. Etc. I think this is usually all the more true when your employer expects you to be a generalist of some kind and I've become a bit jealous of people whose employers let them really dig into things and even deviate to ecosystem projects instead of focusing on keeping the internal hamster wheel spinning. On another tangent, one thing I found very frustrating early in my career and which I still feel is problematic in our field is that there's kind of a double standard when it comes to approaching things "under the hood." At my first job I'd always ask my supervisor when when things lead there and then get told not to go there (despite wanting to) while a coworker of similar experience hired at around the same time would constantly get everything done behind schedule because he just did the things under the hood I made the mistake of asking about, but he'd get applauded for it continually. (Perhaps I learned from this, but it was pretty frustrating and disheartening at the time.)

strickjb9 11y ago
I can relate to your last paragraph. I used to (and still) source dive to find good workarounds to library issues. But I never asked for permission, I just did it. I also delivered on time. Nowadays, I'm a team lead and I am guilty of telling people "not to go there" (about half the time). It's funny because it actually conflicts with my opinion that I want people to dig in! The choice to "dig in" is a personal risk/reward. It's a risk that an engineer must take while practicing good time management. Asking your manager is akin to making them take that risk for you (the risk of wasted time, passing deadlines, etc). My crappy advice is... ask for forgiveness, not for permission. If you're a good engineer, you'll come out on top!
- Glyptodon 11y ago
  I don't disagree with you, but I also think there are situations where (particularly if you aren't privy to the big picture) it's a good idea to have some kind of sounding board to run things off of before diving/jumping in, though that may be a bit tangential to the point at hand. Maybe more to the point, I don't think my behavior at the time was an attempt at pushing the risk up the chain as much as it was a manifestation of fear/anxiety that I'd somehow be outside of company expectations/norms or would end up spending a bunch of time working around/fixing something that had already been solved in a way that I, as a newer employee, just didn't know about.

nogbit 11y ago

I agree, and it gets worse every year "The Law of Leaky Abstractions is dragging us down." - Joel Spolsky (2002)