Once upon a time, I taught a course on AI in the Library in an iSchool. (Check out the reading list and syllabus, which are relevant context for this post.) I haven’t taught it for a while — I got busy with other things, and then ChatGPT dropped and immediately rendered my syllabus obsolete and I wasn’t up for overhauling it.

At least, that was why I wasn’t teaching it in 2022-2024. In 2025 and 2026, there are some pretty different reasons not to be adjunct faculty, particularly in a public university, if you don’t have to be. Like an enormous Project-2025-based, federally directed but decentralized system to dictate syllabi, destroy academic freedom, and fire professors who don’t toe the line. (Examples unfortunately abound, such as University of Oklahoma, Texas A&M, San José State University — the last of these being the university where I taught.)

And in the midst of all this, here’s the (excellent) Texas Tribune reporting on ChatGPT prompts used at Texas A&M to flag course content that might take a perspective on race and gender. And so, with a rising sense of nausea, I may as well see how my syllabus would fare in this brave new world.

First (and startlingly), the prompts only cover very high-level course metadata: course title, description, and learning objectives.¹ The week-by-week descriptions and reading list, or indeed the syllabus as a whole, aren’t covered, so these prompts don’t reach week 2’s case study of an AI metadata generation prototype in a Black photographer’s archive, or week 3 on the broad and heavily researched field of (ironically) algorithmic bias.

And so, the results:

Course Title. Unsurprisingly, “AI in the Library” raises no issues for the state of Texas (though of course chatgpt takes a great many words to be unconcerned about it).

Course Description.

This course covers what artificial intelligence is and critical analysis of AI systems, in the context of real-world library and archival AI applications. Programming skills not required.

To my surprise, chatGPT is pretty okay with this:

Review of value-neutrality

• Advocacy or ideological language:
  None identified. The description does not include prescriptive claims, affective outcomes, or ideological commitments.
• Potential neutrality concerns:
  The phrase “critical analysis of AI systems” is standard academic language and does not, on its own, imply advocacy. However, “critical” can be interpreted broadly; specifying analytical methods or perspectives can improve clarity without reducing neutrality.
• Overall assessment:
  The description is value-neutral, concise, and appropriate, though it is shorter than the requested 75–125 words and could benefit from greater methodological detail.

I was sure that “critical analysis” would get more pushback (how could we possibly want that in higher education in 2026??), but I guess mostly I’m supposed to be more unnnecessarily wordy, and I could keep waving this IYKYK flag.

Learning Outcomes.

Upon successful completion of the course, students will be able to:

1. Understand and explain the basics of AI: both its underlying principles and common machine learning techniques.
2. Discuss realistic ways that AI can be a part of library services.
3. Critically analyze potential pitfalls of AI systems, including the role of their underlying data sets and their ramifications in society.

Y’all. Despite some honestly fair ways chatgpt pointed out that these verbs are squishy and might be replaced with ones that are sharper and/or lend themselves more obviously to assessment, I absolutely slipped “critically analyze…their ramifications in society” right past it:

“Critically analyze potential pitfalls…” — This is largely value-neutral. The phrase “ramifications in society” is acceptable, though specifying analytical contexts (e.g., professional or institutional settings) would improve precision.

Again, let me reiterate that I have a case study on a Black archive. I have a reading list with, inter alia, Meredith Broussard and Catherine D’Ignazio and Safiya Noble and Virginia Eubanks. I have a reading list with Tay (aka “how to make a chatbot unbelievably racist and anti-Semitic in less than 24 hours”) and predictive policing and de-biasing word vectors and feminism and Soylent-Green-based limitations of a major AI ethical framework.

Pretty sure any antagonistic human reading learning objective number 3 there would know what I was getting at, but I guess chatgpt still can’t replace all the jobs.

1. There’s also a prompt for “course justificiation”, but I was not asked to write one of these for my syllabus. The closest it gets is a “core competencies” section aligning the course with learning objectives for the overall iSchool program. However, these objectives are govened by the iSchool, not the individual professors. Therefore I’ll be leaving the course justification prompt aside. ↩︎

