Instapaper: Starred

Things You Should Never Do, Part I - Joel on Software

Wed, 09 May 2012 21:27:22 -0700

by Joel Spolsky

Thursday, April 06, 2000

Netscape 6.0 is finally going into its first public beta. There never was a version 5.0. The last major release, version 4.0, was released almost three years ago. Three years is an awfully long time in the Internet world. During this time, Netscape sat by, helplessly, as their market share plummeted.

It's a bit smarmy of me to criticize them for waiting so long between releases. They didn't do it on purpose, now, did they?

Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch.

Netscape wasn't the first company to make this mistake. Borland made the same mistake when they bought Arago and tried to make it into dBase for Windows, a doomed project that took so long that Microsoft Access ate their lunch, then they made it again in rewriting Quattro Pro from scratch and astonishing people with how few features it had. Microsoft almost made the same mistake, trying to rewrite Word for Windows from scratch in a doomed project called Pyramid which was shut down, thrown away, and swept under the rug. Lucky for Microsoft, they had never stopped working on the old code base, so they had something to ship, making it merely a financial disaster, not a strategic one.

We're programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by incremental renovation: tinkering, improving, planting flower beds.

There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

It’s harder to read code than to write it.

This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it's easier and more fun than figuring out how the old function works.

As a corollary of this axiom, you can ask almost any programmer today about the code they are working on. "It's a big hairy mess," they will tell you. "I'd like nothing better than to throw it out and start over."

Why is it a mess?

"Well," they say, "look at this function. It is two pages long! None of this stuff belongs in there! I don't know what half of these API calls are for."

Before Borland's new spreadsheet for Windows shipped, Philippe Kahn, the colorful founder of Borland, was quoted a lot in the press bragging about how Quattro Pro would be much better than Microsoft Excel, because it was written from scratch. All new source code! As if source code rusted.

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that's kind of gross if it's not made out of all new material?

Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.

You are putting yourself in an extremely dangerous position where you will be shipping an old version of the code for several years, completely unable to make any strategic changes or react to new features that the market demands, because you don't have shippable code. You might as well just close for business for the duration.

You are wasting an outlandish amount of money writing code that already exists.

Is there an alternative? The consensus seems to be that the old Netscape code base was really bad. Well, it might have been bad, but, you know what? It worked pretty darn well on an awful lot of real world computer systems.

When programmers say that their code is a holy mess (as they always do), there are three kinds of things that are wrong with it.

First, there are architectural problems. The code is not factored correctly. The networking code is popping up its own dialog boxes from the middle of nowhere; this should have been handled in the UI code. These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces. They can be done by one programmer working carefully and checking in his changes all at once, so that nobody else is disrupted. Even fairly major architectural changes can be done without throwing away the code. On the Juno project we spent several months rearchitecting at one point: just moving things around, cleaning them up, creating base classes that made sense, and creating sharp interfaces between the modules. But we did it carefully, with our existing code base, and we didn't introduce new bugs or throw away working code.

A second reason programmers think that their code is a mess is that it is inefficient. The rendering code in Netscape was rumored to be slow. But this only affects a small part of the project, which you can optimize or even rewrite. You don't have to rewrite the whole thing. When optimizing for speed, 1% of the work gets you 99% of the bang.

Third, the code may be doggone ugly. One project I worked on actually had a data type called a FuckedString. Another project had started out using the convention of starting member variables with an underscore, but later switched to the more standard "m_". So half the functions started with "_" and half with "m_", which looked ugly. Frankly, this is the kind of thing you solve in five minutes with a macro in Emacs, not by starting from scratch.

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version.

The old mantra build one to throw away is dangerous when applied to large scale commercial applications. If you are writing code experimentally, you may want to rip up the function you wrote last week when you think of a better algorithm. That's fine. You may want to refactor a class to make it easier to use. That's fine, too. But throwing away the whole program is a dangerous folly, and if Netscape actually had some adult supervision with software industry experience, they might not have shot themselves in the foot so badly.

