I have spent more than six years shipping production software and I have no public repositories worth showing you. Everything substantial I have written at work lives in private repositories belonging to the companies I wrote it for, and confidentiality obligations do not lapse when a role ends. So I cannot hand you the code, and I am not going to.
That is not caution for its own sake. An engineer who sends a prospective employer another company's source code has told you exactly what they will do with yours. The restraint is part of what you are assessing, and I would want the same restraint applied to my work later.
Which leaves a real problem. "I was the principal author of the web application" and "I contributed to the web application" are the same sentence to a reader who cannot check either. Most engineering CVs resolve this by getting louder. I think the only honest resolution is to publish the measurement method rather than the artefact, in enough detail that someone familiar with the tools can judge the figure on its own terms without ever seeing the repository.
Here is the method I actually used, what it does badly, and the places where applying it forced me to shrink a claim I would have preferred to keep.
Three measurements, in increasing order of rigour
All-branch commit count. Total authored activity. Do not use this. It counts abandoned branches, spikes and experiments, and it inflates — usually in favour of whoever is most willing to commit. It is the number that makes contribution graphs look impressive and says the least about a codebase.
Production-branch commit count, scoped to tenure. What reached customers, while you were there. Better, because it excludes work that never shipped, and because scoping to tenure stops you either taking credit for years of history that predate you or being penalised for them. But it still counts commits, and a commit is a unit of activity, not a unit of code. Commit share rewards granular committers and punishes people who work in larger increments. It is the weakest of the three, and it is unfortunately the one most easily produced, which is why it is the one people quote.
git blame on the production branch. Which lines are alive in production today, and who wrote them. This is the authoritative one, because it measures surviving authorship — code that was written, shipped, survived every subsequent refactor by everyone else, and is running now. Its weakness is that it is slow, so it has to be sampled.
Two details make the blame figure defensible, and they are the load-bearing part of the whole exercise.
The flags. I ran git blame -w -M against the production branch. -w ignores whitespace-only changes; -M detects lines moved or copied within a file. Both make the result more conservative, not more flattering: reformatted or relocated code is attributed to whoever originally wrote it rather than to whoever last touched it. If I had wanted a bigger number I would have left both flags off, and anybody who knows the command can verify that claim without access to anything.
The sampling. Deterministic, every Nth file across the sorted file list. Not a hand-picked directory, not a random draw I could have re-rolled until it flattered me, and reproducible by anyone with the same repository. Sampling by directory is where this kind of measurement usually goes wrong, because directories are exactly where authorship clusters.
What that produced, and why the gap is the interesting part
At Cendra, where I was one of two founding engineers, blame analysis on a deterministic one-in-seven sample of the production TypeScript sources — several hundred files — attributes 84.7% of surviving frontend code to me, with the remainder spread across eight other contributors. My production-branch commit share over the same period, scoped to my tenure, is 80.7%.
The gap between those two numbers is the claim, and it points in the direction most people would not expect. My share of surviving lines is higher than my share of commits, which means code written by others was disproportionately replaced by code written by me. I did not only add volume to a growing surface; I rewrote and consolidated the one that was there. That is an argument about architectural ownership rather than throughput, and it is the reason I describe myself as principal author rather than as the person who happened to commit the most.
If the ratio had gone the other way — commit share above blame share — the honest reading would be that I produced a lot of code that other people subsequently replaced. That is a real outcome and it happens, and a method that could not have shown it is not a measurement.
Some figures need no method at all. Every commit to the ios/ and android/ projects across the entire history of the repository is mine — 47 and 28 respectively, along with the Capacitor configuration and the Playwright end-to-end suites at 11 of 11 each. No other author has ever committed to those paths. That is the least arguable claim I have, and it is arithmetic rather than analysis.
All of these were measured while I held authorised access, using ordinary git invocations. I am not offering to demonstrate them live, and you should be wary of anyone who would: opening a former employer's private repository in a screen share is a breach in itself.
The method's real value is that it makes you shrink things
The uncomfortable half of publishing a method is that it applies to the parts of the work you were less central to, and it does not let you round them up.
The same blame analysis run against the production C# sources attributes 23.2% of surviving backend code to me, with a 30.9% commit share over my tenure. I joined the backend roughly six months into a twelve-month tenure. It had been under active development for eighteen months before I touched it, by engineers who are still there. So the accurate sentence is that I was a substantial contributor to a codebase I joined late, and not its architect, and I have tried hard not to imply otherwise anywhere.
Where that contribution sits turns out to be more informative than the total. My share of commits since joining runs highest in the test suite at 83.2%, the domain services at 53.6% and the event-processing consumer at 55.4%, and lowest in the infrastructure at 24.1%, the core domain at 20.8% and the CQRS feature handlers at 16.6%. Low in shared CRUD surfaces, high where architectural judgement was required. I was not the highest-volume backend contributor. I owned the parts that needed design, and the test suite the rest of the team relied on. Other contributors' shares are their own information and are not mine to publish.
Across all four repositories, scoped to my tenure, the combined figure is 5,717 of 10,402 production-branch commits — 55.0%. That is the most conservative aggregate available, and I record it for that reason, but I would not lead an argument with it: a single number spanning a frontend I was principal author of and an integration service I touched occasionally is not really a claim about either. Any aggregate over unlike repositories is a worse description than the per-repository figures it averages, which is why the breakdown above exists and why the 84.7% is the number I would defend first.
Two more boundaries that the method cannot measure but honesty requires.
The core AI architecture at Cendra was not mine. Our AI engineer owned the LangGraph services, the agent workflows and the RAG pipelines. I built the product layer those capabilities were surfaced through — agent configuration, the knowledge base, the agentic rule-authoring interface and the in-product assistant — and the transport between the two, over AG-UI, server-sent events and the realtime hub. I contributed to how the rule and guardrail semantics were shaped, because building an interface through which a non-technical operator expresses a rule an engine will enforce requires understanding those semantics as deeply as the person implementing the enforcement. But I did not architect the orchestration, and "I worked on the AI product" is the easiest sentence in this industry to say and the least informative.
Cendra's product-level metrics are not mine either. Automation rates and platform reach are company figures published by the company. I contributed to the systems behind them. I did not measure them, and presenting a company outcome as a personal one is the specific move that makes every other number on a CV suspect.
Where commit share is all you have
At ReadyFly, a part-time founding-engineer role, I have commit shares and nothing better: 157 of 209 commits to the web application — roughly three quarters, and I made the first one — and 31 of 209 to the Python API. So I say principal author of the first and contributor to the second, and I do not dress the 15% up. The AI models themselves, semantic matching and candidate evaluation, were owned by the team's AI engineer; I built the product layer they were surfaced through — the browser side of that story is in An Interview Inside the Browser.
Commit share is the weakest measurement of the three. When it is the only one available, the right response is to name it as the weakest measurement rather than to present it in the same voice as a blame figure.
What actually closes the gap
Method plus disclosure gets you to a claim that can be judged. It does not get you to a claim that has been independently confirmed, and I do not think any amount of self-published measurement does.
Three things do. Process artefacts that exist independently of my description of them: 255 design specifications, 207 implementation plans and 17 production runbooks, alongside 377 production releases coordinated across four repositories over 239 active development days in a twelve-month tenure. Two Cendra co-founders who have agreed to act as references and can confirm scope and ownership without me in the room. And an offer that costs me nothing to make because it is the part I am confident about: a walkthrough of the systems that are genuinely mine, line by line, including the parts I would now build differently.
The measurements are there so the conversation can start somewhere better than mutual assertion. They are not the evidence. They are a description of how I would go about finding out, published so that you can disagree with it.
This essay first appeared on my site — efe-genc-portfolio.vercel.app/writing/showing-ownership-private-repositories/ — where every figure I quote carries its scope and how it was measured. If you have approached this differently, I would genuinely like to hear how; disagreement is the most useful comment I can get.
This article was originally published by DEV Community and written by Efe Genç.
Read original article on DEV Community