Blacklisting Wikipedia & Information Literacy

I taught an interdisciplinary course this past semester, "The Nature of Knowledge." My co-instructor and I focused specifically on what happens to knowledge in a networked, digital environment. The course was revelatory for me, both because it was the first I've taught as a lead instructor and due to how students reacted to our content. The course is going to inspire a slew of blog posts, but I want to start with a plea to postsecondary educators:

Your attitude towards Wikipedia is destroying students' critical thinking.

I say this because virtually every student in the class had heard that Wikipedia is inappropriate for academic use. And it is; it says so itself. The problem is they have no idea why. The most common reason proffered was "because my professors said so," the very antithesis of critical thinking.

Information Literacy & Lists

The third bullet point in ACRL's information literacy competency standards is "evaluate information and its sources critically." This is where assignments that blacklist or whitelist certain sources fail. Rather than equip students to analyze sources, valid sources are pre-selected and often according to arbitrary criteria. For instance:

No Internet sources is a common theme. Even with an "except the library databases" caveat, this is at best confusing and at worst counterproductive. What about Google Scholar, OAIster, Scirus, and all the other open access aggregators? The web is the primary delivery mechanism for scholarly knowledge. One cannot simply write it off. This is especially harmful because it trains students to ignore so many wonderful sources out there. What will they do when they don't have access to research databases? We're teaching them that the open web is useless for research when it's not.

Then there are the blacklists which specify Wikipedia. The issue here is the discrimination: why is Yahoo! Answers not listed? About.com? Ask.com? Conservapedia? The list goes on. It's a fruitless endeavor to delimit the poor sources from the good ones. And Wikipedia is likely singled out not because it's particularly bad but because it's so common.

Finally, there's the inverse approach of assignments which require peer-reviewed articles. The issue is, at least for the first few years of an undergraduate degree, peer-reviewed sources are too arcane for our students. This is less of an indictment of students' reading than academic writing, which eschews accessibility. I've heard grumbles around the librarian blogosphere about peer-reviewed article requirements (Meredith Farkas' screed against freshman research papers is a must-read) and plenty of people are critical of them. They're still all-too-common in assignments.

The underlying concern throughout all of these approaches is that they rarely explain why. Why is the web so awful, especially since many scholarly sources now appear there? Why is Wikipedia specifically worse than other sites that allow anyone to publish? What the heck is peer review and why do we care about it? I touch on all these when I teach information literacy, but half of the time I'm combating the assignment. The ACRL standard is evaluate information and its sources critically, not uncritically accept whatever unjustified stance is taken by the assignment. These assignments cultivate intellectual laziness, to quote my co-instructor, not the skills to critically evaluate any source, regardless of where one happened to find it.

What's really wrong with Wikipedia?

In my classes, I'll often do comparative searches across Google and a library database, then ask students to evaluate a chosen result using a metric like the CRAAP test. I distinctly recall a class when I brought up a Wikipedia article and asked which elements of the CRAAP test it failed. All of them, a student ventured. Nothing could be further from the truth.

Currency? It varies, but most Wikipedia entries are updated frequently. In fact, this is one area where Wikipedia has a structural advantage over other modes of publication: because there's such a wonderfully low barrier to participation, new information can be added as soon as its published elsewhere. Compare this to traditional tertiary sources (especially print ones), where editorial and publishing processes delay information becoming available to end users. On the other hand, compare Wikipedia to other websites; every article has, down to the very minute, its last-updated date visible on the "View history" tab. Anyone who has helped a student cite a website knows that determine the publication date is usually an exercise in futility.

Relevance? Wikipedia's enormous breadth virtually ensures it has something relevant to say on any topic.

Authority? This is Wikipedia's only problem in terms of the CRAAP test. We usually don't know who has contributed to any given article, it could be a credentialed academic or anyone else. Wikipedia itself dismisses authority, stating What is contributed is more important than the expertise or qualifications of the contributor, a provocative stance which I don't have space to explore here.