Someone in a Slack I’m in asked for advice on how to understand classes in programming, and I wrote a mini-novel about how I understand them, so I figured it might as well be a blog post! Here we go —

A class is a noun. That is to say:

• it is a Specific Thing
• which I can name.

And I make a class when I have a noun that needs to know things about itself.

What do I mean by “needs to know things about itself”? I mean that this Specific Thing has associated behavior and/or data. For instance, if I’m writing a circulation system for a library, an important noun might be a Checkout.

Checkouts have data they need to know about themselves: for instance, what time was the object checked out, what object is it, when is it due back, what user ID has it. Every Checkout needs to know this kind of data about itself, but the specific values of the data will differ for each Checkout.

Similarly, Checkouts have behavior — that is, verbs that happen to this noun! For instance, a Checkout might know how to resolve itself: add a checkin timestamp, remove the user ID for privacy purposes, et cetera.

And now the sweet part: Checkouts need to know the mechanics of how to resolve themselves, but code outside of Checkouts only needs to know that Checkouts can be resolved. This makes code a lot more readable — if you give the methods on Checkout good names, then you see something like checkout.resolve() and you understand what’s happening; you don’t need to get bogged down in the details of how it happens. You can even update the mechanics of how Checkout resolution works later, and the rest of the code doesn’t need to change. Only the Checkout class itself needs to keep track of the specifics. This principle of encapsulation is fundamental to software design and makes it easier to maintain code over time.

OK, so how do I know when to write a class? I mean, at first, I usually don’t! I write some functions to handle behavior, and then over time I realize one or more of the following:

• There’s a bunch of data that tends to travel together. Maybe it wants to be different properties of one thing.
• I keep seeing functions that need more than 4 arguments. Maybe several of these arguments want to be properties of a common thing. (This is the most common way that I notice that I have a bunch of data traveling together.)
• I realize that there’s an important object or idea in my problem domain, and a big part of the cognitive work I’m doing is modeling its data and behavior, and my life will be easier if I just slap a name on that and treat it as a Specific Thing.

All of this, of course, was a learning journey I had to go on as a baby programmer. It’s easiest to get started by just writing functions that Do The Thing! That’s definitely where I got started, and it took me a while to build an actionable mental model of classes. For me, I think the first thing that got me over the cognitive hurdle was when Django introduced class-based views. I’d been working in Django but it had only had function-based views, and then I had to adapt to this new way of thinking. It was a challenge at first, but Django did such a phenomenal job of writing class-based views as repeating patterns — so the same sorts of methods tended to be exposed in different ones, and you could just grab and overwrite what you needed — that I started to understand their utility. Also, of course, the documentation was spectacular.

I also found it really helpful to watch a whole bunch of Sandi Metz’s Smalltalk-inflected Ruby conference talks. She has incredibly lucid things to say about object-oriented programming; in particular, the way she talks about message-passing really influenced how I think about writing tests, hiding vs showing information, and different objects’ scopes of responsibility. I don’t think you can go wrong with any of them, but the ones that have stuck with me are Nothing is Something, All the Little Things, and Polly Want a Message.

Happy encapsulating!

I’m updating some old code which includes a model trained under gensim 3.8.3. (Or so I hope, based on the poetry.lock file.) Current stable is 4.3.0, so…I have some updating to do. In theory I can load a 3.8.x model in 4.0.x, save it, then open that in 4.1.x, et cetera. I’d rather do that than retraining the model (which would be a festival of limited documentation, missing institutional knowledge, and additional yaks), so here I am installing gensim 3.8.3 on my 2021 M1 Mac. What could go wrong, right?

First yak: Cython

gensim depends on numpy, numpy depends on Cython, and Cython 0.29.14 (the version in my poetry.lock) is all,

AttributeError: module 'collections' has no attribute 'Iterable'

