why you should respect Technology
There are two kinds of people in the world. Producers of technology, and consumers of technology.
In a perfect world, consumers of technology shouldn’t have to care about it. The technology should serve its users. I don’t want to have to care about my toasted sandwich maker, and I shouldn’t. Toasted sandwich makers should be designed so I can consider them trivial and beneath my need to understand.
Of course, it’s not a perfect world. I have to know something about my toasted sandwich maker, like not to immerse it in water, especially when it’s plugged in. The ideal, however remains that I should need to know as little as possible. It’s use should be simple, efficient and intuitive. It should just work.
In order for this to happen, though, I expect the people who design toasted sandwich makers for a living to know a hell of a lot about them. This is fundamentally necessary. If it were made by some guy who’d read a pamphlet one evening about how to build an electrical appliance, it’d be just as likely to blow up in my face as do anything useful.
People who produce technology should respect technology.
Respect means taking the time to understand it.
I think sometimes, computer programmers lose track of this fact.
To use a term that, thankfully, seems to have gone out of its short fashion, we are in the business of providing ‘solutions’. In order to solve somebody’s problem, we must not only understand the problem, we must also have a good knowledge of the possible solutions, and the prior art that has gone into solving that sort of problem in the past. And where we do not have that knowledge (Hell, I’ve only been a professional programmer for five years, the gaps in my knowledge are staggering), we must recognise our lack, and either work to fill it, or seek the advice of those who know more.
It astounds me, for example, how many people try to write web applications without knowing much HTTP. I don’t see how it’s possible. Sure, we have a bunch of abstractions that sit on top of our HTTP servers, but we all know that abstractions leak, and when they start leaking, you’re lost if you don’t understand the plumbing beneath them. A designer of applications that are transported over HTTP should have an intimate knowledge of HTTP, and probably a pretty good idea how TCP/IP works, for good measure.
What scares me even more is people who try to simplify, or abstract away some protocol or technology without first demonstrating an understanding of what they’re trying to simplify. If you don’t really understand all that is there, you’re certainly not qualified to throw any of it away.
Otherwise, how do you know your toaster isn’t going to blow up?