You just pressed a key on your keyboad.<p>Simple, isn't it?<p>What just actually happened?<p>You engaged a cascade of motor neurons to coordinate the contraction of thousands of muscle cells, which pulls a lever attached to your calcium crystalline framework, grinds across a glucosamine joint. This forces your calcium crystalline frame-member to depress, compressing your saline-filled lipid-polymer foam skin against the keyboard. As you do this, you constantly measure the pressure against the lipid-polymer walls to ensure you are not deforming your muscle cells too much or too little.<p>---<p>Reality has inordinate complexity. When humans build roads or build narratives or build websites, we are simplifying reality for ourselves and others, including other animals.
When I got to the last paragraph or two, I realized this was not just a "computers are complicated" post. He marks a specific <i>social</i> problem the complexity of the technology has created.<p>This is the best way to frame the "tech laws problem" I've seen in a long time. I'm curious: what is the best way to approach the bikeshedding issue?<p>On the one hand, the people who recognize the issue tend to be technical. On the other, the solution will inevitably be a social one, unless something comes along that makes patents and technological laws moot.<p>Here are three social avenues I could see being helpful, but none of them seems to solve the problem. I'd love to know what people are doing in this area.<p>a) Improve technical education for the general public so that they can call BS, or make reasonable decisions.<p>b) Improve technical education of public servants that make crucial decisions regarding technology. I'm not competent to rule in a legal case about pollution, so why should we assume judges are competent to rule in a legal case about code? (How do you measure that? Certifications? - egh).<p>c) Improve social outreach for technical people. Most technical people probably want to build cool things instead of sit in Congress, knock on doors, or otherwise get involved. I've talked with engineers who despise legal proceedings so much they started trolling the lawyers in depositions. Honestly I'd rather build something cool than think for five hours about how to get people to care about patent law. Maybe that should change.<p>I'd love feedback on this, because the bikeshedding issue is the scariest social problem I can't think of a solution to. It doesn't just affect a specific patent, it affects the way we rule on them in general.<p>If you are both a lawyer and technical, I would really love your feedback, here, or via email.
Wow, it's easy to forget how much complexity there is, even for a technologist. This post reminds me to step back and appreciate everything that's going on under the hood. For a similar effect on non-technologists, see Louis C.K's bit about how even the shittiest technologies are a miracle[1].<p>I disagree with the conclusion though. I think the reason Steve Jobs' death impacted people more than Dennis Ritchie's is that Jobs was taken in his prime. Who knows what the world lost by his premature death.<p>1: <a href="http://www.youtube.com/watch?v=KpUNA2nutbk" rel="nofollow">http://www.youtube.com/watch?v=KpUNA2nutbk</a>
Beautiful. One thing though, I believe the OP is mistaken when he implies that Steve Jobs didn't affect how computers work on the inside:<p>"On the one hand, I can imagine where the computing world would be without the work that Jobs did and the people he inspired: probably a bit less shiny, a bit more beige, a bit more square. Deep inside, though, our devices would still work the same way and do the same things."<p>Ultimately, computer architectures serve real world use cases. Innovation in use cases results in innovation in architectures. There are countless new technologies that exist because of the products that Apple invented.
To add some cynical flavor: when you went to the Google homepage, you expended electricity, CPU cycles, network traffic, gave up some privacy and waited some time just to see something that could have been shown to you by a static HTML file(²) on your disk (or even something built in the browser), because some corporation sees some benefit in all this extra work. We're not exactly trying to do things efficiently these days, since it's no longer a priority.<p>(²) not valid for search results of course, but even they could be sent to you in a more efficient, less privacy-destroying way if only some corporation's interests weren't more important than your own
The best bottom up approach to this that I have seen is Charles Petzold's "Code: The Hidden Language of Computer Hardware and Software" [1] which starts with using a flashlight to send messages and walks up the abstraction chain (switch, relay, alu, memory, cpu...) to most of the components of a modern computer. It's very accessible.<p>[1] <a href="http://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319" rel="nofollow">http://www.amazon.com/Code-Language-Computer-Hardware-Softwa...</a>
What's even more cool?<p>Before long computers will be able to conceptualize the whole complex mess.<p>Consider how we acquire knowledge (perhaps like <a href="http://matt.might.net/articles/phd-school-in-pictures/" rel="nofollow">http://matt.might.net/articles/phd-school-in-pictures/</a>). The more we've learned, the more we need to know about how to learn. At each level of knowledge we gain knowledge by accessing new knowledge and combining it with what we know. Eventually the supply of new knowledge dwindles and the only tool we can rely on is learning; the only tool we can rely on is that ability to combine knowledge.<p>This is much harder than taking in new knowledge; especially for computers! However, computers are getting better and better at it. Whereas many of us are out of college, computers are still in middle school, but they're getting better and better at both large scale and high complexity learning, so they'll move on to high school and college soon. Moreover, they're moving at an exponential pace! (see Ray Kruzwell and his ideas on the exponential growth of technology) Eventually, no... soon, computers will be able to conceptualize and intuit the scale and complexity of something like google.com. No person can come close to this, so we have no idea what that ability will bring.
So I like how he ends with that bit on patents, when I did my presentation at the USPTO Silicon Valley roundtable event a month ago, a couple of the presenters made the case that absolutely nothing needs to change with software patents because computers should be treated the same as any other kind of machine, and so software should be considered the same as every other type of patent. The fact of the matter is this is simply not true, computer software cannot be equated to physical items, and barely equate to business flow and methods. With all the complexities, as well as the fact that to try out a new version of software happens in seconds where making a prototype of some machine or object takes days, weeks or months. It seemed they either didn't fully understand the difference, or they understand and do not want the system to change since it works greatly in their favor.<p>Anyone who has an opinion on patents, especially software patents, should be keeping up with the roundtable events. And, I'm not saying that because I went either, stuff is being talked about at these events that will either be ignored or shape the patent system in one way or another. In either case, it's in our best interest to stay involved in the process.<p>Edit: Spelling
From another perspective this is a modern view of the classic "I, Pencil" - which Friedman gave an great overview of:<p><a href="http://www.youtube.com/watch?v=OlTRau_XgGs" rel="nofollow">http://www.youtube.com/watch?v=OlTRau_XgGs</a>
It's a scary thought that if all the computers in the world were destroyed in an instant, how long would it take for us to build a Core i7 processor. Decades?
Brilliant stuff that I have been looking for quite some time. I work in support and sometimes I really want to show this to our users, yet I would love to see something more human like:
Jennie from Sales Support just used word merge to print a letter.
Simple, isn't it?
What just actually happened?
The letter will go to post box, were postman will take it sorting center, where it will be distributed and sent to customer, who will read the letter, discuss it with the family and take number of steps to take a decision how to proceed further.<p>Or a guy from sales just received a call, but what just happened? The client was recommended by a friend after a splendid experience with the product, the client spent bunch of time reading number of sites and reviews and he is just about to purchase a product when sales guy's computer has crashed and he lost a client.
We always try to make people understand the IT more and the other guys will try to makes understand their processes more, yet it is going to be never ending dialogue, process, fight..
I've previously used this as an interview pre-screen question for job candidates. It's a great question to ask; there are so many levels of details involved.<p>As a web company, you generally want potential employees to at least mention "HTTP" in the response. DNS is great. TCP/IP too. You'll definitely weed out some people who don't have a clue.
This question is one of my favourites when interviewing front/back-end developers and sysadmins. It gives candidates the chance to talk about the part of the stack they find interesting, so I can see what they are most knowledgeable/passionate about as well as judging their overall level of background knowledge.
What if I don't use docsis?
:P<p>also, we quite understand how chips are automatically organized by other chips. it's because we don't understand it that computers are "building" computers. its because they're way faster at those repetitive tasks (and yes i'm talking about automatic chip layouts, for example)<p>Even thus it's not exactly TFA's point, since TFA goes pages and pages on complexity for pointing out that people care about what they see, not what it really does, I though that's worth mentioning.
My favorite one-sentence version of this, said by a comedian (whose name I forget): If you're left in the woods with nothing, how long before you can send an email?
I'm just glad I understand technology at least to some extent. I mean technology is often so complex I could never put together most of it myself or even understand it down to intricate detail, but at least I have a grasp of how it all fits together to make a pc, cpu, memory, television, radio, phone, remote control, ...<p>I can't imagine going trough this life without having the faintest idea of how a lot of the stuff I use everyday actually works.
The problem is not only with communication between end-users/management, it's also a problem with communication between teams -- for the same reason.<p>Because of the huge amount of complexity described, it becomes impossible for one developer -- or one group of developers working on the same project -- to understand at one time much more than their current specialization. This makes it hard to talk to peers working on other projects.
Great post. I wrote something similar a while back -
<a href="http://techcrunch.com/2012/06/16/the-way-things-work/" rel="nofollow">http://techcrunch.com/2012/06/16/the-way-things-work/</a><p>But he takes it to another level. There's a lot to be said on this, and education is super important, but ultimately one has to sort of ... surrender, at least to some degree.
I've long contemplated the depths of technological stacks (and knowledge as a whole, it pertains to epistemology as well), and my opinion is that knowing the intricacies of them isn't that important, as long as we manage to archive their fundamental principles somehow (may it be in our heads through studying and transmission, or in data).
Hypothetical question: if all the knowledge in the world was available to you, how long would it take to build a modern electronic device from raw materials and without using any existing machine in the build process? I mean the actual time spent building something, excluding any mental work.