The Curse of Knowledge and Knowledge Rankism in the Classroom

The "curse of knowledge" describes an unfortunate side-effect of acquiring knowledge and expertise: your ability to teach others about what you know is hindered by your inability to remember what it was like not to possess that knowledge.

In fact, it is nearly impossible for the expert to imagine the mindset of a beginner. Which is why horrible teachers and communicators abound.

A person in possession of full knowledge of a subject sees the entire landscape of his understanding. But he can rarely pass on that understanding in a consistently effective way using simple, jargon-free language that anticipates the inevitable problems that beginners will experience.

The curse of knowledge can afflict individuals and entire organizations. How else to explain multi-billion dollar corporations that release user manuals that are poorly written and rammed full of assumptions? Poor documentation for products costs companies countless millions of dollars in customer support every year and results in customers seeing those products in a negative light. When a customer looks at a user manual that is confusing, he immediately assumes that the product is confusing as well.

The Tune is Already Playing in Your Head

In the book Made to Stick, the authors describe a psychology experiment that perfectly illustrates the curse of knowledge. In the experiment, participants were assigned as either "tappers" or "listeners." The tappers were given a list of well-known songs and asked to tap out the song on the edge of a table using only their fingers.

The listeners were asked to guess what songs were being tapped. The tappers predicted that the listeners would easily be able to name the songs that were being tapped. But in most cases, not surprisingly, the listeners couldn't correctly indicate what songs were being tapped.

This demonstrates another important characteristic of the curse of knowledge: we overestimate our ability to pass on information in an effective way. We gloss over ideas we think are simplistic but really aren't. We want to get to what we feel is the meat of the subject—that which actually interests us most, as relative experts—long after we have mastered the basics which are still a mystery to beginners.

So this experiment is a perfect example of the curse of knowledge and highlights its two main features: 1) we can't empathize with beginners when we are experts, and 2) we assume that our expertise in a subject somehow imbues us with an innate ability to teach others about that subject.

The experiment also provides a perfect tag line that sums up the curse of knowledge and can be a strong reminder of it when you are in a teaching situation: remember that the tune is already playing in your head.

The Curse of Knowledge Has a Sister

Inherent in the curse of knowledge is another closely related concept: rankism. The list of things that humans use to compare themselves favourably to others is exhaustive: income, appearance, education level, choice of products, which sports team they support, musical tastes and on and on.

In fact, I challenge you to go through a single day with this idea in mind and marvel at just how many utterances contain some form of rankism. It's inescapable. And I don't mean to suggest that this is some sinister habit—though often it can be in its most extreme form.

Having knowledge that others don't have is one of the  most common ways that people use to elevate themselves. Am I suggesting that a teacher in the classroom can actually feel a sense of superiority over his students for understanding material that his students can't instantly grasp? Yes, absolutely!

I do believe that this "knowledge rankism" negatively affects many teachers. In one of the most cringe-worthy spectacles I have ever witnessed, a young woman conducting a teaching demonstration unloaded on one of her fellow classmates (he was one of the "students" for the purpose of the demonstration) for daring not to instantly understand a point she was trying to make. She eventually raised her voice and said, "how can you not understand this?"

Usually it not as brazen as that, but knowledge rankism in the classroom can take other forms. Many times it will come to the surface in body language or facial expressions that say, "how can you be so stupid?" Often, teachers favour students who pick up on new information faster. Recognizing different levels of students is normal, and better students can help to facilitate learning for weaker students. But when this two-tiered treatment is obvious to students, it can be toxic.

Extreme Knowledge Rankism

If there is some kind of viscerally positive feeling that people get from having one up on others through superior knowledge, does this suggest that a teacher would try to maintain that state of affairs by sabotaging the learning process? No—regardless of how this often subconscious behaviour affects a teacher, to take things to such an extreme would suggest a psychopath or at least someone who doesn't want to remain a teacher much longer.

Of course, the best teachers, whether or not they are conscious of these notions, instinctively engage in just the opposite kinds of behaviour.

