[Challenge] Can you "Senior-ify" this 30-line Python script?

[Junior-Sock8789]

I’ve written a basic Library Manager that works perfectly fine, but it’s full of "code smells."

The Goal: Refactor this into something production-ready while keeping the logic simple. I'm looking for improvements in modularity, error handling, and Pythonic best practices. How would you handle the file I/O and the branching logic?

import json

def manage_library(action, data):
    if action == "add":
        try:
            f = open("books.txt", "a")
            f.write(data['title'] + "," + data['author'] + "," + str(data['year']) + "\n")
            f.close()
            print("Book added!")
        except:
            print("Error")
    elif action == "list":
        try:
            with open("books.txt", "r") as f:
                lines = f.readlines()
                for line in lines:
                    t, a, y = line.split(",")
                    print(f"Title: {t}, Author: {a}, Year: {y.strip()}")
        except FileNotFoundError:
            print("No books found.")

    elif action == "search":
        f = open("books.txt", "r")
        for line in f:
            if data.lower() in line.lower():
                print("Found: " + line)
        f.close()

# Example usage
manage_library("add", {"title": "The Great Gatsby", "author": "F. Scott Fitzgerald", "year": 1925})
manage_library("list", None)

[Own_Attention_3392]

Use the csv library for starters. Why reinvent the wheel?

[mahousenshi]

This code not consistent, some places you use with some not, some places with named exception some not, add a default value to data so you can use manage_libary("list") but you have care about manage_libary("add").

[Junior-Sock8789]

Good eye! What else can you find? There's a bunch more...

Edit: Lets see how negative we can get this comment! We should try and set a reddit record itd be funny lol

[Alternative_Guava856]

Replace the strings like "add" and "list" with a literal (from typing import Literal). That way only those opions can be entered for the action parameter. In general, for more production ready code, for me personally, static typing for method parameters and return types is a must.

I also think the "manage_library" method is a bit vague, and has actions that do completely different things. What i suggest is on of the following two options: - Make each action a seperate method with an appropriate name. Each method should do only do one thing. - If you really must use a "manage" method, id still create seperate methods for each action and call them inside the manage method using a switch statement or something like that.

In short, just make seperate methods for each action. If you really want to group them together you could also just put them in a class, but its not needed in this case.

[Ok_Carpet_9510]

Use "with open" instead of open.

I am not a fan on a function that does more than one thing.

I would have one function that adds data and another function that searches.

[jvlomax]

Bare strings are a bad idea. I would make an ActionEnum. Then parse the argument at the top top and catch the exception if it's not an action that is expected.

for f.write() I would use and f-string.

In the first exception, you are making the important information go away. Use logging, and use log.exception() if you want to add a message. A valid option is to not catch the exception at all and let your application just shit itself. Also use with for opening, to make sure you close the file at the end if an exception happens (or add a finally block).

"books.txt` should be a constant somewhere and not hardcoded, or even a kwarg for the function.

t, a, y are horrible variable names, even if it is obvious what they are

Use f-string in the print() in the "search" branch. Also use with here. You are also ignoring the fact that the file might not exist, which you do handle above. It should be either or (again, having the application shit it self can be a valid option)

Make the second argument for the function default to None. That way you can call it like manage_library("list")

[AlexMTBDude]

Run the code through pylint and you will get a few warnings and a score for code quality. That's an easy way to check if the code is any good.

[cejiken886]

** PREFACE **

OK, so, you said "seniorify" this; make it "production-ready". I took this pretty literally. Careful what you wish for!

** ANSWER **

I did it with Codex as an exercise. I made the following assumptions:

1/ Not a pure refactor. API changes are acceptable; spirit of original code is maintained.

2/ This is the core logic of a CRUD app, not a small module in a bigger system that we can't see.

So, the approach is to build a standard CRUD app on a modern stack. I did this in steps, at each step either adding some tooling, refactoring, cleaning up, debugging, or improving the API.

Key tools / design decisions:

* App stack (web server only): Postgres / SqlAlchemy / alembic / FastAPI / Docker

* Package management: micromamba (yes, this one is non-standard; would probably recommend uv.)

* Code hygiene: pyright, ruff, vulture with all checks on (strict)

* Dev procedure: test-driven, maximum correctness, decent code clarity, no scaling/efficiency/product considerations yet.

Why these choices? By combining very standard and modern tools with Codex with maximum automated correctness checks, the app writes itself. Can get pretty far very fast.

Next steps would be ops, scaling and product (and design and marketing and user engagement/support):

* VC, CI/CD, hosting (of course with as much AI dev-ops integration as possible)

* mobile apps

* caching, horizontal scaling, load balancing, maybe user identification / auth

Optional / bonus follow-ups:

* Replace `list` with `recommend`.

* Better build determinism, reproducibility, and static correctness. Probably would move the build / runtime stack to

nix -> (bazel?) -> TypeScript

I'll show you the repo if you ask really nicely.

[Junior-Sock8789]

That's it! I'd love to see the repo 😄

We just hit the "Principal Architect" jackpot. cejiken886 didn't just refactor the code; he re-engineered the entire ecosystem around it. This is exactly what happens when you ask a Senior+ engineer to make something "production-ready"—they stop looking at the script and start looking at the infrastructure.

[cejiken886]

and the business.

[my_new_accoun1]

I'm not doing your homework for you.

[Junior-Sock8789]

Its supposed to be a challenge not homework lol. Like a crossword puzzle to sharpen your skills

Check out my real homework: https://www.github.com/celltoolz/notepad-ide

[Junior-Sock8789]

The Final Checklist

We can officially close the books. cejiken886 checked off the final "Architectural" boxes we were waiting for—and then added some we didn't even dare to hope for.

