One Letter for Subject Codes?

Interesting question... I think it's mostly about consistency, and not needing to remember which subjects are two letters and which are three. Not to mention just providing enough letter combinations to cover all current and future subjects.

There are some two-letter subject codes Katharina sees frequently: AD (Adult books), YA (Young adult), MN (Male narrator), FN (Female narrator), GN (Group narration), NF and FI (nonfiction and fiction).

I'll point out that those are all more audience notes than actual subjects, which could make it easier to remember that they're a "non-standard" length. But there shouldn't be any programmatic reason you can't use shorter (or longer) subject codes for actual subjects (like Domestic Fiction). None of the subject mapping for incoming MARC records relies on subject codes, only the descriptions.

That said, I'm not sure that shorter subject codes (especially one-letter ones) will really save time in the end. Adding a subject on the title-bib is certainly faster with a one letter code but the chance of typos increases too--entering a W instead of an M will add a completely different subject, while entering WYS instead of MYS is unlikely to accidentally match another subject.

Meanwhile, the subject lookup window (used for tasks like adding a preference to a patron or changing a heading from a query set) sorts by the full desc and not the code. When the code is MYS, entering that will get you mysteries in the lookup... but if the code is M, you'll get male narrator, mathematics, medicine, and any other subjects starting with M and ahead of mysteries alphabetically.

In short, you shouldn't break anything by shortening subject codes, but what helps you could make things take longer for someone else, and those who don't live and breathe subject cataloging are probably better served with a good cheat sheet than with changing codes.

If you (or someone reading this) does decide to change a few codes, remember to first sort your Headings Maintenance by code and triple-check that something else isn't already using the new code you have in mind. I'd also encourage you to loop us in, just in case.