However, it turned out my version of numpy wanted a higher version of Cython:

RuntimeError: Building NumPy requires Cython >= 0.29.30, found 0.29.14 at [local directory structure]/lib/python3.8/site-packages/Cython/__init__.py

So I just tried 0.29.30 (being as conservative as possible about upgrading dependencies, since my ultimate target is an old version of gensim), and the error went away.

Second yak: numpy

Every time I try to install numpy on an M1 Mac I run into errors. I can’t even find the errors in my scrollback any more (other than the one where it couldn’t install the C bindings and pleaded for a better Cython), but if you’re reading this post, you probably know the ones. I tried Rosetta; it didn’t help.¹

I ended up with the same solution I always end up with²; to wit (modulo numpy version),

poetry run python -m pip install --no-use-pep517 --no-binary :all: numpy==1.24.2

It bothers me that I have to special-case the numpy install, because I’m always thinking about how this would look in CI/CD. But by running pip under poetry, I at least ensure that numpy ends up in the right virtualenv, and poetry is able to find it when it does dependency installation and resolution.

Boss yak: gensim

Now I have all the dependencies I need to install gensim; hooray! I verify that my model loads and saves in 3.8.3. It does. Now I install 4.0.x so that I can —

AttributeError: 'dict' object has no attribute '__NUMPY_SETUP__'

Oh. Oh dear.

This is actually a known bug that has been solved in newer versions of gensim, but that fix didn’t make it back to 4.0.x. OK. Well. I clone gensim locally, apply that patch to my version, and discover that you can poetry install a local project (this is actually an extremely sweet feature).

Now I can load my model in 4.0.x, relying on the backward compatibility guarantee, and —

  File "/path/to/local/version/gensim/models/doc2vec.py", line 328, in docvecs
    return self.dv
AttributeError: 'Doc2Vec' object has no attribute 'dv'. Did you mean: 'dm'

File "/path/to/local/version/gensim/models/keyedvectors.py", line 272, in _upconvert_old_vocab
    if 'sample_int' in self.expandos:
