raganwald
(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Thursday, April 19, 2007
  Pop culture lives in the present, it doesn't really live in the future or want to know about great ideas from the past


In the last few years I’ve been asking computer scientists and programmers whether they’ve ever typed E-N-G-E-L-B-A-R-T into Google—and none of them have. I don’t think you could find a physicist who has not gone back and tried to find out what Newton actually did. It’s unimaginable. Yet the computing profession acts as if there isn’t anything to learn from the past, so most people haven’t gone back and referenced what Engelbart thought.

The things that are wrong with the Web today are due to this lack of curiosity in the computing profession. And it’s very characteristic of a pop culture. Pop culture lives in the present; it doesn’t really live in the future or want to know about great ideas from the past.

I’m saying there’s a lot of useful knowledge and wisdom out there for anybody who is curious, and who takes the time to do something other than just executing on some current plan. Cicero said, “Who knows only his own generation remains always a child.” People who live in the present often wind up exploiting the present to an extent that it starts removing the possibility of having a future.

—Alan Kay: The PC Must Be Revamped—Now, via discuss.joelonsoftware.com.

What other treasure troves of useful knowledge and wisdom are out there? Please post suggestions in the comments! (By the way, you can embed HTML anchors in comments, so don’t be shy about including links).
 

Comments on “Pop culture lives in the present, it doesn't really live in the future or want to know about great ideas from the past:
I've inflicted Dijkstra's archive on my local reading group on more than one occasion. EDW1304 always sums it up for me -- "How not to make a mess of it" is still the central problem we face. Engineering can wait.

Michael
 
for what it's worth, i've read a lot of engelbart's writing and know other programmers who have as well.

an oft stated accompaniment to him is vannevar bush (see memex, 'as we may think') and (recently re-popularised on programming.reddit) J.C.R Licklider

lb (secretGeek.net)
 
you know melvil dewey is worth reading about too. in the same way that they say ada lovelace was a programmer before programming -- melvil dewey was a dba before db's.

grace hopper is worth your time. too.

lb
 
I wrote a little bit about this as well. It's a little disconcerting talking to some truly brilliant programmers -- who have to be reminded who Alan Kay is!
 
I just finished reading the lessons learned by Fred Brooks in the 1960s.

Anything I do in the future regarding software will pass through that filter.
 
I'll second Brooks. I recently started reading the MMM again, and it could have been written yesterday.

David Parnas is also a great resource:

On The Criteria To Be Used in Decomposing Systems into Modules
http://www.acm.org/classics/may96/
http://en.wikipedia.org/wiki/David_Parnas
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /