raganwald
Monday, April 24, 2006
  Why do we resist the idea that programming might be hard?
Don’t blame me for the fact that competent programming, as I view it as an intellectual possibility, will be too difficult for ‘the average programmer’, you must not fall into the trap of rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner.
Edsger Dijkstra
Programming something even half decent requires considerable intellectual ability. That’s not all there is to it, but if you’re not smart, it will be much harder for you to be a decent programmer. We’re mostly in denial about this and would like to believe that programming can be done by anyone or can be made somehow unnecessary. It’s the opposite view we take to managerial or executive ability, where we pay through the node for talent. Yet it’s been known since we started building software that some programmers are much better than others. Maybe all disciplines are like this, but it is very obvious in programming. Naturally this intelligence makes people who don't have it uncomfortable, particularly if that person is supposed to lead or organize very smart people to do something that they don't fully understand, even though that person is probably better paid, more socially equipped and has nothing to worry about.

As with meat-markets this is not something we like to talk about a lot. It’s not egalitarian and intelligence is something we’re sensitive about culturally. But consider that it’s not controversial to say being a good musician or athlete requires a level of ability, some of which is innate. Or that our educational systems are based around being ranked smarter than the next person anyway. So we should get over ourselves a bit and accept the fact the good software requires more than stringent process; it requires well-above average intelligence to create it.
Bill de hÓra

The statements that make people mad are the ones they worry might be believed. I suspect the statements that make people maddest are those they worry might be true.
—Paul Graham, What You Can't Say

Addendum:

I have recieved a few emails and comments suggesting that anyone can become a good programmer with sweat and dedication. Here're my personal feelings:

I don't believe that anyone can become a good programmer with dedication, practice, and experience. In case you haven't guessed from the third quote above, my interest is not in whether there is an innate talent involved with programming, but in people's state of denial.

Let's look at what it means to improve and to be good.

I suppose there's some room for argument about whether almost any infant or toddler, if exposed to the right stimuli, can become a good programmer. Our knowledge of genetics and early brain development is primitive.

However, by the time people reach their teen years, I believe that much of their potential has been established.

With dedication and practice, people can improve almost anything, however in most fields this improvement shows diminishing returns. It may be aymptotic, so in theory they may eventually become a good programmer or a chess master, but in practice this may take longer than the number of productive years available.

With respect to everyone who has emailed to say that anyone can be a great programmer, how many of you play Bridge or Chess? These are fields where no serious practitioner believes that round the clock study and fanatic devotion will take you to the top: winning requires both potential and the will to fulfill that potential.

Likewise, how many of you who write or email play a musical instrument and especially compose music? Many people have fanatic devotion to practice, yet every generation yields remarkably few geniuses that will stand the test of time.

Why do people consider fields like Bridge, Chess, Athletics, and Music different from programming?

I think the salient distinction is that we habitually consider games like Bridge, Chess and Athletics very competetive. And if you're paying close attention, we consider Classical Music and Jazz equally competitive, if not more so (where do you think we got the word "Diva"?).

When something is competitive, it's irrelevant how good you can become through practice. If someone else can become even better with the same amount of practice, you will be unable to surpass them.

Of course, you can still surpass those that don't study, practice, or learn from their mistakes. That's important. But if the field is desirable enough that there are a significant number of innately talented people willing to study, practice, and learn, then only those with innate talent will occupy the top spots.

I believe that if programming jobs were more demanding and that if the industry were more competitive, we would rapidly lose all pretensions to egalitarianism.

But what do I know?

If you found this interesting, you may want to read How to make programming hard for yourself.

Labels: ,

 

Thursday, April 20, 2006
  Events April 24th-26th in Toronto
Two absolute musts:

Toronto Democamp 5: Tuesday April 25th, 6:30 PM BA 1180, Bahen Centre for Information Technology, 40 St. George St. Toronto, ON. This is a fabulous opportunity to see what's going on in the start up community and share your work. No power points and other great rules for sticking to the point.

Avi Bryant is giving two presentations at the Smalltalk Solutions Conference April 24th-26th. He'll be talking about Using AJAX from Seaside and Thinking Small: Bootstrapping a Web Startup with Smalltalk. Recommended.

(If I can, I'll lure Avi into presenting at Democamp!)
 

Reg Braithwaite


Nota Bene
A Brief History of Dangerous Ideas

Share
rewrite.rubyforge.org / ick.rubyforge.org / andand.rubyforge.org / 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

Buy Raganwald a Coffee
If you enjoy reading my weblog, please consider buying me a Darkhorse Double Espresso, for just $3.15 Thank you!

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 /