How to Avoid the Curse of Knowledge

One way to avoid the curse of knowledge and knowledge rankism in the classroom is to give the appropriate amount of time to all topics, even ones you may have previously classified as "easy" or "simple." In fact, avoid designators like that altogether.

When a student hears that something is easy but subsequently has trouble with it, her confidence can be negatively affected. She sees others catching on quickly and starts to question her own learning ability. If this happens to her often enough, the mere mention of a supposedly simple idea can make her brace for the worst.

The curse of knowledge and knowledge rankism can combine to create a frustrating and unproductive situation in the classroom. Being aware of them can help you to analyze your actions while teaching, better structure your lessons, and empathize with students.

More About the Curse of Knowledge

I also write about the curse of knowledge here.

Technical Writer Job Interviews: How to Prepare, and Common Questions

When you are in a job interview for a technical writing position, there are a few questions that the interviewer is almost certain to ask.

In fact, if the question that I discuss in this post does not come up, you can use that as part of a litmus test towards determining if the organization is really serious about technical writing. And if they are not serious, you definitely want to think about if you really want to work for them.

The Most Common Question in a Job Interview for a Technical Writer

The most common in-depth question that you will face in an interview for a technical writer job is:

Can you explain the lifecycle of a technical document? (This process is also known as the documentation development life cycle or DDLC.)

The following is a detailed answer that you can provide to this question.

(Note: Some of the details I provide with regard to this question are based on the assumption that you are writing a user manual in particular. So if you plan on using the information included in this post, you may want to mention this in your interview before you answer the question. If you are interviewing for a technical writing job where writing user manuals is not going to be a main part of your job duties, alter your answer accordingly.)

Project Start-up: Create the Project Plan

The project plan for the document you are creating occupies a place within the greater project plan for the product that is being released. Make sure that you do not confuse the two. This is the first stage of the document lifecycle. Within this stage, a number of tasks could take place, and a number of decisions could be made.

First, you must know what product you are writing about (this may seem like a foolish point to make, but in this case, state the obvious).

Second, establish what deliverables the documentation team will be producing. This could include, but not be limited to, user manual, help files, and white paper. With each deliverable, the purpose will usually be clear: to inform, instruct or persuade.

Third, audience analysis: discuss who will be the main audience. For example, what is the average age of your expected audience, their educational background, and their level of technical expertise as it relates to the product? 

Fourth, you will decide which tasks are assigned to each person on the documentation team. This will also entail establishing timelines for the first draft, edits, second draft, and final draft.

Research/Gather Information

First, if this is a subsequent version of a software product, look at the pre-existing user manual. Second, arrange necessary interviews with subject matter experts. These interviews may take place with developers, the product manager, the marketing department and testers (more information on planning for and conducting an interview with subject matter experts in a future post). Third, and probably most importantly, use the product yourself.

In this stage, you may also want to read the proposal for the product and any brochures or other marketing material that exists.

Create the Document Plan

(Note: do not confuse this with the project plan.) You will create a document plan for every deliverable that your team agreed to produce during the project planning stage. Essentially, a document plan is an outline that you can write as a table of contents (though the exact wording will no doubt change when you write the actual table of contents for the document).

I include in this stage: Design the Structure of the Document, as it is very closely related. In many cases, you will be using existing templates. However, there are numerous formatting considerations, such as how many levels of information you want to include in each section, and where to place notes, tips, warnings, and other related information.

Create a Style Sheet

This is a hugely important step, and shows the company you are interviewing with that you know what it takes to produce consistent, quality documentation. Most organizations will likely have a company style guide and will probably also defer to a larger style manual (such as The Chicago Manual of Style). I won't go into details regarding style guides and style sheets at the moment, but ensure that you are familiar with the logic behind using a style guide and style sheet, and know what different aspects of a document would be included in a style sheet.

Write the First Draft

