Month three: learning enough to ship

Month three of the data science apprenticeship at the 718 Digital Lab was the first month I was contributing to real products instead of mostly preparing to. The comic above is the honest summary: I love to learn, and that's really what got in my way.

By the numbers

Eight tickets across two codebases that are built very differently, by different teams.

Two codebases; Two sets of house rules

FPDS is a dashboard for and by The Knowledge House's Teaching & Learning (T&L) team, built SQL-first on PostgreSQL with schema changes run through Alembic migrations. I analyzed the schema, built an interactive HTML map of it so I could actually see how tables relate, and tightened column types and constraints to protect data integrity. Along the way I learned how Alembic migrations work and how to iterate on them safely.

KBOX is the 718 Digital Lab's own project: a much larger TypeScript monorepo with a retrieval-augmented generation (RAG) pipeline that generates instructor-reviewed practice material from TKH's own curriculum. Before writing any code, I studied its OpenAPI contract to learn how the API is shaped. Then I opened two PRs: a mock server with contract tests so the API can be tested in isolation, and a design recommendation for securing communication between services.

The problem: trying to understand everything first

FPDS took two days to get into. KBOX took a week, which is what my comic is portraying. KBOX is roughly three times the size, and I set myself the goal of understanding it deeply before I touched a ticket. That turned into a loop: inexperience → anxiety → overcompensating by studying more → still not shipping. Perfectionism felt like diligence, but it was mostly delay.

What I'm practicing now is getting a high-level understanding of how these systems fit together, then going deep only on the part my ticket actually touches.

What I'm proud of

Asking for help. Talking it through with my senior engineer and PM is what broke the loop. It wasn't a technical fix. It was permission to stop trying to know everything before doing anything.

The other moment was brainstorming my first KBOX ticket with a fellow apprentice, who showed me a different way to use Claude Code. I had been using it like a study guide: explain this topic, then the next one. They used it to learn while building, asking about the exact code in front of them as the work went. After that shift, both KBOX PRs went up within about a week.

What I learned

• How to learn enough of a system to contribute to it. "Enough" is a real, reachable target, but "everything" isn't.
• How to simplify a task efficiently. Shrink the ticket to the smallest piece I can understand and finish, then build out from there.
• Claude Code as a code tutor, not a textbook. Ask about the code I'm changing, while I'm changing it.

What I'm hopeful for

I want to see these products working the way they're meant to, especially KBOX. I care about helping The Knowledge House's bootcamps succeed, and KBOX is aimed right at the moment a fellow starts falling behind: practice material based on their own curriculum, reviewed by their own instructor, delivered where they already are. That's the kind of support that keeps fellows in the program, and I want to help build it.

Next month's goal: less time studying, more time building!