Have you been wondering about Distributed Version Control? It has been a huge productivity boon for us, so I wrote Hg Init, a Mercurial tutorial—check it out!

Controlling Your Environment Makes You Happy

Want to know more?

You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.

About the author.

I’m Joel Spolsky, co-founder of Fog Creek Software, a New York company that proves that you can treat programmers well and still be highly profitable. Programmers get private offices, free lunch, and work 40 hours a week. Customers only pay for software if they’re delighted. We make FogBugz, enlightened project management software for bug tracking, Kiln, which provides distributed version control and code reviews, and Fog Creek Copilot, which makes remote desktop support easy. I’m also the co-founder of Stack Overflow.

Teach Yourself Programming in Ten Years

Mon, 07 May 2012 17:21:16 -0700

Why is everyone in such a rush?

Walk into any bookstore, and you'll see how to Teach Yourself Java in 7 Days alongside endless variations offering to teach Visual Basic, Windows, the Internet, and so on in a few days or hours. I did the following power search at Amazon.com:

     pubdate: after 1992 and title: days and
      (title: learn or title: teach yourself)

and got back 248 hits. The first 78 were computer books (number 79 was Learn Bengali in 30 days). I replaced "days" with "hours" and got remarkably similar results: 253 more books, with 77 computer books followed by Teach Yourself Grammar and Style in 24 Hours at number 78. Out of the top 200 total, 96% were computer books.

The conclusion is that either people are in a big rush to learn about computers, or that computers are somehow fabulously easier to learn than anything else. There are no books on how to learn Beethoven, or Quantum Physics, or even Dog Grooming in a few days. Felleisen et al. give a nod to this trend in their book How to Design Programs, when they say "Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies.

Let's analyze what a title like Learn C++ in Three Days could mean:

Learn: In 3 days you won't have time to write several significant programs, and learn from your successes and failures with them. You won't have time to work with an experienced programmer and understand what it is like to live in a C++ environment. In short, you won't have time to learn much. So the book can only be talking about a superficial familiarity, not a deep understanding. As Alexander Pope said, a little learning is a dangerous thing.
C++: In 3 days you might be able to learn some of the syntax of C++ (if you already know another language), but you couldn't learn much about how to use the language. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for. So what's the point? Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing". One possible point is that you have to learn a tiny bit of C++ (or more likely, something like JavaScript or Flash's Flex) because you need to interface with an existing tool to accomplish a specific task. But then you're not learning how to program; you're learning to accomplish that task.
in Three Days: Unfortunately, this is not enough, as the next section shows.

Teach Yourself Programming in Ten Years