AttributeError: 'KeyedVectors' object has no attribute 'expandos'

  File "/path/to/local/version/gensim/models/keyedvectors.py", line 1700, in _upconvert_old_d2vkv
    self.vocab = self.doctags
  File "/path/to/local/version/gensim/models/keyedvectors.py", line 654, in vocab
    self.vocab()  # trigger above NotImplementedError
  File "/path/to/local/version/gensim/models/keyedvectors.py", line 645, in vocab
    raise AttributeError(
AttributeError: The vocab attribute was removed from KeyedVector in Gensim 4.0.0.

Oh. Oh dear.

This was actually all pretty easy to solve, given that I now had an installable version on localhost. I added a property to gensim/models/doc2vec.py:

@property
def dv(self):
    return self.__dict__['docvecs']

And a check, before trying to access self.expandos:

if not hasattr(self, 'expandos'):
    self.expandos = {}

And I replaced a line that threw a KeyError:

# del self.expandos['offset']
self.expandos.pop('offset', None)

I also commented out the line self.vocab = self.doctags in _upconvert_old_d2vkv, because the very next line calls a function which destroys self.vocab, whereas this line just triggers a NotImplementedError in attempting to reference self.vocab, which should render the assignment moot.

Next steps

I’m going to have to verify that my model actually works as expected with these changes!

I’m also going to pull together a PR patching 4.0.x, assuming the maintainers are open to it, and work is cool with my using a version of this model as a test case (I need something which triggers the bugs in order to test the patch, you know?).

Also, of course, I will glory in these clouds of yak hair I am now surrounded by.

Footnotes

1. But it let me have some fun messing around with Terminal settings. Now I have a duplicated version of Terminal.app, named Terminal_Rosetta, which is set to always open in Rosetta mode. I also gave it a different default color scheme so that I can always tell which architecture my terminal is in, because you know it would be the easiest thing in the world to end up with things not working because of weird architecture clash bugs that would take forever to track down.

I will probably never use this again.

2. Which maybe I will remember after having written a whole blog post about it? Honestly, probably not. But at least I might remember that I wrote a blog post about it and will therefore be able to find the answer faster.

I just had So Many job interviews, which means I had so many tech screens, all of which ran differently. I didn’t know what to expect going into most of them — I’ve only interviewed in the library world in the past, where many organizations don’t have tech screens at all, but some of these were industry jobs — and organizations varied in how much they explained what to expect, so I’m going to outline the varieties of tech screen I faced in hopes this will help you. All organization names are, obviously, anonymized.

The Order of the Promethean Banner

A screen (preceding any human interviews) via Triplebyte, which presented short blocks of code and asked multiple-choice questions about their outputs, flaws, et cetera. Questions were timed. Googling, documentation, REPLs, et cetera were disallowed.

I am pretty sure I went down in flames on this one. While I got to choose a language I am familiar with, the questions mostly concerned obscure edge cases and details of that language — some of which I know, some of which I have literally never used in ten years of writing software. (One of which my husband, who has been writing extremely hardcore software for thirty years, thinks he’s used once.)

But also: I don’t think it’s a fair assessment of my skills, or the job’s skills. In the real world, I actually do read documentation, or write tests, or try something out in a REPL if I’m not sure of how something works. And: the job description wasn’t for someone writing 6-line functions to exercise weird edge cases; it was for someone operating at a much more senior level where architecture and communication skills are important.

This was also, in effect, the front door to the company. I decided I didn’t want to work at a place whose opener was so hostile, and withdrew this application.

The Society of the Emerald Smiles

“Bring a piece of code you have written, or substantially contributed to, and tell us about it.”

This was great. I knew exactly what to expect in advance. My prep was limited to choosing code and finding its GitHub link, and that was short because I know off the top of my head the code I’m proudest of. I knew that code showcased — not only my skills in general — but the particular skills I wanted them to see for this position. I came in feeling confident and relaxed, because I know this code, and I know I did an excellent job with it. I got to be the expert in the room storytelling and fielding questions rather than a supplicant in an interrogation. The code was firmly grounded in the real world. We got to talk about design decisions, aesthetics, documentation, et cetera as well as syntax-level stuff. 👍

The Union of the Ancient Oak

A take-home: they added me to a private repo which contained a small but working app, and asked me to add some small and clearly-scoped features. Then in the interview we talked about the code I’d written, why I made those choices, alternative possibilities, et cetera.

I’m sensitive to concerns that take-homes unfairly privilege people with lots of spare time, but I don’t think it’s unreasonable to ask candidates to do short prep work, and this was well-scoped. (They said it should take less than three hours, and it did; quite a lot less if I recall correctly.) It used a familiar web framework and followed its conventions, so for anyone familiar with that framework (which successful candidates for this job will be) it was quite easy to get oriented to the code and figure out where the new features might go. The code came with tests (not all of which worked — a nice way to check that your candidates actually run the tests — all of which were simple to fix). Writing the code here was not hard but it was realistic. The sample data had a sense of humor, which was fun, and made their company culture look good.

As with the previous format, this meant that I got to come into the interview with code I was familiar with and could talk about from a position of expertise, which meant I felt confident. Not coincidentally, in both of these interviews, I got strong positive feedback about my code — because both of them had set me up for success, made it easy for me to show them my best work.

The League of the Ghostly Well

Another take-home, this one strictly timed to 90 minutes (solidly within my “reasonable to expect of a candidate” realm). Two parts: one writing up a feature proposal; one doing code review. In other words, this one is striking for involving no actual coding! But above the junior level these skills of design, communication, and mentorship are more important, and this exercise seemed well-scoped to capture those skills. At the same time, it did draw on my syntax-level knowledge due to the utter haplessness of the code I was reviewing 😂

I did feel some breathlessness from the time pressure (while simultaneously appreciating that the organization was being respectful of people who have less available time). But as with the preceding, the format meant that I got to the subsequent human interview with code that I was familiar with and could discuss from a position of some confidence. The interviewers were also totally aware that in the real world they would have needed more time to do their best work on these prompts, so they didn’t expect me to be perfect. It left room for conversations about alternatives I would have considered with more time, which is a good sort of thing to talk about in an interview.

The Guild of the Radiant Visage

We had a video call via Hackerrank. They sent me a link to a Hackerrank sandbox first so that I could get familiar with the platform, which was a hospitable touch. It’s quite nice, actually; in-browser coding with input, output, REPL, editor; nice syntax coloring, tab completion, the stuff I do subconsciously while typing works more or less as I expect, the editor has vim and emacs modes too if you’re into that sort of thing.

I was worried this might be like Triplebyte, but no; they presented me with a description of a function they wanted to implement. This function was a simplified version of something they encounter in their day-to-day work, and they took the time to explain the context. The description included sample input and expected output.

I found it extremely nerve-wracking to do live coding, but they were nice about both stepping back when I needed space to think, and throwing me some lifelines. In the end I missed one edge case and was totally kicking myself about that (it’s absolutely the sort of thing I would have caught in a calmer situation) and sure I’d tanked it. But my husband (who does a lot of interviewing for his company) said that the fact that I finished with time to spare was a good sign and that in his standard interview problem (a code review), people who get 40% of the available bugs get a thumbs-up from him. Whew. And as it turns out I did get an offer from this organization, so apparently you really don’t have to be perfect!

Hope this helps, people of the internet. Good luck in your interviews.

I read this article¹ and was moved to furious tweetstorm and several respondents asked that I make it into a blog post. This is that post.

Let’s dissect this quote, “They tired of care-taking, even though this involved little more than continuing to host the project files on a server.”

Firstly, it did not involve just continuing to host the files on a server. That server needs to get upgrades to stay secure and to be a solid foundation for future software development. Those upgrades may in turn mean the files must be upgraded to remain usable. Those server upgrades are themselves labor. Ensuring that the web server configuration and file permissions remain in a state where your files can be served is labor.²

If there are enough people who want to host “just a few files”, it’s a lot of labor. And server costs add up. The PHP or ruby or whatever programming language your dynamic files run on, that needs to be upgraded too. And again, this may necessitate maintenance so your files remain usable.

You probably have a database backing the system. Guess what, that needs maintenance too.

Upgrading those files to maintain compatibility is probably less than a week of work, assuming that the files come with documentation about how to deploy them and a test suite to make sure the upgrades don’t break key features.

Guess what?

If the team writing your “project files on a server” didn’t include software engineers, your files bloody well do not come with documentation and a test suite.

Given that the article includes neither the word “software” nor the word “engineering”, I know my hypothesis on this one.

(That AND the fact that when the author talks about tech work, she mostly talks about delegating it to part-time undergrads and the occasional solo grad student. These people may know how to code, but the chance they know engineering is near-zero.³ And even if they DO know engineering, their ability to practice it effectively, and stay up-to-date, as a solo practitioner is deeply limited.⁴)

OK but let’s back up a bit. I said, best case (remember: this is not the best case), that maintenance is probably under a week of work. Say, yearly.

If you have 30 faculty members who want to host “just a few files”, someone’s doing that full-time for 2-7 months a year.

I actually enjoy doing maintenance work — to a point. Most software engineers don’t. Necessary, but not fun. You ask people to spend too high a percentage of their time on maintenance, they hate their jobs, and they quit.

Also they stop having time for new feature development! Which, in addition to being more fun, is actually the thing that brings grant money in,⁵ and a thing that stakeholders are constantly clamoring for. Is anyone going to hire another FTE to keep up? Nah.

Alternatively, they look the other way, letting “just a few files” languish unmaintained, and if they are any good they KNOW in their hearts the bitrot, the attack surface. They work in a place that doesn’t value quality and if they’re any good it eats them.

I used to fantasize about being able to sunset things. I inventoried every “just a few files” on a whole set of servers. There were 243 of them. There were, at most, 6 of us. We couldn’t kill them. Because faculty like this might complain.

Some of them were critical services. Most of them were running on obsolete versions of whatever they ran on. We didn’t have business owners, documentation, tests. No principled way to transition or upgrade them. No SLAs giving us permission to kill them in 5 years.

“Just a few files.”

TWO HUNDRED FORTY THREE PROJECTS. SIX OF US.

If you want to talk sustainability for software projects — first, talk to an actual software engineer. Maintainability is part of their expertise.

And second, the labor conditions of your techies’ work lives are an important part of that plan. If your plan rests on making their jobs suck, it is not a sustainable plan. Or one that anyone should feel good about.

Thank you for coming to my TED talk.

Footnotes

[1] “Sustainability and complexity: Knowledge and authority in the digital humanities.”
Johanna Drucker. Digital Scholarship in the Humanities, Volume 36, Issue Supplement_2, October 2021, Pages ii86–ii94, https://doi.org/10.1093/llc/fqab025.

[2] For example, the actual months, on and off, I spent trying to deal with five years’ worth of deferred maintenance coming due at once on one of my personal projects. I was able to wait that long to touch it because my code had good tests and the deployment system had been set up responsibly by the very capable Andy Dorner…but the result was, when I couldn’t avoid doing maintenance any more, 1) everything was broken, and 2) I was dealing with a system I wasn’t super familiar with, because I hadn’t been the one who set it up, and Andy and I were no longer coworkers, so I had limited access to his expertise.

