Three bugs we found and fixed in our own pipeline this week

Journeymen — Sat, 01 Aug 2026 18:50:45 +0000

Three bugs we found and fixed in our own pipeline this week

Journeymen grades developer work against GitHub's server-side history. That only means something if the grading pipeline itself is reliable — so here's the honest engineering update, not the highlight reel.

1. Silent progress loss on connect-repo analysis runs

A connect-repo analysis run could sit in processing status with no visibility into what stage it was actually at, or whether it had stalled. From a dev's dashboard, a slow run and a stuck run looked identical. We added explicit progress-stage tracking so a stuck run is visibly stuck, not silently pending.

2. A background worker timing out without a clear signal

The Lambda-based worker handling asynchronous analysis jobs was hitting its timeout under certain repo sizes, and the failure mode wasn't obvious from the outside — a run would just never complete. We root-caused the timeout and fixed the underlying slow path.

3. Dead-letter queue with no observability

Jobs that failed enough times to land in the SQS dead-letter queue were, until this week, invisible — no alerting, no in-product surfacing. We wired up observability so a DLQ arrival is now a visible signal instead of a silent dead end.

Why post about our own bugs

The entire pitch of Journeymen is "don't trust the self-reported version, trust the verified one." That standard has to apply to us too. All three issues: found, fixed, and shipped this week.

journeymen.in

Grading GitHub work like evidence, not a resume

Journeymen — Sat, 01 Aug 2026 18:14:39 +0000

Grading GitHub work like evidence, not a resume

Skill badges are self-assigned. Endorsements are traded. Git history doesn't do favors -- that's the premise behind Journeymen, a developer certification I've been building that grades your actual GitHub work instead of taking your word for it.

The problem with self-reported skill

A badge you can click to award yourself isn't a credential, it's a claim. An endorsement someone traded for one back isn't a credential either. The one thing that's expensive to fake is your own commit history -- so that's what Journeymen reads.

Three confidence tiers, never blended into one score

Verified via GitHub: merged PRs and timestamps confirmed directly against GitHub's own API. If GitHub doesn't confirm it, it isn't Verified.
Cross-checked: local git commit cadence, sanity-checked for organic patterns.
Inferred: structure and README-vs-code consistency -- qualitative signal, always labeled as such.

Most certification systems collapse everything into a single number. Journeymen shows you which tier every finding came from, because "verified" and "inferred" are not the same claim.

CLI-first, and it shows you first

The CLI (journeymen analyze) reads your local git history and prints exactly what it found -- and exactly what it would send -- before anything leaves your machine. Nothing about your code or commit messages goes anywhere; only aggregated stats do.

Anti-fraud, built in from day one

Fork-and-claim detection, solo-repo authorship limits, merged-PR-only credit (an open PR you never got merged doesn't count), and automated README-vs-code consistency checks. All server-side, all re-verified against GitHub -- your local CLI's word is never taken as-is.

Where it stands today

I'm the first real user -- my own profile is graded the same way anyone else's would be. Only 2 developers are registered so far, so this is very early. If you've dealt with padded resumes or traded endorsements, I'd like to hear what's missing from this model.

Site: https://journeymen.in

DEV Community: Journeymen

Three bugs we found and fixed in our own pipeline this week