Researchers (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, telegraph operation, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. In another genre, the Beatles seemed to burst onto the scene with a string of #1 hits and an appearance on the Ed Sullivan show in 1964. But they had been playing small clubs in Liverpool and Hamburg since 1957, and while they had mass appeal early on, their first great critical success, Sgt. Peppers, was released in 1967. Malcolm Gladwell reports that a study of students at the Berlin Academy of Music compared the top, middle, and bottom third of the class and asked them how much they had practiced:

Everyone, from all three groups, started playing at roughly the same time - around the age of five. In those first few years, everyone practised roughly the same amount - about two or three hours a week. But around the age of eight real differences started to emerge. The students who would end up as the best in their class began to practise more than everyone else: six hours a week by age nine, eight by age 12, 16 a week by age 14, and up and up, until by the age of 20 they were practising well over 30 hours a week. By the age of 20, the elite performers had all totalled 10,000 hours of practice over the course of their lives. The merely good students had totalled, by contrast, 8,000 hours, and the future music teachers just over 4,000 hours.

So it may be that 10,000 hours, not 10 years, is the magic number. (Henri Cartier-Bresson (1908-2004) said "Your first 10,000 photographs are your worst," but he shot more than one an hour.) Samuel Johnson (1709-1784) thought it took even longer: "Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price." And Chaucer (1340-1400) complained "the lyf so short, the craft so long to lerne." Hippocrates (c. 400BC) is known for the excerpt "ars longa, vita brevis", which is part of the longer quotation "Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile", which in English renders as "Life is short, [the] craft long, opportunity fleeting, experiment treacherous, judgment difficult." Although in Latin, ars can mean either art or craft, in the original Greek the word "techne" can only mean "skill", not "art".

So You Want to be a Programmer

Here's my recipe for programming success:

Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in your ten years/10,000 hours.
Program. The best kind of learning is learning by doing. To put it more technically, "the maximal level of performance for individuals in a given domain is not attained automatically as a function of extended experience, but the level of performance can be increased even by highly experienced individuals as a result of deliberate efforts to improve." (p. 366) and "the most effective learning requires a well-defined task with an appropriate difficulty level for the particular individual, informative feedback, and opportunities for repetition and corrections of errors." (p. 20-21) The book Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life is an interesting reference for this viewpoint.
Talk with other programmers; read other programs. This is more important than any book or training course.
If you want, put in four years at a college (or more at a graduate school). This will give you access to some jobs that require credentials, and it will give you a deeper understanding of the field, but if you don't enjoy school, you can (with some dedication) get similar experience on your own or on the job. In any case, book learning alone won't be enough. "Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter" says Eric Raymond, author of The New Hacker's Dictionary. One of the best programmers I ever hired had only a High School degree; he's produced a lot of great software, has his own news group, and made enough in stock options to buy his own nightclub.
Work on projects with other programmers. Be the best programmer on some projects; be the worst on some others. When you're the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you're the worst, you learn what the masters do, and you learn what they don't like to do (because they make you do it for them).
Work on projects after other programmers. Understand a program written by someone else. See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain them after you.
Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), one that supports coroutines (like Icon or Scheme), and one that supports parallelism (like Sisal).
Remember that there is a "computer" in "computer science". Know how long it takes your computer to execute an instruction, fetch a word from memory (with and without a cache miss), read consecutive words from disk, and seek to a new location on disk. (Answers here.)
Get involved in a language standardization effort. It could be the ANSI C++ committee, or it could be deciding if your local coding style will have 2 or 4 space indentation levels. Either way, you learn about what other people like in a language, how deeply they feel so, and perhaps even a little about why they feel so.
Have the good sense to get off the language standardization effort as quickly as possible.

With all that in mind, its questionable how far you can get just by book learning. Before my first child was born, I read all the How To books, and still felt like a clueless novice. 30 Months later, when my second child was due, did I go back to the books for a refresher? No. Instead, I relied on my personal experience, which turned out to be far more useful and reassuring to me than the thousands of pages written by experts.

Fred Brooks, in his essay No Silver Bullet identified a three-part plan for finding great software designers:

Systematically identify top designers as early as possible.
Assign a career mentor to be responsible for the development of the prospect and carefully keep a career file.
Provide opportunities for growing designers to interact and stimulate each other.

This assumes that some people already have the qualities necessary for being a great designer; the job is to properly coax them along. Alan Perlis put it more succinctly: "Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers". Perlis is saying that the greats have some internal quality that transcends their training. But where does the quality come from? Is it innate? Or do they develop it through diligence? As Auguste Gusteau (the finctional chef in Ratatouille) puts it, "anyone can cook, but only the fearless can be great." I think of it more as willingness to devote a large portion of one's life to deliberative practice. But maybe fearless is a way to summarize that. Or, as Gusteau's critic, Anton Ego, says: "Not everyone can become a great artist, but a great artist can come from anywhere."

So go ahead and buy that Java/Ruby/Javascript/PHP book; you'll probably get some use out of it. But you won't change your life, or your real overall expertise as a programmer in 24 hours, days, or even weeks. How about working hard to continually improve over 24 months? Well, now you're starting to get somewhere...

