I recently led a session on this at BarCamp NewsInnovation Philly. It began with a brainstorming discussion on different types of thinking, which were mapped in the graphic below. My Publish2 colleague, Lauren Rabaino, also took extensive notes (there’s summary of coverage at the end of this post).

Mindmap by Aram Zucker-Scharff

My interest in different types of “thinking” came as I researched computational thinking, a concept outlined by Jeannette Wing, then a professor at Carnegie Mellon. This term “represents a universally applicable attitude and skill set everyone, not just computer scientists, would be eager to learn and use,” she says.

Wing, now at the National Science Foundation, said in her 2006 article:

“Computational thinking involves solving problems, designing systems, and understanding human behavior, by drawing on the concepts fundamental to computer science. Computational thinking includes a range of mental tools that reflect the breadth of the field of computer science.”

Some “everyday examples” of computational thinking that she outlines include:

“When your daughter goes to school in the morning, she puts in her backpack the things she needs for the day; that’s prefetching and caching. When your son loses his mittens, you suggest he retrace his steps; that’s backtracking. At what point do you stop renting skis and buy yourself a pair?; that’s online algorithms. Which line do you stand in at the supermarket?; that’s performance modeling for multi-server systems. Why does your telephone still work during a power outage?; that’s independence of failure and redundancy in design…”

A few days after BCNI Philly, I came across a May 2009 piece by Kim Pearson that relates the concept to journalism. In it she articulates some insightful points, including that “computational thinking is more than digital literacy.” Also,

“I’m not saying that journalists need to become programmers. I’m saying that we need to be able to reason abstractly about what we do, understand the full palette of computational tools at our disposal, and collaborate to deploy those tools with maximum efficiency and effectiveness.”

This ties in to something I said at the session, in response to a comment about what it means to bring computational thinking to journalism: It’s not about turning the reporting process into a rigid, scientific formula — journalism incorporates both art and science. It’s about taking the concepts, ideas, practices, etc. from different areas of thinking — including computation — and applying them to do better journalism.

There’s so much more that could be done — and at a more fundamental level — to improve our journalism with this additional way of thinking. Though he doesn’t identify it specifically, computational thinking is very much at the heart of the ideas outlined by Stijn Debrouwere in  We’re in the information business and the rest of his series on information architecture for news):

“Let’s not kid ourselves. A new way of doing journalism requires new technology to support and foster that innovation. That technology should reach right into the core of our journalistic endeavors, not just touch the periphery…”

And a new way of doing journalism means incorporating new ways of thinking.

(To simplify things below, I use the titles “journalist” and “programmer” below to describe a primary role. Of course, a journalist can be a programmer and a programmer can be a journalist.)

In addition to computational thinking, another important point that came out of the BCNI session is that communication and collaboration between journalists and programmers needs to improve so we can build the necessary tools to do better journalism. Understanding computational thinking is one step, but it would also be beneficial for journalists to understand more specific programming concepts. Again, not all journalists necessarily need know how to program (though we do need more journalists who know code and I, as someone learning more coding skills, would highly recommend journalists learn as much as they can).

Put another way, it would help journalists to understand the similarities between programming and journalism. As a personal example, when I served as editor of The Miami Hurricane, one of our best copy editors — by chance — was the webmaster, Brian Schlansky. I eventually realized the reason: he was accustomed to staring at lines of code and searching for errors, akin to a copy editor.

Here some commonalities I’ve drawn between journalism and programming:

• Abstraction: My colleague Daniel Bachhuber verbalized this well: This means breaking something down into discrete elements. In the context of journalism, it means breaking things down into concrete questions and then finding the answers, which you can compose in some fashion.
• Defining your variables or functions: Programming involves defining variables and functions to quickly and efficiently reference something without redundancy (ideally). As the saying goes, “don’t repeat yourself” (usually abbreviated as DRY). This is just like journalism. For example, if you’re writing about a fire, you need to explain the who, what, when, where, why, how, etc. “variables” so people understand what you mean later on when you reference “the fire.” Also, when you mention something related to the subject matter and link to more background or context. The DRY (unnecessarily) principle also applies to journalism.
• Debugging: This process of locating and correcting errors in a code is similar to copyediting (think for the webmaster-copy editor example).
• Bug and error reporting: When my browser crashes, it gives me the option to send an error report. When someone catches a factual error, we ask them to let us know. These two concepts already intersect with Scott Rosenberg’s MediaBugs, which launched in beta last week and allows users to report and discuss errors.
• Commenting your code: Leaving a comment in your code is a way of adding information that doesn’t interfere with the code and, for example, helps to explain what something is and why it’s there. This is much like how a reporter would provide context for a quote, which you can’t change without “breaking it,” so to speak.
• Learning different programming languages: On the bus back from Philly, I listened to a tech podcast on which Kevlin Henney, author of 97 Things Every Programmer Should know, asserted that programmers should learn other languages to improve inform and improve how they write their primary language. Similarly, journalists are encouraged to read other forms of composition to become better writers and watch other styles of motion pictures to become better videographers. For example, I’ve heard recommendations to take a screenwriting class and learn about that style to my enhance journalistic work.
• Refactoring: This refers to changing internal code without effecting the external meaning or behavior. Another definition that correlates more to journalism says it’s a “form of editing whose goal is to improve readability while preserving meaning. It is a stronger term than copy editing.” This reminded me of the larger structural or organizational changes sometimes needed to improve a story while still maintaining the original focus.
• Algorithm: In general sense, this is a “precise rule (or set of rules) specifying how to solve some problem.” A cooking recipe could be considered an algorithm, as could  the reporting process — you start with some information or questions and then do research, interview people, draft and finalize a story as the result. That said, journalism includes elements of both art and science, not a rigid process as I explained before.
• Version control: When creating software, a core principle is keeping track of each iteration of the project. In the editing workflow of a news organization ideally keeps track of different revisions, either on a single document (for The Hurricane, that would be in the WordPress admin) with a history or by saving a new document and noting who last saw it (as The Hurricane did before switching to WordPress).
• Semantic: Another word for semantic is unambiguous, David Siegel says. More specifically, ”In the Semantic Web, we declare what we mean in precise, standardized terms. Data that is semantic means exactly the same thing to any system or person who uses it.” Do we not aim for the same thing in journalism?

