Igor Ljubuncic's article 5 cool Notepad++ tricks gives you some reasons why you might want to switch from plain old Notepad.

Also it's free.

In discussing what a manager can do, faced with this situation, he quotes President Harry Truman:

It is amazing what you can accomplish if you do not care who gets the credit.

10 useful tips from Chris Sullivan, Director of Technical Communication and Social Media at AVST

http://www.bluemangolearning.com/blog/2010/05/who-should-write-your-software-documentation-not-tech-pubs/

I feel like I could have written this myself!

I'm not sure I'm sold on Agilewords. How's it better than all the countless other ways of doing shared documents? How's it better for reviewing than Acrobat Pro?

But these tips are worth a look.

Make Radio | This American Life

Technically Speaking » Review of MadCap Flare V6

Particularly worth checking out is multi-topic in XEdit.

James Shore: The Art of Agile Development: "Done Done".

Great Technical Writing: Banish These Two Attitudes.

Rahul Prabhakar writes:

Koreans place a lot of emphasis on title; it could be said that nowhere in East Asia does title hold more prominence than in Korea. Try addressing a Korean colleague of the same age group but higher designation with his name, and chances are you'll be asked to prefix a title. If you don't use a title to address someone higher in the value chain, Koreans are likely to consider you disrespectful or discourteous.
If the distance between top- and bottom-level organizational hierarchies is wide, technical communicators should resort to formal communication. If the culture encourages a flat organization, the communication automatically becomes less formal. In order to succeed in a Korean company, you must consider the hierarchy between you and the final decision maker. Allow everybody in the middle to give their opinion and be included as much as possible.

...

Korean companies don't understand why technical communication is important. For them, it's always an afterthought or an additional burden.

It incredibly thorough and not something I'd send out to developers, product managers etc when asking them to review documentation, but it's a very useful reminder for tech writers conducting peer review of a fellow writer's work.

A fascinating Flare tip on how to steer users towards the help they're looking for more effectively in context-sensitive help.

Alan J. Porter writes: 
If you go around say “I’m only a tech writer,” or “publications never gets any respect,” then people will believe you and act accordingly. Be aware of what you do, what you can offer and be proud of it. Treat your team (even if it’s only you) as if it was your own business. Build brand awareness, market and promote what you have to offer, and sell yourself, your team and the profession.

The anonymous blogger at kungfuwit.wordpress.com describes how to use the SHJS (Syntax Highlighting for JavaScript) resources to make code snippets easier to digest, and easier on the eye.

My documentation rarely ever contains code, but it's the kind of thing that may come in useful one of these days.

Note: He/she says this doesn't work in WebHelp - only for .chm - but there's a workaround I'll blog myself when I get some time.

Mike Hughes questions the value of preparing PDF manual for people to read on screen. My experience is that there is still a lot of pressure on us to produce print-formatted manuals, even if they rarely get printed. Hughes writes:

“Users want hard copy. So, we should give them hard copy.” “Too expensive” is the rationale, “Users won’t pay for hardcopy.” Then, the real truth is users don’t value hard copy.

I stumbled upon this and - as someone who has to write sober, humourless procedural steps - I found it a lot of fun. For example, step 23:

Pick up one of the cut-off nuts. Seconds later, drop it because it is hot like the sun. When you leave the bathroom to get some ice to put on your burn, tell your significant other that you touched it “by accident”.