The Job
In fall 2024 I was the class reviewer for my software engineering class at Allegheny, one of the especially technical courses taught by the professor behind tools like ExecExam. I implemented the git flow the whole class worked in, and classmates' pull requests came through me for review before they merged.
That means I spent a semester reading code I did not write, from people with wildly different styles, and deciding what was ready and what needed another pass. It changed how I write software more than any single assignment did. The work from that class is public: you can see it across execexam, gatorgrade, and gatorgrader.
The Little Learnings
- Small pull requests are a kindness. A 40 line PR gets a real review; a 900 line PR gets a tired skim.
- The description is half the PR. If I had to open the diff to figure out what the change was for, the description had already failed.
- Review the code, never the person. The fastest way to make someone defensive is to make it about them.
- A branch name is documentation. feature/fix-grading-crash tells me something. patch-7 tells me nothing.
- Merge conflicts are a communication problem wearing a technical costume. Two people touching the same file did not talk first.
- If the tests pass but I cannot understand the code, it is not done. Future readers are part of the team too.
Why It Stuck
Being the reviewer put me on the other side of my own habits. Every vague commit message I had ever written suddenly had a face: the poor person trying to understand it. I came out of that role writing smaller branches, clearer descriptions, and commit messages that tell the story of the change.
I still work this way now as a professional developer. The repos are different, but the lesson holds: code review is not a gate, it is the place where a pile of individual work turns into a team's software.