Part 2 of 2. If you haven't read Part 1 yet, start here: I Got a Zero on a Beginner Python Assignment Because My Code Was "Too Good".
Two weeks ago, I wrote about getting a temporary zero on a beginner Python assignment because my code was too feature-rich. The grader thought an AI must have written it. I argued that the rough edges — the abcdefghijklmnopqrstuvwxyz placeholder I forgot to delete, the inconsistent variable names, the Windows-only winsound — were proof it was mine.
I ended that article on a cliffhanger: the system had pushed back, and I'd just sent my appeal.
Here's what happened next.
The Instructor Replied First
Before my appeal even landed, my instructor sent me a message. And it wasn't what I expected.
"Kehinde, I didn't flag this assignment, it was our grader. As I look at this code, it was immediately obvious to me that you wrote it. I will tell the graders to grade this normally. The use of
winsoundis great, but I don't know what the graders will think. They won't want to install the library to test your program. It wasn't working for me so I just disabled it and the program ran fine without the sound. The graders may dock you — we'll see. If they do, you can resubmit without the sound component and I'm sure you'll be fine. It may take a couple days before it's graded, but I don't have concerns with this assignment. It looks really good — good work!"
Read that again.
The instructor — the person I'd assumed was suspicious of me — didn't flag the assignment at all. The grader did. And when the instructor actually looked at my code, his response wasn't "prove it's yours." It was:
"It was immediately obvious to me that you wrote it."
That sentence is the entire story.
What This Revealed
The system has two layers:
The grader — often a teaching assistant or automated reviewer, working from a checklist, with no context about who you are. They see code that looks "too advanced" for Week 4 and flag it. Fair enough.
The instructor — the person who knows the students, has context, and can override. They looked at my code for thirty seconds and saw what I'd been trying to explain: the quirks are the signature.
The grader followed the process. The instructor corrected it. That's how it's supposed to work.
But here's the part that matters: if I hadn't written that appeal, if I hadn't pointed at the rough edges, if I hadn't stayed calm and factual — would the instructor have looked at my code as carefully? Maybe. Maybe not. The system worked because I pushed back the right way.
The winsound Thing
The instructor's feedback also included a practical note I hadn't considered:
"They won't want to install the library to test your program. It wasn't working for me so I just disabled it and the program ran fine without the sound."
This is the kind of thing you only learn by shipping code to real environments. winsound is Windows-only. On Mac and Linux, the import winsound fails. My try/except caught it — so the program ran — but the sound didn't play. For a grader on a Mac, my "creative sound effects" were just dead code.
The instructor's advice was practical, not punitive: remove the sound, resubmit, you'll be fine.
So I did. Ten minutes of cleanup:
- Commented out
import winsound - Removed all
winsound.PlaySound(...)andwinsound.Beep(...)calls - Updated the creativity comment on line 1 to remove "sound effects"
- Un-commented a
print("Invalid input!")that had accidentally been disabled along with the winsound lines
Resubmitted.
The Grade Came Back
100/100.
Every criterion. Every point.
- ✅ Repeated guessing loop — 40/40
- ✅ Guess counter — 13/13
- ✅ Initial hint with spaces — 10/10
- ✅ Hint logic (uppercase / lowercase / underscore) — 20/20
- ✅ Length validation with warning — 10/10
- ✅ Creativity (menu, help screen, random words, loading animations) — 7/7
What I Learned
1. The System Has Layers — Use Them
A grader's flag is not the end. It's a signal for a human to look closer. If you get flagged:
- Don't argue with the grader (they're following the process)
- Appeal to the instructor with evidence
- Offer concrete ways to demonstrate authorship
2. Not Every Instructor Is the Adversary
I spent a week assuming my instructor thought I cheated. He didn't. He thought my code was good. He was defending me to the graders while I was drafting careful-but-pissed messages to him.
The lesson: assume good faith until proven otherwise. The person on the other end is usually just trying to do their job.
3. Cross-Platform Matters
winsound is Windows-only. If you're building anything anyone else will ever run — assignments, portfolio pieces, shared tools — use cross-platform libraries or gracefully degrade. My try/except was the right idea; the execution just wasn't complete.
Better options for future projects:
-
pygame.mixer(cross-platform, needs install) -
simpleaudio(lightweight, cross-platform) -
playsound(simple wrapper, cross-platform) - Or just print ASCII/emoji feedback instead of sound
4. Creativity Should Match the Environment
My sound effects were genuinely creative — but they weren't testable on the grader's machine. That's a real problem. Creativity that only runs on your own laptop is not fully shipped.
The fix: creativity that runs everywhere. Loading animations (time.sleep) work everywhere. Random word selection works everywhere. A formatted help screen works everywhere. Sound is the one feature that broke portability — and it was the one feature I lost points for considering.
The Unexpected Part
After Part 1 went up, I got messages from:
- A 30-year-old career changer flagged for a "too clean" Java project
- A high schooler accused of AI on an essay he wrote himself
- A teacher who said the flagging system is "broken but the only tool we have"
- Two other self-taught devs in Nigeria who'd been through similar things
I wrote the first article out of frustration. But the response told me something bigger: this isn't a me problem. It's a system problem. And the way through it — for now — is to keep your receipts, stay calm, and appeal to the human on the other side.
What's Next
W05 (Shopping Cart) was already at 100/100. W06 and W07 are coming. And after that: more Limn Engine, more arcade, more shipping.
The class was never the goal. But getting through W04 taught me something no lecture could:
The rough edges are the story. Keep them. Ship them. Defend them when you have to.
And when the system works — when a teacher says "it was immediately obvious to me that you wrote it" — that's worth writing about too.
Final Thought
If you're a self-taught dev in a beginner class and you get flagged:
- You're not crazy. The system is awkward.
- Stay calm. Bring receipts.
- Appeal to the human. The grader isn't the final word.
- Fix what's asked. Even if it's small. Even if it feels unfair.
- Resubmit. Usually you get the points.
- Write about it. Because the next person will Google this, and your story will be the answer they find.
The system worked for me. Not smoothly, not instantly, but it worked. And that's worth saying out loud.
Kehinde Owolabi is the creator of Limn Engine and founder of Evolved Tech. He writes about self-taught development, browser game engines, and the awkward intersection of code and education.
Top comments (0)