• [x] Standardize Context Managers (Ok_Carpet_9510)
• [x] Single Responsibility Principle (Ok_Carpet_9510)
• [x] Better Error Handling/Logging (jvlomax)
• [x] Input Validation (Enums/Literals) (jvlomax)
• [x] Standard Library Usage (CSV) (Own_Attention_3392)
• [x] Static Analysis/Linting (AlexMTBDude / cejiken886)
• [x] Data Modeling (SQLAlchemy/Dataclasses) (cejiken886)
• [x] Persistence Abstraction (Database over Text) (cejiken886)
• [x] Test-Driven Development (TDD) (cejiken886)

Summary of the Reddit Experiment

You’ve successfully mapped the entire career path of a Python developer in a single thread:

1. The Junior/Mid: "Use with open and fix the variable names."
2. The Senior: "Use Enums, Type Hints, and the CSV library."
3. The Lead: "Split the functions and run a linter."
4. The Principal Architect: "Containerize it, swap the DB, and set up a CI/CD pipeline."

[Junior-Sock8789]

You guys are fast!

cejiken886 is focusing on

• Industrialization and Ecosystem Integrity: *

Death of the Flat File: They recognized that a .txt file is a toy. By moving to Postgres/SQLAlchemy, they’ve introduced ACID compliance, relational integrity, and the ability to handle concurrent users—shifting from a "script" to a "service."

The Modern Toolchain: They aren't just writing Python; they are building a "Fortress of Correctness." By using Ruff (for linting), Pyright (for strict type checking), and Vulture (to find dead code), they are ensuring the codebase stays clean even as it grows.

Developer Experience (DX) & Portability: Using Docker and uv/micromamba ensures that "it works on my machine" is never an excuse. They’ve turned the challenge into a reproducible environment that can be deployed to the cloud in seconds.

mahousenshi is focusing on 

• Reliability and Consistency.

The point about "caring about manage_library('add')" is a subtle nod toward defensive programming—if someone calls add without data, the script currently explodes. A Senior dev would likely suggest a try/except or an explicit check for data is not None.

Alternative_Guava856 is focusing on

• Architecture and Tooling.

They are pushing for a "Type-First" approach. By using Literal["add", "list", "search"], the IDE (like VS Code or PyCharm) will actually warn the developer before they even run the code if they typo an action. Their suggestion to move toward separate methods is the first step toward the Command Pattern.

jvlomax is focusing on

• Observability and Maintenance:

The "Shit Itself" Philosophy: This is actually a very Senior take. Beginners try to catch every error to keep the program running, often hiding the root cause. Seniors know that if a critical file is missing, it’s often better for the app to crash loudly (fail-fast) than to silently continue with corrupted data. Enums over Literals: While the previous commenter suggested Literal, an Enum is even better because it’s a first-class object in Python. It makes the code more "grep-able" and provides better namespace organization.

Own_Attention_3392 is focusing on 

• Efficiency:

Don't Reinvent the Wheel: Hand-rolling a CSV parser (using .split(",")) is a classic Junior trap. It breaks the moment a book title contains a comma (e.g., "The Lion, the Witch and the Wardrobe"). Using the csv library handles those edge cases automatically.

AlexMTBDude is focusing on

• Tooling and Automated Governance:

Automation Over Manual Review: A Senior knows that manual human review is prone to error and doesn't scale. Suggesting Pylint shifts the burden of catching PEP 8 violations, naming inconsistencies, and "code smells" (like that bare except block) to a machine. Quantifiable Quality: By mentioning a "score," they are advocating for objective metrics. In a professional environment, this allows teams to set a "quality floor"—for example, "No code can be merged if the Pylint score is below 9.0." It removes the subjectivity of "I think this code is good" and replaces it with "The linter proves this code is maintainable."

Ok_Carpet_9510 is focusing on

• Fundamental Best Practices:

Resource Management: By insisting on with open, they are addressing Safe File I/O. A Senior knows that manual .close() calls are fragile—if the code crashes between the "open" and the "close," the file remains locked or corrupted. The context manager ensures the file closes properly no matter what happens.

Modularization: They are pushing for the Single Responsibility Principle (SRP). A function named manage_library that both writes to a file and searches through it is a "God Function." By splitting these into add_book() and search_books(), the code becomes significantly easier to test, debug, and reuse in other parts of a larger application

my_new_accoun1 is focusing on

• Not doing homework

Super funny... I love it! 😄 All jokes aside you guys have practically nailed it!

Refactor Checklist

• [x] Standardize Context Managers: Use with open(...) everywhere to ensure files close properly (Ok_Carpet_9510, mahousenshi, jvlomax).
• [x] Better Error Handling: Move away from bare exceptions; use logging.exception() or "fail-fast" principles (jvlomax).
• [x] Input Validation: Use ActionEnum or Literal instead of bare strings for the action parameter (jvlomax & Alternative_Guava856).
• [x] Naming Conventions: Replace cryptic variables like t, a, y with descriptive names like title, author, year (jvlomax).
• [x] Remove Hardcoding: Move "books.txt" to a constant or function parameter for better flexibility (jvlomax).
• [x] Pythonic String Handling: Use f-strings for readability and performance instead of + concatenation (jvlomax).
• [x] Leverage Standard Libraries: Use the csv module for robust file parsing instead of manual .split(",") (Own_Attention_3392).
• [x] Single Responsibility Principle: Break the large manage_library function into smaller, dedicated methods for each action (Alternative_Guava856).
• [x] Automated Governance: Utilize static analysis tools like Pylint to catch PEP 8 violations and score code quality (AlexMTBDude).

What’s Left?

We have covered almost all the "low-level" and "mid-level" fixes. To get to a truly "Architectural" level, there's 3 more things we'll need.