At this point you start writing. You start filling in the outline with the information that you gathered during the research stage. You do not get hung up with gaps that you detect in the information that you have collected though you should note the relevant places where you are missing details. The goal at this stage is to get the information down. You may want to throw in a few comments here about how you set personal deadlines for yourself and get the work accomplished in a timely manner. The inability to produce is something that plagues writers of all types, and technical writers are no exception.

Perform the Technical Review/Edit

At this stage, someone who is familiar with the product will review the document to ensure that it is technically accurate. If there is not a dedicated editor, prepare a review sheet with space to fill in the reviewer's name, and the date and the time of the edit.

Implement Recommended Changes and Write the Second Draft

You now implement the changes provided to you by the person who reviewed your document. There may be a further round of subject matter experts to fill in gaps in the document. After you finish writing the body of the document, you will then write the table of contents and other front matter material, and the index and other material that goes at the end of the document (such as glossaries).

Perform a Usability Test on the Document

Now, if you have the time, performing a usability test on the document itself, is something that can help you catch any problematic language or gaps in the document. Mention usability tests in the interview only if you are familiar with how to prepare for and conduct a usability test.

Perform Final Edits

First, you should perform a self-edit on your document based on your style sheet and a related checklist which you use to confirm the consistency of the document. Just a quick  note on the checklist that you use: it will address issues such as format and structure of the document, terminology related to the software (i.e., when a specific button or part of the user-interface is referenced, it is always referenced in the same way), style, and grammar.

Next, the copyedits will take place, followed by a proofread, and then the final sign-off by whomever is responsible (lead technical writer, in-house editor, or product manager; different organizations are different in this regard). The legal department will then take a look at the document as well.

Then, the document will be sent to the graphics department so that they can lay out the document, and add screen shots and other visual components that may be necessary (Note: in many smaller organizations, this may be something that the technical writer could be responsible for.)

One last check should take place to ensure that no errors have been introduced by the graphics department (a very, very real possibility, if not likelihood!).

Send Document for Printing

Finally, the document is sent for printing, or if the document is only to be in digital form, it is generated. When the product is shipped, there could be last minute updates included as inserts with the printed document and/or as .txt files included in the digital release of the document.

Summary: The Lifecycle of a Technical Document

A summary of the above steps:

—Project start-up: create project plan for the document
—Research and gather information
—Create the document plan (outline)
—Create a style sheet
—Write the first draft
—Perform the technical review/edit
—Implement recommended changes
—Write second draft of document
—Conduct usability test on document
—Perform final edits
—Send to graphics department
—Final check
—Send document for printing

Two very important qualifiers to keep in mind when you prepare for this likely question at a job interview for a technical writer:

—Do not confuse this with a question about the lifecycle of a document in an agile development environment. Some significant differences exist.

—Do not confuse this with a question about the lifecycle of a software product and how and where the writing of the user manual fits within that process. A related but different question (and one that I may cover here later)!

Finally, remember that this is a very idealized version of what really takes place when a document is being created. In the real world, changes to the product, changing deadlines, staff shortages and any number of other unexpected occurrences can result in a slightly different process, or steps being omitted. However, if you are familiar with the process, especially for those with little or no experience, it at least demonstrates to the organization you are interviewing with that you know the importance of planning and organization (often, skills that are almost as important as your writing ability).

Good luck in your job interview!

Firefox: Create a Desktop Shortcut for a Website Address

This post provides instructions on how to create a desktop shortcut for a website link that will open in Mozilla Firefox.

For PCs with Windows XP and Firefox version 3.5 or higher.

The instructions contain two tasks:

—How to make Firefox your default browser
—How to create an internet shortcut on your desktop that will open in Firefox

To make Firefox your default browser:

1. Open Firefox.

2. Click Tools, and then click Options.

3. In the Options dialog box that appears, click the Advanced tab.

4. Under System Defaults, click Check Now.

If Firefox is already your default browser, proceed to the second task in this post.

5. In the Default Browser dialog box, click Yes.

6. Click OK.

