One thing that programmers are very comfortable with is a project. We tend to instinctively break things down into project-sized units: features, side-projects, commits, deliverables, and so on. This is actually one of the powerful things about programmatic thinking. Projectifying finds a potent expression in code. But in some ways is also quite distinct: we write code, but we also make projects.

We share this enthusiasm with project managers. As you might expect, project managers are also very project-oriented, and they have a great deal of codified knowledge about how to run successful projects. In practice, this often dovetails with programmers’ work quite productively.

There is decidedly a politics to this. By defining what is and is not a project, or what is or is not a constructive workflow, project managers and programmers are shaping what is allowable and what is not. This, itself, is politics. Despite rhetorical attempts by project managers to develop purportedly neutral and universal workflows, discussions of projects are nonetheless always situated in the politics of projectification. What is a project is a question about the broader ways we organize modern work.

Anyhow, there is an art to defining a codeable project. It has to be acheiveable. It has to be decomposable into constitutive smaller-scale projects. It should serve a purpose. Scaffolding a programming project is a learned skill. When we begin our programming journey, we may think of a project as “a website” or some such. But this is just a starting point. Our projectifying instincts are honed through breaking down problems, but also through our negotiations with the politics and methodologies of modern, projectified work.

To bring this back to the librarians’ vibe coding workshop, we are negotiating, in our own way, what librarians are contributing to the projectification of our discipline. We are determining what is or is not a library project, and also what roles librarians are playing in building those projects. Are we writing code? Are we telling Claude what to code? Are these real projects or just toys? Can we build something significant ourselves, without an outside vendor? These are important questions, and they hinge around what is or is not a library “project”.