Code Reviews When You're the Whole Team

Most blog posts about code reviews assume you work at a company with a team, PR culture, and dedicated reviewers. I don't. I'm one person shipping Sysmon-CLI, Zvezda, and Iris.

Here's what code review looks like when you're the whole team—and what actually matters when someone does review your work.

The Reality of Solo Development

No one reviews my code before it ships. I merge to main. I deploy. Users find bugs. I fix them.

This sounds chaotic. It's not. I've shipped three production tools this way. They work. But I still "review" my code—just differently.

Self-Review: What Actually Works

The 24-Hour Rule

I don't merge code the same day I write it. I wait. Sleep on it. Come back tomorrow.

Why? Because fresh eyes catch stupid mistakes. Yesterday I thought this was brilliant:

func GetMetrics() map[string]interface{} {
    return map[string]interface{}{
        "cpu": getCPU(),
        "mem": getMem(),
        "disk": getDisk(),
    }
}

Today I see it's `map[string]interface{}` hell. Needs a struct. Type safety matters.

The Diff Review

Before committing, I review my own diff. Not in the editor—in `git diff` or GitHub's draft PR view. Different context reveals different problems.

Things I catch:

If I can't explain the diff to myself, it's not ready.

The "Why" Test

Every commit message gets a "why":

❌ Update metrics collection
✅ Switch to buffered channel to prevent blocking

❌ Fix bug
✅ Handle SIGTERM during shutdown to flush metrics

If I can't articulate why I'm making a change, I probably shouldn't make it.

When Someone Actually Reviews Your Code

Occasionally someone opens an issue or PR on Sysmon-CLI or Zvezda. Here's what I've learned about receiving feedback.

Most Feedback is Noise

"You should rewrite this in Rust" is not feedback. It's an opinion. Ignore it.

"This panics when config file is missing" is feedback. That's a bug. Fix it.

The signal:

The noise:

Good Feedback is Specific

I got an issue on Zvezda: "It's slow." Useless. Can't fix "slow."

Then I got: "Listing 500 repos takes 12 seconds. Here's `pprof` output showing 80% of time in JSON parsing."

Fixed in 30 minutes. The problem was re-parsing the entire repo list on every request instead of caching. Specific feedback = actionable fix.

When to Push Back

Someone wanted Sysmon-CLI to support Windows Event Log collection. Sounds reasonable. But:

I said no. My tool, my rules. They're welcome to fork it.

**You don't owe anyone features.** Especially in open source. Especially in solo projects.

What I Look For When Reviewing Others

I've reviewed PRs on other projects. Here's what actually matters:

Does It Work?

Not "is it elegant" or "does it follow best practices." Does it solve the stated problem?

I've seen beautiful, idiomatic, perfectly tested code that didn't fix the bug. I've seen ugly hacks that worked perfectly. Ship the hack. Clean it up later if needed.

Will It Break Something?

The only blocker is: does this break existing functionality?

Everything else—performance, style, architecture—can be fixed incrementally. Breaking changes can't.

Can I Understand It?

If I can't figure out what the code does by reading it, that's a problem. Not because "clean code" matters, but because I might need to fix it later.

I don't care about variable names, comments, or formatting. I care about: can I trace the execution path?

The Tools I Actually Use

No fancy PR workflows. No automated review bots. Just:

CI/CD

# .github/workflows/test.yml
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - run: go test -race ./...
      - run: golangci-lint run

If tests pass and linter is happy, it's probably fine. If not, fix it before merging. That's the gate.

Local Checks

Before pushing:

go test -race ./...
go build
./sysmon-cli --version  # smoke test

If it builds and runs, good enough. Perfect is the enemy of shipped.

What Doesn't Matter

All the corporate code review advice is irrelevant for solo projects:

**Response time SLAs**: You're reviewing your own code. It's done when it's done.

**Required approvals**: You're the only approval. Approve your own PR if you want ceremony.

**Review checklists**: If you need a checklist to remember to write tests, bigger problems.

**Consensus building**: You decide. Ship it or don't. No committee.

**Team culture**: You're the team. Your culture is "does it work?"

When Code Review Actually Helps

I'm not anti-review. I'm anti-process-for-the-sake-of-process.

Code review helps when:

Code review doesn't help when:

The Real Review: Production

The best code review is production. Users find bugs you missed. Logs show performance issues. Crashes reveal edge cases.

Sysmon-CLI had a memory leak. Took 3 weeks for someone to report it. No code review would've caught it—it only triggered under 24+ hour continuous operation.

Zvezda had a race condition. Found it via crash reports, not review. Added `go test -race`, fixed it, added regression test. Done.

**Production is the reviewer.** Everything else is just preparation.

If You're Actually on a Team

If you're not solo, here's what matters:

1. **Automate style, bike-shedding, and formatting**. Never discuss tabs vs spaces in a PR.

2. **Only block on correctness**. "I would've done it differently" is not a blocker.

3. **Review for bugs, not beauty**. Code can be ugly and correct.

4. **Keep PRs small**. 50 lines = 10 minutes. 500 lines = "LGTM" without reading.

5. **Self-review before requesting review**. Don't waste their time on stuff you'd catch yourself.

Bottom Line

Code review for solo developers:

Code review for teams:

Everything else is cargo-culting enterprise processes that don't apply to small teams shipping real software.