We Are Abstracting on the Shoulders of Giants(hanselman.com)
hanselman.com
We Are Abstracting on the Shoulders of Giants
http://www.hanselman.com/blog/WeAreAbstractingOnTheShouldersOfGiants.aspx
4 comments
I love this. Great point. The dependency chain is huge.
> I generally understand the full stack from assembler all the way up to managed code and beyond to the cloud.
Please let this be the new definition of 'full stack developer'. I cannot stand the current definition.
Please let this be the new definition of 'full stack developer'. I cannot stand the current definition.
Let me get this clear in my head - you want "Full Stack Developer" to be someone well versed in everything that is happening from the assembly running on your machine to the browser, to the network stack and routers, down to the server, and back down to the assembly running on that server?
It would be a good interview question; it would filter out a lot of bullshit because, frankly, anybody who says they understand that for all permutations of those components is a liar.
There are very few people who would be able to even give you a 10,000 foot view of all the components that make up the delivery of a web page from end to end, let alone truly understanding all of them.
To borrow from the article - there's too many abstractions.
It would be a good interview question; it would filter out a lot of bullshit because, frankly, anybody who says they understand that for all permutations of those components is a liar.
There are very few people who would be able to even give you a 10,000 foot view of all the components that make up the delivery of a web page from end to end, let alone truly understanding all of them.
To borrow from the article - there's too many abstractions.
No, not really. Even Hanselman does not say he's well versed. It's a general understanding. I wouldn't expect a full stack developer to be able to whip out a GUI app using nothing but assembly during an interview, but I would expect them to understand that missed branch predictions thrash the instruction cache, what object files are and how a linker works, what a normalized database schema looks like, basic ipv4 networking etc. These are all wide swathes of knowledge. If someone claims they are 'full stack', what stack are they talking about? Serving web pages? If that's all it is, wouldn't 'web developer' suffice?
"The full stack developer brings the SaaS cloud to you with webscale!"
It even sounds like marketing garbage.
"The full stack developer brings the SaaS cloud to you with webscale!"
It even sounds like marketing garbage.
All that abstraction has a cost. Additional compute time (and energy) to work through the abstraction layers. Having to debug someone else's code when it doesn't "just work". Having to re-write the abstraction layer when your work no longer fit within the defined parameters of the abstraction.
Frequently, the benefits of developer productivity outweigh these costs, but when an abstraction falls apart, it has a tendency of doing so spectacularly.
I tend to think of abstractions like those mentioned in the article as land mines full of technical debt. At first, it's easy to avoid stepping on them. But eventually you will step on that landline (perhaps even intentionally), and when it does, your productivity is going to suffer severely.
The analogy fits in one other way: the cost of clearing those abstraction land mines is disproportionate to the cost of putting them in your code in the first place.
Frequently, the benefits of developer productivity outweigh these costs, but when an abstraction falls apart, it has a tendency of doing so spectacularly.
I tend to think of abstractions like those mentioned in the article as land mines full of technical debt. At first, it's easy to avoid stepping on them. But eventually you will step on that landline (perhaps even intentionally), and when it does, your productivity is going to suffer severely.
The analogy fits in one other way: the cost of clearing those abstraction land mines is disproportionate to the cost of putting them in your code in the first place.
How is having to re-write the abstraction layer a "cost of abstraction"? That is work that you would have had to do anyway.
I think the "land mine" metaphor is unnecessarily disparaging. Abstractions are more like roads. They make life easier, as long as you can stay on them. But if you have to go off the road, you're going to have to make a road for yourself.
Generally speaking, roads only reduce the amount of work you have to do to travel, unless you use them inappropriately (like going too far out of your way when you could have taken a shortcut). On the other hand, land mines only increase the difficulty of traveling.
I think the "land mine" metaphor is unnecessarily disparaging. Abstractions are more like roads. They make life easier, as long as you can stay on them. But if you have to go off the road, you're going to have to make a road for yourself.
Generally speaking, roads only reduce the amount of work you have to do to travel, unless you use them inappropriately (like going too far out of your way when you could have taken a shortcut). On the other hand, land mines only increase the difficulty of traveling.
> How is having to re-write the abstraction layer a "cost of abstraction"?
Because in my experience, it's never as clean cut as "this abstraction doesn't work, lets go re-write it". The process typically goes more like:
* Identify that there's a problem, start trying to understand the code in the abstraction in order to identify the problem.
* Fork the abstraction code and make changes to it.
* Attempt to push changes upstream because "if I have the problem, other people have the problem as well", plus all the work that comes with pushing changes upstream.
* Repeat the previous three steps for a period of time ranging from months to years
* Find another implementation of the abstraction and repeat the previous four steps again.
* Finally give up and then re-write the whole abstraction in a way which actually works for your needs.
Land mines are also a leaky abstraction of the facilitation of forward movement as you have pointed out, but I have a hard time getting the "technical debt explosion in potentia" out of my mind.
Because in my experience, it's never as clean cut as "this abstraction doesn't work, lets go re-write it". The process typically goes more like:
* Identify that there's a problem, start trying to understand the code in the abstraction in order to identify the problem.
* Fork the abstraction code and make changes to it.
* Attempt to push changes upstream because "if I have the problem, other people have the problem as well", plus all the work that comes with pushing changes upstream.
* Repeat the previous three steps for a period of time ranging from months to years
* Find another implementation of the abstraction and repeat the previous four steps again.
* Finally give up and then re-write the whole abstraction in a way which actually works for your needs.
Land mines are also a leaky abstraction of the facilitation of forward movement as you have pointed out, but I have a hard time getting the "technical debt explosion in potentia" out of my mind.
[deleted]
Let me guess, you like C++? :)
When writing a LGPL licensed CMS server, I tried to find all sub-projects to make sure we could distribute the software safely. Sadly, not every framework and plugin does list its own dependencies correctly - often you will find components in the lib/ folder that require specific attribution with the author's name if the software is to be used legally.
http://cinnamon-cms.com/de/cinnamon-server/lizenz-ubersicht
And for a list of Giants and Dwarves:
http://cinnamon-cms.com/de/standard/riesen-und-zwerge
edit: clarification / fix typo