I’ve always felt that the gap between "finishing a tutorial" and "contributing to a production codebase" is a cliff. Most newcomers struggle because real-world code is messy, undocumented, and often broken.
I’m building Grind-Mal, a platform that turns open-source contribution into a "grind" (in the gaming sense). Instead of clean sandboxes, we provide "Artifacts"—intentionally broken or complex Go-based environments that require actual debugging and architectural thinking to fix.
I just added a dashboard to track the ecosystem's state: PR velocity, active "arenas," and contributor impact. The goal is to move the industry away from "resumes and opinions" and toward "proof of work."
We are currently in alpha. I'm looking for feedback on the "Artifact" concept. Is intentionally breaking code a valid way to vet/train engineers, or is it too artificial?
tomari99•1h ago
I’m building Grind-Mal, a platform that turns open-source contribution into a "grind" (in the gaming sense). Instead of clean sandboxes, we provide "Artifacts"—intentionally broken or complex Go-based environments that require actual debugging and architectural thinking to fix.
I just added a dashboard to track the ecosystem's state: PR velocity, active "arenas," and contributor impact. The goal is to move the industry away from "resumes and opinions" and toward "proof of work."
We are currently in alpha. I'm looking for feedback on the "Artifact" concept. Is intentionally breaking code a valid way to vet/train engineers, or is it too artificial?
GitHub: https://github.com/Grind-Mal
I’ll be around to answer any questions about the architecture or the vision.