References

Bloom, Benjamin (ed.) Developing Talent in Young People, Ballantine, 1985.

Brooks, Fred, No Silver Bullets, IEEE Computer, vol. 20, no. 4, 1987, p. 10-19.

Bryan, W.L. & Harter, N. "Studies on the telegraphic language: The acquisition of a hierarchy of habits. Psychology Review, 1899, 8, 345-375

Hayes, John R., Complete Problem Solver Lawrence Erlbaum, 1989.

Chase, William G. & Simon, Herbert A. "Perception in Chess" Cognitive Psychology, 1973, 4, 55-81.

Lave, Jean, Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life, Cambridge University Press, 1988.

Approximate timing for various operations on a typical PC:

execute typical instruction	1/1,000,000,000 sec = 1 nanosec
fetch from L1 cache memory	0.5 nanosec
branch misprediction	5 nanosec
fetch from L2 cache memory	7 nanosec
Mutex lock/unlock	25 nanosec
fetch from main memory	100 nanosec
send 2K bytes over 1Gbps network	20,000 nanosec
read 1MB sequentially from memory	250,000 nanosec
fetch from new disk location (seek)	8,000,000 nanosec
read 1MB sequentially from disk	20,000,000 nanosec
send packet US to Europe and back	150 milliseconds = 150,000,000 nanosec

Appendix: Language Choice

Several people have asked what programming language they should learn first. There is no one answer, but consider these points:

Use your friends. When asked "what operating system should I use, Windows, Unix, or Mac?", my answer is usually: "use whatever your friends use." The advantage you get from learning from your friends will offset any intrinsic difference between OS, or between programming languages. Also consider your future friends: the community of programmers that you will be a part of if you continue. Does your chosen language have a large growing community or a small dying one? Are there books, web sites, and online forums to get answers from? Do you like the people in those forums?
Keep it simple. Programming languages such as C++ and Java are designed for professional development by large teams of experienced programmers who are concerned about the run-time efficiency of their code. As a result, these languages have complicated parts designed for these circumstances. You're concerned with learning to program. You don't need that complication. You want a language that was designed to be easy to learn and remember by a single new programmer.
Play. Which way would you rather learn to play the piano: the normal, interactive way, in which you hear each note as soon as you hit a key, or "batch" mode, in which you only hear the notes after you finish a whole song? Clearly, interactive mode makes learning easier for the piano, and also for programming. Insist on a language with an interactive mode and use it.

Given these criteria, my recommendations for a first programming language would be Python or Scheme. But your circumstances may vary, and there are other good choices. If your age is a single-digit, you might prefer Alice or Squeak (older learners might also enjoy these). The important thing is that you choose and get started.

Appendix: Books and Other Resources

Several people have asked what books and web pages they should learn from. I repeat that "book learning alone won't be enough" but I can recommend the following:

Scheme: Structure and Interpretation of Computer Programs (Abelson & Sussman) is probably the best introduction to computer science, and it does teach programming as a way of understanding the computer science. You can see online videos of lectures on this book, as well as the complete text online. The book is challenging and will weed out some people who perhaps could be successful with another approach.
Scheme: How to Design Programs (Felleisen et al.) is one of the best books on how to actually design programs in an elegant and functional way.
Python: Python Programming: An Intro to CS (Zelle) is a good introduction using Python.
Python: Several online tutorials are available at Python.org.
Oz: Concepts, Techniques, and Models of Computer Programming (Van Roy & Haridi) is seen by some as the modern-day successor to Abelson & Sussman. It is a tour through the big ideas of programming, covering a wider range than Abelson & Sussman while being perhaps easier to read and follow. It uses a language, Oz, that is not widely known but serves as a basis for learning other languages. <

Notes

