Tanvil
Sign up

Career paths/From Library & Information Science

How to Become a Software Engineer From a Library & Information Science Background

Moving from Library & Information Science (LIS) into software engineering is a real jump, but it's less alien than it looks: LIS trains you in structured metadata, taxonomies, database systems (MARC, Dublin Core, SQL-backed catalog systems), and information retrieval logic, all of which have direct analogs in computer science. That said, you will need to build programming fluency, data structures/algorithms knowledge, and comfort with the engineering toolchain (git, testing, deployment) essentially from scratch, since an MLIS degree does not cover this even if your role included "digital libraries" or "systems librarian" work. Expect 8-14 months of consistent, structured study before you're competitive for junior roles, longer if you're doing it alongside a full-time library job.

Skills that transfer

Metadata schemas and controlled vocabularies (MARC, Dublin Core, MODS)

This is functionally the same mental model as designing database schemas, JSON structures, or API payloads — you already think in terms of fields, relationships, and normalization, which maps directly onto relational database design and data modeling in software.

Boolean logic and query construction for catalog/database searching

Years of building precise Boolean search strings for OPACs and licensed databases translates almost one-to-one into writing SQL WHERE clauses, search algorithms, and conditional logic in code.

Information architecture and taxonomy design

Organizing collections and designing findability systems is the same skill used in structuring codebases, naming conventions, and designing REST API routes so other developers can navigate them logically.

Systems thinking from working with ILS platforms (Koha, Sierra, Alma)

Having configured or troubleshot an integrated library system gives you a head start understanding how front-end interfaces, back-end databases, and third-party integrations (like discovery layers or link resolvers) connect — the same layered architecture you'll work with as an engineer.

Patience with detail-oriented, precision-dependent work

Cataloging demands exactness (one wrong subfield breaks a record); debugging code demands the same tolerance for painstaking, methodical error-tracing rather than guessing.

User-needs research (reference interviews, UX for patrons)

The reference interview skill of translating a vague patron question into a precise search strategy is the same skill needed to translate a vague product requirement into a technical spec.

The gap to close

A production programming language (e.g., Python or JavaScript)

LIS coursework may touch XML/XSLT or basic scripting, but you need real fluency writing, debugging, and reasoning about program logic in a language used for actual software products.

Work through a structured course (CS50 or The Odin Project) and build small tools first — a script to batch-clean a CSV of catalog records, or a script that auto-generates citations — projects that use your existing domain knowledge as the test case.

Data structures and algorithms

Technical interviews at most software companies test arrays, hash maps, trees, and Big-O complexity directly; nothing in an MLIS program prepares you for this, and it's often the single biggest blocker for career-changers.

After 3-4 months of programming fundamentals, spend dedicated time on a resource like NeetCode or AlgoExpert, practicing problems daily rather than passively watching solutions.

Software engineering toolchain (git, command line, testing frameworks, CI/CD)

Even a strong coder without git/version-control fluency and basic testing habits will struggle to pass technical screens or contribute to a real codebase on day one.

Use git for every practice project from the start, push to GitHub, and require yourself to write at least basic unit tests — this habit needs to be automatic before you interview.

Building and shipping a portfolio of applications (not scripts)

Employers hiring career-changers weigh demonstrated project work heavily since you lack a CS degree or prior engineering job; a resume alone won't be convincing.

Build 2-3 full applications with a front end, back end, and database — ideally solving problems from your library background (a citation manager, a shared reading-list app, a metadata-cleanup tool) since domain-specific projects also make you stand out in interviews.

Comfort with ambiguity and fast iteration vs. LIS's standards-driven pace

Cataloging and archival work rewards following established standards precisely; software teams often move fast, ship imperfect code, and iterate — a cultural adjustment that surprises many LIS transitioners.

Practice working in agile-style sprints even solo (set weekly goals, ship something imperfect, revise) and contribute to an open-source project to get used to fast-moving, less standardized collaboration.

First steps

  1. Complete a structured intro programming course (CS50 or freeCodeCamp) over 8-10 weeks, coding daily rather than just watching lectures.
  2. Build a small script that solves a real problem from your library work — e.g., de-duplicating a CSV export of catalog records or auto-formatting citations — to anchor learning in something concrete.
  3. Set up a GitHub account and push every practice project to it, even small ones, to start building a visible portfolio from week one.
  4. Join a local or virtual coding community for career-changers (e.g., a bootcamp prep group or freeCodeCamp study group) to get accountability and peer code review.
  5. After 3 months of fundamentals, start daily data-structures-and-algorithms practice on a platform like LeetCode or NeetCode, aiming for consistency over volume.
  6. Research whether a part-time bootcamp fits your timeline and budget as an accelerant, but don't wait for one to start — self-study first will make a bootcamp far more effective.

Common questions

Is my MLIS degree worthless for a software engineering job?

Not worthless, but it won't substitute for technical skills — no hiring manager will treat an MLIS as equivalent to a CS background. Its value is in the transferable thinking (metadata, systems, structured problem-solving) and in making your portfolio projects more distinctive, not in checking a technical-qualification box.

Should I go back to school for a CS degree instead of self-teaching or a bootcamp?

For most LIS transitioners, a second bachelor's isn't worth the time and cost; a rigorous self-study path or a reputable bootcamp, combined with a strong project portfolio, is generally sufficient for junior roles, especially if you leverage your library-domain projects to stand out. A CS degree matters more if you specifically want to work at companies with strict degree requirements or want to go deep into research-heavy engineering.

Can my systems librarian or digital archivist experience count as engineering experience?

It counts as relevant technical experience and should be framed that way on your resume (database administration, systems configuration, API integrations with vendors), but it won't be read as software engineering experience by itself — you'll still need demonstrated coding ability through projects or a junior role to be considered.

Library & Information ScienceSoftware Engineer

Get a personalized version of this plan, built from your actual background, with progress you can track.

Get your personalized plan
More paths to Software Engineer →More paths from Library & Information Science →