Firefox is now your default browser.

Warning: If Firefox is not your default browser, any website shortcut you add to your desktop will open in the browser that is your default (likely Microsoft Internet Explorer).

Next, we will add an internet address shortcut to your desktop that, when clicked, will open in Firefox.

To create an internet shortcut on your desktop that will open in Firefox:

1. In Firefox, open the website page for which you want to create the desktop shortcut.

2. In the upper right corner of Firefox, click the Restore Down button to reduce the browser window so that you can see both the website page and your desktop.

Note: You can perform these instructions with multiple tabs open in Firefox.

3. To the left of the browser address bar, click and drag the website favicon onto your desktop.

You will see a faded copy of the favicon plus a rectangle with a dashed border and your cursor.

Note: The website page you want to create a shortcut for may not have a custom favicon. Regardless, it will at least have an image of a blank piece of paper with its upper right corner turned down. Click and drag that image and you will get the same results.

Warning: Ensure that you are not clicking and dragging the favicon that appears next to the browser tab. If you do this, you will not create a shortcut on your desktop but will instead disconnect the tab so that it opens in a separate window.

4. Release your mouse button on your desktop.

You will see the new shortcut on your desktop.

Renting an Apartment in Bangkok: Advice for Expats

Bangkok is probably one of the easiest places for expats to find apartments to rent. From concrete boxes in the 5000 baht per month range, all the way up to 25, 000 baht and above for serviced, luxury apartments, there is something for every budget and requirement.

This is not a comprehensive guide on how to rent an apartment in Bangkok, nor does it include everything to look out for. Rather, it discusses only one aspect of renting an apartment in Bangkok: the available internet options at an apartment that you may be interested in renting.

Find Out About Available Internet Options

When talking to a potential landlord in Bangkok you can ask one question that will tell you a great deal about the place: If I move in here, can I arrange an internet connection directly with one of the internet service providers in Bangkok (namely True, TOT or 3bb)?

If the answer is no, I strongly advise you not to rent there. Here's why.

If you are unable to arrange an internet connection directly with a service provider, the only probable option is for you to buy a monthly internet card from the apartment building. They will have set up an arrangement through a third party organization. And while that third party no doubt has a deal with one of the major internet providers for the actual internet service, the quality of the wireless connection (and it will only be wireless) will be poor. Sure, you may get some periods where the connection is OK. But at peak periods when everyone in the building is online, the connection will slow to a crawl.

In addition, when the down times occur, you will receive no help from the apartment building. You will be told to phone the third party provider. And guess what they will say? "Try again later."

Not only that, but in all likelihood, you will not be able to access many sites that may be of interest to you, such as torrent sites. The torrent sites as well as the software needed to download the files from the torrents, will be blocked because they are a drag on bandwidth. If you spend a great deal of time online, this could become a very frustrating experience for you.

Finally, when only the in-house internet option is available, it is often an indication of the kind of building in which you could be living. Some apartments in Bangkok are poorly designed and/or attract a certain kind of resident for whatever reason.

Avoid Apartments that Double as Hotels

This could result in low occupancy rates and as a way to make up for this, the building may almost operate as a hotel, with people being able to rent for a few nights, weeks, or months at a time. In this case, the in-house internet option serves those people well. But it also means that the feel of the place will not be as pleasant as it could be for those who want to sign year-long leases. It will also probably mean more noise, because short-timers just don't care nor do they have any sense of the apartment being their home.

It is important to note that some buildings will allow you to set up a connection directly with one of the internet providers as well as having the option of buying an internet card to use with the in-house connection. Fair enough. The monthly card may suit some people. But if that is the only option, steer clear!

I urge you to ask numerous times about this so there is no possibility for the landlord or building owner to later say that he misunderstood. A shameless crook may simply say that, in fact, the connection is with one of the major service providers. The key is that you are able to set-up the connection with them directly, and then pay them directly, and interact with them directly regarding any service issues.

Good luck in your hunt for an apartment in Bangkok!