T. Capey points out that the Complete Problem Solver page on Amazon now has the "Teach Yourself Bengali in 21 days" and "Teach Yourself Grammar and Style" books under the "Customers who shopped for this item also shopped for these items" section. I guess that a large portion of the people who look at that book are coming from this page. Thanks to Ross Cohen for help with Hippocrates.

Translations

Thanks to the following authors, translations of this page are available in:

Arabic
(Mohamed A. Yahya)

Bulgarian
(Boyko Bantchev)

Chinese
(Xiaogang Guo)

Croatian
(Tvrtko Bedekovic)

French
(Etienne Beauchesne)

German
(Stefan Ram)

Hebrew
(Eric McCain)

Hindi
(Vikash Tiwari)

Hungarian
(Marton Mestyan)

Indonesian
(Tridjito Santoso)

Italian
(Fabio Z. Tessitore)

Japanese
(yomoyomo)

Korean (John Hwang)

Persian
(Mehdi Asgari)

Polish
(Kuba Nowak)

Portugese
(Augusto Radtke)

Romanian
(Ştefan Lazăr)

Russian
(Konstantin Ptitsyn)

Serbian
(Lazar Kovacevic)

Spanish
(Carlos Rueda)

Slovak
(Jan Waclawek)

Turkish
(Çağıl Uluşahin)

Eight Reasons Why My Anxiety Is Pointless and Foolish – Justin Taylor

Fri, 04 May 2012 05:56:53 -0700

1. God is near me to help me.

Philippians 4:5-6: “The Lord is at hand; [therefore] do not be anxious about anything, but in everything by prayer and supplication with thanksgiving let your requests be made known to God.”

2. God cares for me.

1 Peter 5:7: “. . . casting all your anxieties on him, because he cares for you.”

3. My Father in heaven knows all my needs and will supply all my needs.

Matthew 6:31-33: “Therefore do not be anxious, saying, ‘What shall we eat?’ or ‘What shall we drink?’ or ‘What shall we wear?’ For the Gentiles seek after all these things, and your heavenly Father knows that you need them all. But seek first the kingdom of God and his righteousness, and all these things will be added to you.”

4. God values me more than birds and grass, which he richly provides for and adorns; how much more will he provide for all my needs!

Matthew 6:26-30: “Look at the birds of the air: they neither sow nor reap nor gather into barns, and yet your heavenly Father feeds them. Are you not of more value than they? And which of you by being anxious can add a single hour to his span of life? And why are you anxious about clothing? Consider the lilies of the field, how they grow: they neither toil nor spin, yet I tell you, even Solomon in all his glory was not arrayed like one of these. But if God so clothes the grass of the field, which today is alive and tomorrow is thrown into the oven, will he not much more clothe you, O you of little faith?”

5. The worst someone can do to me is to kill me and take things from me!

Matthew 6:25: “Do not be anxious about your life, what you will eat or what you will drink, nor about your body, what you will put on. Is not life more than food, and the body more than clothing?” [I.e., you still have eternal life even if you have no food; you will still have a resurrection body even if you are physically deprived.]

Luke 12:4: “Do not fear those who kill the body, and after that have nothing more that they can do.”

Luke 21:16, 18: “Some of you they will put to death. . . . But not a hair of your head will perish.”

Romans 8:31-32, 35, 38-39: “If God is for us, who can be against us? He who did not spare his own Son but gave him up for us all, how will he not also with him graciously give us all things? . . . Who shall separate us from the love of Christ? Shall tribulation, or distress, or persecution, or famine, or nakedness, or danger, or sword? . . . For I am sure that neither death nor life, nor angels nor rulers, nor things present nor things to come, nor powers, nor height nor depth, nor anything else in all creation, will be able to separate us from the love of God in Christ Jesus our Lord.”

6. Anxiety is pointless.

Matthew 6:27: “Which of you by being anxious can add a single hour to his span of life?” [Answer: no one.]

7. Anxiety is worldly.