So, really, you could say computational thinking has always been a part of journalism — we just hadn’t labeled it as such.

Many more parallels can be gleaned from works such as this Pragmatic Quick Reference (hat tip, Chrys Wu) and The Zen Python (hat tip, Christopher Groskopf). Read the latter — included below — and consider how many of these statements could work just as well for journalists as they do for Python coders:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!

Again, the point here is to show the similarities between journalists and programmers — to help overcome any perceived barriers.

But we can’t and shouldn’t wait for any magical bridge to appear. There are so many things we can do today, even as simple as rethinking our thinking. If we do, then we can more easily pick up one another’s skills and tools.

Overall, by integrating journalism, programmers and “computational thinking for everyone,” we will be better prepared to more effectively build the tools, practices and platforms we need. And, with those platforms, we will be able to further connect and innovate to do better journalism.

Other posts about BCNI Philly 2010

Where journalism gets reinvented
Random Mumblings | April 25, 2010

Peer News, emerging news hybrid in Hawaii
Daniel Bachhuber’s weblog | April 24, 2010

BCNI Philly: APM’s Public Insight Network
Daniel Bachhuber’s weblog | April 24, 2010

BCNI Notes: Howard Weaver on an emerging news biz model
Lauren Rabaino | April 24, 2010

BCNI notes from “The Insight Graph: CRM for Journalists”
Lauren Rabaino | April 24, 2010

So why are developers obsessed with Facebook? Because there are fewer applications on Facebook than there are on the web, so there is less competition — at least for now. That’s it.

But Facebook will eventually be overrun with apps, just like the web. So will MySpace’s new platform. So will every application with lots of users that turns itself into a platform.

Platforms are already commodities. Because the WEB is the real platform. Google’s Jeff Huber said it well at Web 2.0 yesterday:

A lot that you have heard here is about platforms and who is going to win. That is Paleolithic thinking. The Web has already won. The web is the Platform. So let’s go build the programmable Web.

Sounds like an attack on Facebook Platform and all of the me-too platform plays, right? Maybe on the surface. But I’ll bet if Facebook’s Mark Zuckerberg was listening at Web 2.0, he was smiling to himself.

Because Facebook Platform is just one big feature development and testing scam — and a brilliant one at that. But Zuckerberg and Facebook know that’s not where the real value is.

The real value is in the DATA.

Facebook has been attacked for not letting users export their data and use it on another social networking service.

Well, DUH. How else are they going to create any business value?

Applications — the front end technology — are no longer the core business asset, at least not in the long term. It’s way too easy for anyone to clone anyone else’s application.

And that means applications built on another service’s platform aren’t the real asset either — it’s too easy to reproduce. Just watch MySpace’s platform catch up with Facebook’s platform.

So what is the business asset? The users — and their data. The “social graph” is what drives value for users on Facebook. They have all their data on Facebook. Their friends have all their data on Facebook. That’s it. Done. The users are happy. They’re locked in, but they DON’T CARE.

Users put data into Facebook. Their friends put data into Facebook. Facebook kicks back a lot of value. Everyone is wins.

All the silly platform applications — it’s just a game for Facebook. Test a bunch of new features. Test how users respond. Test new ad models. All with free labor. Brilliant — but still a sideshow.

Facebook isn’t building its business around apps — it’s building it around data — by making that data hugely valuable to advertisers.

Try to think of a successful web company who asset is anything other than data. YouTube’s videos (including the copyrighted ones). Facebook’s social graph. Google’s indexed web pages. Amazon’s user purchase history.

Tim O’Reilly had been evangelizing DATA for a while now, but somehow the message hasn’t gotten through to everyone:

That goes back to a major theme of web 2.0 that people haven’t yet tweaked to. It’s really about data and who owns and controls, or gives the best access to, a class of data.

All you have to do is look around to see that it’s all about the data.

The most successful companies on the web are those that created a virtuous cycle between their users and their database, where the more data users put in, the more value they get out. That’s the essence of Web 2.0. Data has limited value locally, or walled off on a single site. But pool that data, and the whole becomes much greater than the sum of its parts, allowing everyone who puts data in to take much more value out.

That’s what drives the search economy. That’s why NYTimes.com realized they were better off putting their content (data) into the search engine index (database), because they derive more value from putting data into the search ecosystem than they do keeping it to themselves.

YouTube, MySpace, and Facebook didn’t get big because they created technology that couldn’t be cloned — their applications were cloned dozens (hundreds) of times over. They got big because they were the FIRST to create a well-designed application that drove a virtuous cycle of data input and data output for a particular group of users, e.g. college students. And once they got the data, no competing applications could create the same value for users, because they weren’t sitting on top of the same massive database.

Got data? Got users who thrive the more data they put in. You win.