Engineering · 6 min read · April 18, 2026
Git logs and manifests reveal engineering discipline before code review
A hackathon judge explains how commit history, dependency files, and stray artifacts expose process quality that demos never show.
Project metadata — commit history, package manifests, leftover files — reliably signals whether software was engineered deliberately or assembled hastily.
- — Iterative commit histories indicate a developer reasoned through problems step by step.
- — A single large commit hides the entire development process from any reviewer.
- — Default template values left in package.json signal the developer skipped basic cleanup.
- — Unused dependencies listed but never imported suggest uncritical acceptance of AI suggestions.
- — Files like CLAUDE.md left in a repo show the developer did not audit their own submission.
- — Test files that crash on execution or contain no assertions are not tests in any meaningful sense.
- — README claims unsupported by actual code represent a credibility gap judges can measure directly.
- — Developers who maintain clean metadata in low-stakes contexts tend to do so in production too.
Frequently asked
- A commit history with many small, descriptively named commits shows that a developer iterated, debugged, and made deliberate decisions throughout the build. A history with only one or two large commits means the development process is invisible — there is no evidence of problem-solving, backtracking, or refinement. According to Vignesh Durai's analysis of ten hackathon projects, iterative commit histories correlated strongly with better architecture, error handling, and fewer broken code paths.