Accuracy? Wikipedia articles can have hundreds of references. The encyclopedia's insistence on verifiability and citations are cardinal strengths. In fact, the way I recommend most students use Wikipedia articles is to learn important terminology from them and mine their references. I wrote a paper in graduate school on net neutrality; Wikipedia was my first stop and it outlined not only the major issues but also linked directly to pertinent policies and secondary sources. Thanks largely to that excellent start, my paper earned an A.

Purpose? Wikipedia is admirably forthright about what it is and is not. Its goals are noble (as evidence by its enlightened five pillars), especially relative to for-profit alternatives like About.com which display ads and lack external references.

Yet no one had walked my students through this kind of analysis. No one had shown them the "View history" tab of an article, or its references section, or any of Wikipedia's fundamental policies. Why Wikipedia is a non-academic source was always left as an exercise for the reader.

"Anyone Can Edit"

It's worth investigating the "anyone can edit" argument further, because it appears to be the main objection to Wikipedia.

First of all, it is not strictly true that anyone can edit any article at any time. Certain articles are protected and can only be edited by a subset of editors, such as administrators or confirmed accounts. These articles tend to be common targets for vandalism. They form a small minority of articles.

Secondly, as my students found out, wiki markup is nontrivial. It takes some familiarity before an editor can do anything other than add unformatted text. This was a large obstacle for most of my students; despite an exercise introducing them to HTML using Codecademy early on, many struggled to understand more complex markup structures such as references and links. It seems unlikely that someone would invest a great deal of time learning wiki markup only to write nonsense into articles. Most would take the time to learn editorial guidelines as well as markup, which we did in our class by reading guidelines and Joseph Reagle's Good Faith Collaboration.

Thirdly, the "anyone can edit" objection often refers to vandalism more so than biased or inaccurate writing. The problem with this argument is...how often do you see actual vandalism on Wikipedia? Even the hypocrites who ban Wikipedia have likely read dozens if not hundreds of articles. I've probably read thousands myself but I've only ever seen vandalism once, which is largely due to the fact that anyone can edit. Anyone who spots vandalism can easily remove it and Wikipedia also employs bots to detect and delete vandalism. I made a brief video that covers the points in this paragraph, showing an example of vandalism that was reverted within a minute.

Finally, and most importantly, "anyone can edit" does not equate to "anyone writes anything they want." Wikipedia has standards which are enforced by an editorial community. It is not an open forum for any kind of discourse, it's an open encyclopedia written from a neutral point-of-view. Yes, there are articles which are inaccurate, biased, or incomplete. But they're not the product of a million monkeys hammering away on laptops, they're deliberate steps towards a better and more encyclopedic article.

What's really great about Wikipedia?