Matthew 6:31-32: “Do not be anxious, saying, ‘What shall we eat?’ or ‘What shall we drink?’ or ‘What shall we wear?’ For the Gentiles seek after all these things. . . .”

James 4:4: “You adulterous people! Do you not know that friendship with the world is enmity with God? Therefore whoever wishes to be a friend of the world makes himself an enemy of God.”

8. Tomorrow has enough to worry about and doesn’t need my help.

Matthew 6:34: “Do not be anxious about tomorrow, for tomorrow will be anxious for itself. Sufficient for the day is its own trouble.”

Lamentations 3:23: “[God's mercies] are new every morning.”

How Critical Thinkers Lose their Faith in God

Thu, 03 May 2012 21:05:52 -0700

Mind Matters | Mind & Brain

Religious belief drops when analytical thinking rises

By Daisy Grewal | May 1, 2012 |

Faith and intuition are intimately related. Image: iStock/artpipi

Why are some people more religious than others? Answers to this question often focus on the role of culture or upbringing. While these influences are important, new research suggests that whether we believe may also have to do with how much we rely on intuition versus analytical thinking. In 2011 Amitai Shenhav, David Rand and Joshua Greene of Harvard University published a paper showing that people who have a tendency to rely on their intuition are more likely to believe in God. They also showed that encouraging people to think intuitively increased people’s belief in God. Building on these findings, in a recent paper published in Science, Will Gervais and Ara Norenzayan of the University of British Columbia found that encouraging people to think analytically reduced their tendency to believe in God. Together these findings suggest that belief may at least partly stem from our thinking styles.

Gervais and Norenzayan’s research is based on the idea that we possess two different ways of thinking that are distinct yet related. Understanding these two ways, which are often referred to as System 1 and System 2, may be important for understanding our tendency towards having religious faith. System 1 thinking relies on shortcuts and other rules-of-thumb while System 2 relies on analytic thinking and tends to be slower and require more effort. Solving logical and analytical problems may require that we override our System 1 thinking processes in order to engage System 2. Psychologists have developed a number of clever techniques that encourage us to do this. Using some of these techniques, Gervais and Norenzayan examined whether engaging System 2 leads people away from believing in God and religion.

For example, they had participants view images of artwork that are associated with reflective thinking (Rodin’s The Thinker) or more neutral images (Discobulus of Myron). Participants who viewed The Thinker reported weaker religious beliefs on a subsequent survey. However, Gervais and Norenzayan wondered if showing people artwork might have made the connection between thinking and religion too obvious. In their next two studies, they created a task that more subtly primed analytic thinking. Participants received sets of five randomly arranged words (e.g. “high winds the flies plane”) and were asked to drop one word and rearrange the others in order to create a more meaningful sentence (e.g. “the plane flies high”). Some of their participants were given scrambled sentences containing words associated with analytic thinking (e.g. “analyze,” “reason”) and other participants were given sentences that featured neutral words (e.g. “hammer,” “shoes”). After unscrambling the sentences, participants filled out a survey about their religious beliefs. In both studies, this subtle reminder of analytic thinking caused participants to express less belief in God and religion. The researchers found no relationship between participants’ prior religious beliefs and their performance in the study. Analytic thinking reduced religious belief regardless of how religious people were to begin with.

In a final study, Gervais and Norenzayan used an even more subtle way of activating analytic thinking: by having participants fill out a survey measuring their religious beliefs that was printed in either clear font or font that was difficult to read. Prior research has shown that difficult-to-read font promotes analytic thinking by forcing participants to slow down and think more carefully about the meaning of what they are reading. The researchers found that participants who filled out a survey that was printed in unclear font expressed less belief as compared to those who filled out the same survey in the clear font.

Following Up on the Jesus/Religion Video – Kevin DeYoung

Tue, 01 May 2012 10:14:49 -0700

Well, the internet is a strange place. With all the enthusiasm for and against Jeff Bethke’s viral video and now all the enthusiasm for and against my critique, it may seem like all we have here is sound and fury signifying nothing. Maybe another Bellesque brouhaha in the making.

But sometimes good things happen on the internet, even in exchanges like this. Jeff sent me an email yesterday afternoon and we exchanged several emails since then. I have his permission to post parts of that exchange.

This was his first email to me:

I just wanted to say I really appreciate your article man. It hit me hard. I’ll even be honest and say I agree 100%. God has been working with me in the last 6 months on loving Jesus AND loving his church. For the first few years of walking with Jesus (started in ’08) I had a warped/poor paradigm of the church and it didn’t build up, unify, or glorify His wife (the Bride). If I can be brutally honest I didn’t think this video would get much over a couple thousand views maybe, and because of that, my points/theology wasn’t as air-tight as I would’ve liked. If I redid the video tomorrow, I’d keep the overall message, but would articulate, elaborate, and expand on the parts where my words and delivery were chosen poorly… My prayer is my generation would represent Christ faithfully and not swing to the other spectrum….thankful for your words and more importantly thankful for your tone and fatherly like grace on me as my elder. Humbled. Blessed. Thankful for painful growth. Blessings.

Grace and Peace,

Jeff

I wrote this in reply:

Thanks for your email. It confirms my impression of you—humble, sincere, a real love for God and the gospel. I can’t remember ever receiving such a teachable response to criticism. I’m grateful for you and your courage in taking time to write me a note. Really grateful.

I know that criticism can be hard. You are probably getting it from right, left, and center, from Christians and non-Christians. I’m sure you are getting a lot of affirmation too, and that presents its own challenges. I tried to my write my post as a friend, not as a hater. I am rooting for you, not against you. I wanted to approach this like Acts 18:26. Thank you for receiving it in that spirit….

What can I do to help you? Have you thought about posting a clarifying follow up to the video? Or maybe writing something on “what I wish I had said differently?” It could be a powerful example of the things you were talking about to come back and say, “Hey, I didn’t get everything right here. I don’t want people to take this in the wrong direction.” Do you want me to post some of your email to me on my blog so people can see your heart in this? Let me know if there is something I can do.

Your friend,

Kevin

Later Jeff wrote me back. This is part of his reply:

Wasn’t expecting such a quick response. I appreciate you a ton, and your words really hit home…My biggest fear is that I will say something and it will be out on the internet forever. But already quickly learning all praise goes to Jesus, and same with critique…Feel free to share parts of my email on the blog if you’d like! The tone is already gracious enough but it’d be cool to show that we have had some correspondence and it’d mean a lot.

The actual emails were longer, but these excerpts give you a feel for the tone. I’m immensely grateful for Jeff’s response and feel like I’ve made a new friend in this process. We talked on the phone this morning and had a chance to get to know each other better. We talked about the wonders and trials of the internet and the difficulty in receiving praise and criticism. We both talked about what we could have done differently in retrospect.

A friend wrote to me yesterday and said, “This is a good test for both Jefferson and for yourself. Is he the kind of guy who would be willing to write a critic with humility? And did you write the piece in such a way that the one being criticized would feel comfortable chatting with you?” I hope we are passing that test. Through the years I haven’t always aced this kind of exam.

I hope everyone reading this blog will share Jeff’s heart and mine for getting the gospel out as far as we can and as right as we can. I look forward to seeing Jeff’s next video.

Instapaper: Starred

Things You Should Never Do, Part I - Joel on Software

Next:

Want to know more?

About the author.

Teach Yourself Programming in Ten Years

Why is everyone in such a rush?

Teach Yourself Programming in Ten Years

So You Want to be a Programmer

References

Appendix: Language Choice

Appendix: Books and Other Resources

Notes

Translations

Eight Reasons Why My Anxiety Is Pointless and Foolish – Justin Taylor

How Critical Thinkers Lose their Faith in God

Following Up on the Jesus/Religion Video – Kevin DeYoung