[3] I say this with tremendous respect for graduate students. I teach them, and some of them have been brilliant, hardworking people whose work has already had, and will continue to have, significant impact beyond the classroom. Nonetheless, the difference between writing code and doing engineering is significant. Just as having read Romeo and Juliet (however insightfully!) does not mean you can stage a Broadway production, knowing how to write scripts that achieve particular tasks does not mean you know how to make those scripts usable by others, flexible around changing requirements, easy to debug, or performant under increased load. Nor does it mean that you can document them clearly, figure out where and how to deploy them, automate that deployment system, write effective tests, or work with others. These are skills people generally develop through experience, by working as part of a community of practice on large, shared projects over time. Research code — code written in the course of academic work, for the sake of prototyping something or generating data for a paper — often does not have these characteristics. Indeed, some of the worst code I and my colleagues have encountered has been written by people with Ph.D.s in computer science. They may well be brilliant in their areas of research, but computer science and software engineering are very different. Just as my professional experience has given me little formal background about algorithms and I couldn’t write a proof involving big O notation to save my life, academic training rarely provides the type of experience needed to develop engineering skills.

[4] Truly, I cannot emphasize enough how much the community of practice matters here. The critical habits of mind — things like “writing tests is important” — all come from being embedded in a culture that values them. The techniques and tools for carrying out these habits of mind come from coworkers, conferences, techie Slacks, blog posts, hallway conversations. The ability to keep up with those techniques and tools as they change, doubly so. Asking a software practitioner to work solo inherently undermines their skills. If you support a team that, for whatever reasons of budgetary reality, has only one such person, I implore you to budget for them to attend conferences regularly, and to make time for them to participate in a professional community via conferences, local meetups, and/or open-source participation; this is the most effective professional development you can do, and will also be good for their mental health.

[5] This is a problem that funders are starting to grapple with, typically under the framing of sustainability. I know Mellon has this on its radar, for example, and I want to gratefully recognize this trend. That said, there are also real down sides to funding operations on soft money (see, e.g., “sustainability” here, or the Collective Responsibility white paper on contingent labor in libraries, archives, and museums). Ultimately, good technology work rests in the institution having both a commitment to employ adequate labor to sustain core services, and a funding model to pay that labor.