Wikipedia has a few advantages over traditional research sources, such as the widely distributed editorship, the speed with which articles can be updated, its strong community norms, and the bots which automate low-level tasks like reverting vandalism. But there has always been one thing that stands out about Wikipedia to me: it is the only source which warns you of its own inadequacies. From inline citation needed and weasel words warnings, to colored boxes up top (unencyclopedic, doesn't represent a worldwide view, personal reflection or opinion, uses out-of-date sources...the sheer variety of these indictments speaks to just how high the encylopedia's standards are, and how often they're not met); Wikipedia wants you to know it's imperfect. Users should be aware that not all articles are of encyclopedic quality from the start: they may contain false or debatable information.

No one else does this. Not About.com, not Britannica, not brilliant economists who make errors in their Excel spreadsheets. A source detailing its own issues is virtually unheard of and can only come about in a community like Wikipedia, where numerous editors representing diverse viewpoints constantly enforce a set of stringent standards.

To bring this back to assignment structure, it provides instructors with an easy criterion, too. If you must blacklist Wikipedia articles, how about starting with the ones that have issues identified by alert boxes? While this doesn't challenge students to analyze sources by themselves, it at least tells them why a particular article is unusable.

Scaffolding

I'll readily admit; I oversimplify concepts in instruction sessions all the time. It's productive to create a foundation of a few artificial givens upon which students can build. Then, in a later course, those assumptions can be examined and problematized. So, to some extent, black- or whitelists of sources are useful, they wean students off of poor sources until students can analyze them on their own. Scaffolding is tricky and I certainly haven't mastered it yet.

However, college is the time when we should be examining students' perceptions surrounding Wikipedia. The Wikipedia ban is a high school scaffold; it needs to be torn down in the first two years of college. Students can benefit from using Wikipedia articles appropriately, from understanding tertiary sources, from thinking critically about the sorts of issues that pop up in alert boxes at the top of questionable articles. If nothing else, the heresy of crowdsourcing—that a mass of amateurs can produce information as good as or even better than a handful of experts—must be taught. It's too important to today's information economies to be overlooked.

Faculty & Technology

This is a continuation of my First Search Committee post, largely inspired by respondents answers to questions about technology. I broke it into a second post for several reasons: there were no good responses to technology questions, the first one was already pretty long, & I have a specific interest in educational technology. It's not merely that I'm a library technologist, it's also that I serve on a distance learning committee that exposes me to a lot of major issues with the way we deliver education online. When we framed what we wanted in a candidate, experience teaching online was one of our primary attributes. Despite receiving numerous, well-qualified applicants, this was the one area where we couldn't match our desired qualifications.

Bad Interview Responses

Students love watching videos! I use lots of YouTubes.

I asked a question about online tech usage during the phone interviews and no one gave a convincing answer. The worst were neo-Luddite and the best contented themselves to list a series of proper nouns as if that demonstrates technical competence: BlackBoard, WebCT, YouTube, PowerPoint. PowerPoint is never a great answer to any question, but it's particularly bad answer to a question about online technology. What I really wanted was an honest, critical opinion of tech. Tell me how you use it and why, not what you use. Your specific tools are time-sensitive and prone to making you look foolish if you name something antiquated. If you have proficient in WordPerfect on your CV, now would be the time to remove it. Honestly, my solitary question about online technology was easily the most troublesome part of the hiring process. Many instructors are comfortable using technology but few seem thrilled about it or possessed of any rudimentary understanding.

I love technology, but Twitter/texting is ruining my students writing.

Really? That's interesting, do you have any longitudinal data to share? I assume you ran a multi-year study, comparing students who use Twitter to a control group who do not, to come to this conclusion. It's a bit controversial, because virtually every piece of research on this subject disagrees with you: the more someone reads and writes, the better they are at reading and writing. Thanks largely to the ubiquity of cell phones, students are reading and writing more today than they ever have in the past. Those students who write poorly today may have been near illiterate without the added practice of texting or tweeting. Secondly, consider that one of the faculty members you're talking to might be hella into Twitter. I identified myself as the Emerging Technologies Librarian before asking my question; anyone with any familiarity with Twitter probably knows it's popular among those in the tech scene. When you say "Twitter is turning my students into idiots," the snarky response that pops into my head is: I use Twitter, do you think I'm an idiot?

Students are good with technology! They show me how to do things!

I like the admission that one learns from one's students. I don't mean to indict that. But the blanket generalization that all students are good with technology is not only false, it's damaging. I know these faculty members. They're the ones who ask students to make a chart in Excel without giving any instruction. They ask students to make a video presentation without knowing how to do it themselves. And when the students become frustrated and get stuck, they come to the library, where we patiently try to guess what the faculty member wanted and assist the student in completing the assignment. That's a big part of my job and I'm not complaining about the helping part; I love it. I'm complaining about the poorly written assignment that assumed a skill base that didn't exist.

The Myth of the Digital Native

The assumption that students are skilled and comfortable with technology belies a much more disconcerting issue: the myth of the digital native is alive and well in academia. The myth, for those who are unfamiliar, is basically the kids these days are so good with computers. It's an assumption that growing up today, our younger students are so inundated with technology that they somehow magically glean a deeper understanding of it than prior generations. The fact is, many of our younger students know how to log onto Facebook, send a text message, and little else. If you ask them what web browser they use, they will say Google. And they don't mean Chrome, they mean Google. They can't differentiate between the address bar and the search box in Internet Explorer 8. Many have a cursory understanding of the use of some pieces of tech and but no conceptual grasp of the larger edifices of the web and computer operating systems.

To be clear: some students obviously do understand tech, the issue is when we assume they all do.

At a community college, the digital native assumption is even more problematic. When you say students are good with technology, meaning that the younger generation is, what I hear is I don't understand that many of my students will be adults, some doubtless older than I am. We have a lot of adults returning to higher ed. For many of them, calculators were the only computing device involved in their prior education. Now we ask them to understand the bloated behemoth that is a Learning Management System, to juggle several different accounts, to manage at least two emails, to complete assignments using specific software packages (e.g. PowerPoint). It's a major struggle for many of them; again, I know because I end up helping them in the library. A faculty member simply assuming technical competence is severely damaging their ability to deliver effective instruction.

Where Do We Go From Here

I don't have a solution to the problems I've raised. As a job applicant, I would avoid naming specific software, instead describing the broader category to which they belong (e.g. word processing, presentation). I would also take some time to think critically about how you incorporate technology into instruction. Do you use it to increase collaboration? To make instruction less top-down & more interactive? Or are you simply showing amusing YouTube videos because the students seem to like them? There's a vast gulf between using technology and using it effectively.

Finally, I want to impress one hopeless plea upon the graduate schools of the world: offer—ideally require, but I'll settle for offer—an instructional technology class for all disciplines that covers the basics of technology, its technical underpinnings, how to use it, and finally how it can fit successfully into different pedagogical strategies. As a devotee of two-year, teaching-focused institutions, I already think it's tragic that most faculty members don't receive any teaching training. They become brilliant researchers and writers, but they're mostly left to their own devices when it comes to teaching. Knowledge of educational technology falls by the wayside as a consequence. Its use can be learned on the job but I wish grad schools would do more in this area.

What I Learned from My First Search Committee

I was recently on my first search committee for a full-time faculty position at my community college. I was excited to see academic hiring from the other side and, sure enough, I learned much about the process. Below, I express my particular preferences for the enlightenment of the job-searching public. These views do not represent those of my institution or my peers on the search committee (indeed, some would doubtless disagree with certain contentions).

I will write a second post focusing on technology, because I found our applicants' ideas about technology particularly underwhelming.

The Good

Included is my teaching philosophy.
Oh, we didn't ask for a statement of teaching philosophy? I don't care. It was great to read these statements. The mere fact that an applicant sent an unsolicited pedagogical statement meant that they'd thought about teaching as a discipline. It indicated a degree of rigor and dedication.

For instance, in my 101 class I have my students do...
Yes, a concrete example! It's very easy to say that you're a great teacher, you care about students, you employ multimedia, you know technology, you appeal to variegated learning styles. There, I just did it. Obviously, I'm the best candidate! No, the people who stand out give concrete examples that show me that they know their stuff. They don't say "proficient in Microsoft Office" they say "I hold Skype office hours." They give assignments, lectures, and media right there in the cover or add further attachments.

Attached are my student reviews.
It surprised me to see student reviews included. While it's true that, if you've been teaching a while, it's trivial to pick out the two semesters you happened to receive ace reviews. But I do like seeing reviews, be they from students or peers. It shows that the faculty member kept the reviews, cares about them, thinks that they speak well of their teaching. That alone is important.

Developmental and adult education...
These are the people that really get it. While many applications mentioned diversity, a surprising few actually singled out their experience with developmental education and non-traditional students. When you mention these issues it tells me that not only have you worked at a community college but you paid attention to the institution's foremost issues and programs. How to effectively deliver developmental education is a huge dilemma for us. Even if we're hiring for a position that will never teach developmental classes, the faculty member will teach students either in or recently out of developmental ed.

Honesty
Many interviewees were clearly honest; they said things that undoubtedly were admissions of weakness, or humanity, basically anything that made them out to be something other than a robot sent from the future to instruct students to death. You're nervous about the interview? That's perfectly normal and we're not hiring you to sit through job interviews, we want to know what kind of teacher you are. You're a woman and a mother, first and foremost, and a faculty member second? Well, that's great, those are logical priorities. The value of honesty isn't in the statements themselves but the trust that it builds with the hiring committee.

I also liked mentions of service learning or flipping the classroom, topics which have come up recently amongst our faculty. It shows that the applicant is aware of some of the same teaching approaches that we utilize.

The Bad

I'm available ASAP.
I've written this in cover letters because it sounds like a plus. In truth, if we're worried about your start date, that worry comes much later. Say you're available to start immediately during your phone interview or especially once you've been called to campus. But anything prior to that is both irrelevant and makes us think that you're desperate, perhaps have been rejected by other places for reasons we haven't discerned yet.

My research focus is...
Under certain circumstances, & when written in a concise manner, research interests can work well in a cover letter written to a community college. But applicants should understand that I want to know first & foremost what kind of teacher you are. Research is not a part of our mission, period. The easiest way to rule out most candidates was when their cover & CV went to great lengths to demonstrate their research prowess to the detriment of teaching. If you're a respected researcher with plenty of publications & presentations, by all means add that to your CV. But if all you can say about teaching is "yeah I really love it" then your application immediately drops to the bottom of the pile.

I taught graduate level quantitative analysis, a seminar on Michel Foucault's notion of transgressive dissimulation in relation to the liminal corporeality of modernity...
OK, so you've taught a bunch of things that will never be in our curricula, cool. I guess I can just skip over this section. It becomes even more worrisome if that looks like the only thing you teach because now I'm concerned that you'll be bored—or worse, think it beneath you—when teaching introductory level courses exclusively. And while this search committee wasn't in my area of expertise, I'm quite familiar with theory. If I can't follow your course's theme or what you say your research interests are, I worry our students won't either.

The Ugly

Your esteemed institution
Look, no offense to MPOW which I truly love, but no one esteems us. We're not Harvard and, more importantly, we're not trying to be Harvard. Institutional prestige is meaningless to us. We're in the business of teaching students, of moving them along to prestigious institutions. We don't need the credit. And the fact that you failed to name our institution indicates you sent this same cover to a dozen other schools.

I taught X at Y, Z at A, B at C, D at E, F at G, H at I..
Yes, people actually wrote this in their cover. The laundry list approach shows you're clueless and perhaps haven't read your own cover letter aloud. Lengthy lists are unpersuasive, particularly when you relate zero details about each appointment (oh boy, do we get to be another bullet point on your list?!?). Furthermore, it wastes an incredible amount of space in the cover when I'm searching for persuasive narrative. These details are entirely redundant with your CV; let the CV do that, the cover is the time to tell me about who you are and why we want you.

Tiny font, no line-spacing, letters over a page & a half long
All of these show me that you don't respect the hiring process. We're reading a lot of letters. I would love to devote an infinite amount of time to carefully considering each applicant but the truth is the reason why there is a conventional cover letter length is that time is finite. No one gets extra time or space. Have a lot to say? Include an optional attachment that I reserve the right to ignore or only consult if you make it to the next round of consideration. But making your cover 8pt font with no line spacing is a sophomoric trick which fools no one. An unfortunate majority of faculty don't trust students and thus require a particular font and spacing; do you really think they won't spot the opposite trick coming from you?

Conclusion

After reading dozens of job applications, many of the points above were obvious. But they weren't all on my mind when I was submitting job applications. I probably included laundry lists, I said I was available ASAP, and I didn't include a teaching philosophy (which, as it happens, was never required for any of the positions I applied to). The point is: none of this is obvious. I hope someone reads it and finds it helpful.

Libraries, Art, Math, & the Value of Failure

I am going to start in one place & end up somewhere else. Ready? Here we go.

Failure

There's a wonderful trend lately at library conferences of promoting open dialog around failure. I was first acquainted with this at the #drupalfail sessions held by LITA's Drupal Interest Group. Presenters would detail the various ways their projects crashed & burned, or merely did not meet expectations. With Drupal, this is particularly easy: it's a complex CMS, as powerful as it is enigmatic, & you have to be fairly experienced to successfully plan & implement a project with no hiccups along the way.

Related news flash: most librarians don't learn Drupal in library school, it's something they learn on the job, so there's a lot of intermediate failures before anyone gets close to something that vaguely resembles success. But Drupal isn't the only example of this trend: I heard good things about Code4Lib's "Fail4Lib" preconference. There have been scattered talks elsewhere discussing the need to create a culture where taking risks & occasionally failing is a welcome. It's certainly a necessary element of innovation.

What stands out about these failure sessions? They're useful. Knowing someone else's mistakes saves you immense amounts of time & often all you have to do is avoid something stupid to gain from it. As a technologist at a small library, I'm constantly bombarded with awesome things I can't use: they require money, or staff, or time, or expertise, or scale that we just don't have. It's cool to hear about Linked Data & Near-Field Communication; it's not something that would be a wise investment on my part. But when I hear someone say that creating a custom theme from scratch in Drupal is a waste of time relative to using a pre-built theme, I instantly am more prepared to do my job. Don't reinvent the wheel with theming, check. Lesson learned, time saved.

Art

When you consider the pedagogical value of failure, some weird issues arise. I had a unique undergraduate career in that I was trained in both the humanities (English) & formal sciences (Mathematics). You know what both of those fields happen to be utterly terrible at? Teaching failure. In math, when a theorem is superseded, it's simply not taught anymore. It might as well have never existed. I never had homework problems phrased "spot the problem with this theorem" or "hey Fermat was a dummy, can you tell why?" Mathematics ignores an entire mode of analysis. You become skilled at deductive reasoning & constructing your own theorem cabins from axiom Lincoln Logs; you never learn how to approach someone else's theoretical edifice other than simply assuming it's true because it's in the textbook.

English is also awful at admitting failure, in its own warped way. We read the classics, but not the failed classics. There are at least two kinds of failed classics: works which were highly regarded in their own time but grew irrelevant & works which were never highly regarded in any time. Either way, why are the canonical works more valued than the telling failures of their contemporaries? While Mathematics education's failure to teach non-deductive modes of logic is troubling, artistic prejudices are even more disturbing.

Everyone has, by now, heard "beauty is in the eye of the beholder." The aesthetic disciplines cling to this maxim as if it somehow places them outside the realm of objective inquiry, paradoxically able to pass judgment without recourse to supporting evidence. If this is true, why do we read Shakespeare? [1] Wouldn't any arbitrarily chosen text suffice, given that the text itself is irrelevant, it's the Beholder that matters? Of course, what you learn in English is that—to paraphrase George Orwell's Animal Farm—some Beholders are more equal than others. Your professors are Beholders, you as a student are but a Beholder-in-training, & art works are unimpeachable: they do not fail, they either go unmentioned or become canonical via mysterious means. Aesthetics masquerades as subjective judgment while never admitting its own folly or interrogating the social conditions that cause certain works to become canonical while others are summarily discarded.

Practicality

Doubtless there are objections that I'm conflating disparate fields. Mathematics is axiomatic logic, English is aesthetics, & the specific vein of librarianship I've mentioned is quite practical. These are library projects that failed & perhaps we cannot say a work of art or a theorem fails in any corresponding sense.

But don't give up on me so easily. Librarians are onto something here. We know that art fails. We don't purchase every book, we write harsh Goodreads reviews about books that didn't please our Beholder's eye. My earlier examples were from library technology events, events that skirt around the practice of programming if not engage it directly. & what is a failed program, or a bug in an algorithm, if not a flawed theorem? There are connections & they might even be meaningful. Otherwise I'm just way off base, a deranged squirrel collecting copper washers for the winter. I never was good at aesthetics as theory. I probably should avoid writing about it. But I'm pretty good at failing & perhaps I'll write more about that.

Footnotes

[1]^ The thing about Shakespeare: he's not a very good writer. He has flaws & they're the sort creative writing teachers spell out in red sharpie at the end of student plays: "Heavy handed." "Deus ex machina." "Did you really back yourself into such a corner that the only way out is to kill every single character for which the audience has a shred of empathy left? Please, go back to the drawing board." I'm still bitter about Shakespeare, a sole author, being a required course for my undergrad degree, which utterly ignored the entire 20th century.

Reflections on Writing JavaScript

I've been working with JavaScript for a little while now & I want to briefly share changes I've made in my coding style. These changes, while seemingly pedantic, can be very meaningful in constructing a maintainable script.

Use Anonymous Functions Sparingly

When I first started writing semi-serious JavaScript using jQuery, I was passing anonymous functions as parameters frequently. It's a pattern that's condoned by Codecademy & all the brief jQuery API examples, but it gets messy & unsustainable quickly. Throwing anonymous functions around all the time misses the entire point of functions, i.e. that they're named, reusable chunks of code. What's clearer here:

// anonymous
$.getJSON( "http://some.api.url/gimmejson", { q: "search+term" } , function ( response ) {
        var len = response.len;
        if ( len > 0 ) {
            console.log( "Well, at least it's not empty..." );
        } else {
            return "ERROR ERROR DEATH FATAL ERROR";
        }
        var dataset = [];
        for ( var i = 0; i < len; i++ ) {
            dataset.push( response.items[ i ].text );
        }
        return dataset; },
    );

// named
$.get( "http://some.api.url/gimme.json", processResponse );

Having ten lines of anonymous function pasted into a function call as a parameter is probably the least readable code pattern commonly in use. In particular, if other parameters also span multiple lines (e.g. if I pass a much larger object in the second parameter above) it is a chore to differentiate between commas that separate items within objects & arrays & the commas that separate the parameters you're passing. Debugging is also easier with named functions; you can look back through a call stack that makes sense, rather than discovering that the last function called before an error was but one of the twelve anonymous ones sprinkled throughout your code.

The one disadvantage is that it's not immediately evident that processResponse is a function; it looks like it could be any type of variable. That's why the best, most readable way to use most functions is by passing parameters in an object, which jQuery makes extensive use of:

// passed in an object
$.ajax( {
    url: "http://some.api.url/gimme?json=yesyesyes",
    dataType: "json",
    data: { q: "search+term" },
    success: processResponse,
    error: displayError
} );

This makes the role of processResponse much clearer; it's a callback function called upon a successful request. If the $.getJSON function let me pass in both a success & an error callback, I'd have to look up the function's syntax every time just to figure out which anonymous function was assigned to each. With the object parameter, their roles are doubly evident both from the name of their key as well as the name I've given the function.

&& and ||

&& and || are frequently used in assignment expressions, while intuitively they only belong inside comparison expressions. It's not something I do a lot but it's incredibly frequent in code libraries so understanding its usage is important. Basically, && and || are not merely comparison operators; they are expressions which return a value. && returns the first value if it is falsey & the second if the first is truthy; || is the opposite in that it returns the second value if the first is falsey & the first if it is truthy. You can see how this works in typical comparisons, where && is used to mean "and" & || is used to mean "or". Example:

if ( false && true ) // -> false because 1st is falsey, code won't execute
if ( false || true ) // -> true because 2nd is truthy, code will execute

We know intuitively that these make sense, because "and" usage means that both the first and the second conditions must be true while "or" usage is happy if either the first or the second is true. But what do you think this code, taken from the Google Analytics snippet, does?

var _gaq = _gaq || {};

Does it make sense to have a || outside of a conditional statement such as if? Here, || returns _gaq if _gaq is truthy (e.g. if it exists) but it will return an empty object literal if _gaq is falsey. Then, later on in my code, if I add a method or property to _gaq I've guaranteed that it exists so I won't receive a reference error. So a more verbose but less tricksy rewriting is:

if ( _gaq !== undefined ) {
    _gaq = _gaq;
} else {
    _gaq = {};
}

Writing one line as opposed to five makes sense; an if-else condition is overkill here, when we just want to check if our object already exists & initialize it as empty if not.

Spaces

Spaces are good. I like an abundance of spaces in my code. I pad array brackets, object curly braces, & parentheses wrapped around control flow expressions or function parameters with spaces. So I write

var obj = {
    nums = [ "one", 2, three ],
    funk: function ( param ) {
        if ( param.toLowerCase() === 'parliament' ) {
            return 'Give up the funk.';
        }
    }
};

instead of

var obj = {nums=["one", 2, three],
    funk:function(param){
        if (param.toLowerCase() === 'parliament') return 'Give up the funk.';
}};

One telling space is the parentheses that wrap a function's parameters. I try to always put a space in between the term function & the parameters in a function definition, while there's no space when the function is being executed.

var funk = function ( args ) { ... } // function assigned to variable
funkyFunk function ( args ) { ... } // function declaration
funk(); // function being executed.

Functions are thrown around so frequently in JavaScript that this subtle difference, if consistently enforced, can go a long ways towards helping you read whether a piece of code is being executed or defined for later use.

Switch

I generally avoid the switch statement; its syntax is weird. I find it uncharacteristic that the code blocks following "case foo" aren't wrapped in curly braces. If I had to guess how a switch statement would be done, the cases would look more like:

switch ( foo ) {
    case ( bar ) {
        doSomething();
        break;
    }
    case ( bah ) {
        doSomethingElse();
        break;
    }
}

which parallels the control flow operators. switch doesn't save much space over a series of if comparisons & carries the potential hazard of unintentional fallthrough.

++ and ?

I follow a lot of Douglas Crockford's advice, but not his avoidance of ++. I use ++ in for or while loops & it hasn't come back to bite me. Sometimes I'll use it to increment a value outside of a loop. I think I understand its usage in these limited contexts & while it isn't a huge gain in terms of saving space, it's nice to put all my loop details in one expression. I also don't think the ternary operator is worth avoiding; it's very handy during variable initialization even if it's a little opaque, much like || and &&. The ternary operator looks like:

var someVariable = ( expression ) ? "value if expression evaluates to true" : "value if expression evaluates to false";

We could rewrite the Google Analytics code:

var _gaq = ( _gaq ) ? _gaq : {};

It does the exact same thing; check to see if _gaq exists, initialize it to an empty object literal if not.

You Don't Hate JavaScript, You Hate the DOM

I, as many JavaScript programmers before me, have discovered that JavaScript is really not so bad a language. It has its peculiar errors—the extreme unreliability of typeof & the leading zero issue with parseInt come to mind—but it also has gorgeous features. In particular, the first-class nature of functions is wonderful & I can't live without it. Passing functions as parameters to other functions is mind-blowing once you realize how much you can achieve with it.

But JavaScript's biggest issue isn't the language itself, it's the way it interacts with HTML pages via the DOM. DOM manipulation is tough, the commands are verbose, & cross-browser incompatibilities abound. There's a reason why people love jQuery; it removes the pain of accessing & altering the DOM, scaffolding on top of CSS selectors that most web developers already know. The one biggest piece of advice I give to people who want to learn JavaScript is to start with jQuery. With a nice layer of abstraction, you can actually do something on a website which is amazingly gratifying. The building blocks of the language are easier to acquire when you see their utility on the web, as opposed to repeatedly printing text to the console.

Conclusion: Steps to Learning a Language

There are a few steps you go through when learning a programming language. The very first step is simply understanding what syntax is valid. Writing echo "Hello world!" will result in an error in JavaScript. The next step is understanding the advantages of specific syntax choices; knowing whether a particular situation calls for a a particular control flow operator, for instance.

The next step after that is meaningless in terms of how the code executes but of paramount importance to programmers, who tend to be human; knowing how to write clear code. Once I had the basics out of the way, I found myself having lots of opinions on what makes a piece of JavaScript understandable. Now, every time I go back & look at something I wrote previously, I find myself employing all sorts of conventions (spaces! fewer anonymous functions!) that I've discovered or come to appreciate. While much of JavaScript: The Good Parts went over my head initially, I now understand its essence; that deliberate choices when writing JavaScript can not only avoid common programming pitfalls but increase clarity.