I've been building EduTrack, a school management system for Ghanaian primary and JHS schools. Today's session started with fixing real bugs — a permission check that could crash if a teacher's class assignment changed mid-request, undefined variable bugs hiding in conditional branches, a missing CSRF consideration.
But the part I'm most proud of happened when I looked at my Result model for storing student test scores and felt something was wrong with it. I couldn't fully explain why at first — just a gut sense that one flat table per student per subject per term wasn't going to work once you add quizzes, class tests, and exams into the mix.
Turns out I was reaching for a pattern I'd already used twice before in this same project, without realizing it was a named, reusable idea: a parent record describing an event, and child records describing individual outcomes of that event.
My Fee/FeePayment tables already worked this way. So did the Attendance/AttendanceRecord redesign I did a few days ago. Today, without anyone pointing it out, I recognized the same shape forming in a third, completely different feature — assessments and results.
That's the part of this journey that feels different from just "learning Django." I'm not just writing code that works. I'm starting to recognize shapes — patterns that repeat across unrelated parts of a system, once you've felt the pain of not having them.
Still building. Still debugging real bugs from real edge cases I test myself. Still learning out loud.
Loading thoughts...