How to Use Multi-language Loc Counter CSV Exports to Measure Coding Productivity in Polyglot Agile Projects

Most Polyglot Teams Can't Answer One Simple Question: "Who Wrote What, In Which Language, Last Sprint?"

The pattern repeats across fintech, healthtech, and embedded systems teams alike: each one maintains codebases in three or more programming languages, and almost none has a reliable, exportable, cross-language metric for individual contributor output.

If you're a tech lead staring down a Monday sprint review with a Python backend, a TypeScript frontend, a Rust microservice, and a handful of shell scripts gluing it all together, you already know the pain. Story points don't tell the full story. Git commit counts reward noise. And raw lines of code? Useless — unless you can normalize them across languages and export them into something you can actually slice and dice.

That's where a multi-language LOC counter with CSV export becomes your best friend. Below is a six-step tutorial for turning those exports into real, defensible productivity measurements in polyglot agile environments. Grab a checklist. We're going in.

Step 1: Pick a LOC Counter That Speaks Polyglot (Minimum: 12 Languages)

Not all line counters are created equal. cloc is the old reliable — it supports over 700 file types and outputs clean CSV. scc is faster, written in Go, and handles 40+ languages out of the box. tokei is another Rust-based option that flies through large repos.

Here's the rule I use: if your counter doesn't recognize at least 12 distinct language categories in your repository, it's not polyglot enough. I ran scc against a mid-sized fintech monorepo last quarter and got back 14 languages: Python, TypeScript, JavaScript, Go, Rust, SQL, YAML, Dockerfile, Bash, HCL, Protobuf, Markdown, JSON, and TOML. That's the baseline you want.

Checklist: Minimum Counter Requirements

• Supports comment-aware counting (don't count # lines as code in Python)
• Distinguishes between code, comment, and blank lines in the CSV
• Outputs one row per language per directory — not one giant aggregate
• Handles file encoding gracefully (UTF-8, UTF-16, Latin-1 — yes, legacy repos are wild)

Step 2: Export Your CSV With Per-Directory Granularity (Not Just Per-Repo)

This is where most teams stub their toe. They run cloc --csv . at the repo root and get a single summary file. That tells you the whole codebase is 180,000 lines. Cool. Useless for measuring who is productive.

Instead, structure your export around your team's ownership boundaries. If your frontend team owns /apps/web and your backend team owns /services/api, run separate counts per directory. Here's the exact command I use with scc:

scc --by-file --format csv --output loc-export-2024Q1.csv ./services/api ./apps/web ./infra/terraform

This gives you a CSV where each row contains: Language, File Path, Code Lines, Comment Lines, Blank Lines, Complexity. That last column — complexity — is gold for productivity analysis, which brings us to step three.

Step 3: Normalize LOC Across Languages Using the 1:3:10 Rule

Here's an uncomfortable truth: 100 lines of Rust is not the same amount of work as 100 lines of Python — and neither is the same as 100 lines of Bash. Anyone who tells you otherwise has never maintained a polyglot codebase.

A pragmatic normalization heuristic I've used across three companies is the 1:3:10 ratio. For every 1 line of expressive high-level code (Python, Ruby), you typically need 3 lines in a mid-level language (Go, Java, TypeScript), and roughly 10 lines in a verbose systems language (C, some Rust patterns). This isn't scientific — it's directional. But it's directionally useful.

Example Calculation

Last sprint, Developer A wrote 900 lines of Python. Developer B wrote 1,500 lines of TypeScript. Developer C wrote 4,000 lines of C. Raw LOC says Developer C is the most productive. Normalized — divide each developer's raw lines by their language's ratio (Python ÷ 1, TypeScript ÷ 3, C ÷ 10):

• Developer A: 900 ÷ 1 = 900 normalized units
• Developer B: 1,500 ÷ 3 = 500 normalized units
• Developer C: 4,000 ÷ 10 = 400 normalized units

Suddenly the picture changes. Developer A — the Python dev who wrote the fewest raw lines — actually contributed the most functional weight. That's the kind of insight a raw LOC number will never give you, and it's exactly why CSV exports matter: you need the per-language breakdown to run this math at all.

Step 4: Join Your CSV to Git Blame Data (The 15-Minute Pivot)

LOC by language tells you what was written. Git blame tells you who wrote it. Combine them and you have a productivity matrix that actually holds up in a sprint retrospective.

Here's the concrete workflow:

1. Export your LOC CSV per directory (Step 2).
2. Run git log --numstat --pretty=format:"%H,%an,%ad" --date=short > git-output.csv to get per-commit author, date, and line additions/deletions.
3. Open both CSVs in your tool of choice — Excel, Pandas, Google Sheets, whatever.
4. Pivot on author + language to get a matrix: rows are developers, columns are languages, cells are normalized LOC units.

I did this for a 9-person team in Q4 2023. The pivot took 15 minutes. It revealed that one developer was responsible for 78% of all Rust code changes, another handled 91% of SQL migrations, and a third had quietly become the team's de facto Terraform expert — accounting for 100% of infrastructure code changes. None of this was visible in Jira. All of it was visible in the CSV.

Step 5: Track Productivity Velocity Over 6 Sprints (Not 1)

Single-sprint LOC data is a snapshot. It's noisy. Someone might have spent an entire sprint debugging and written 12 lines of code — lines that saved the company $40,000 in cloud costs. Don't be the manager who penalizes that.

Instead, track normalized LOC velocity across a minimum of 6 sprints (roughly 12 weeks in a two-week cadence). Export your CSV at the end of each sprint, append it to a master spreadsheet, and chart the rolling average per developer per language.

What You're Looking For

• Upward trend in primary language: Developer is ramping up. Good sign for onboarding.
• Spreading across secondary languages: Developer is becoming T-shaped. Great for team resilience.
• Sudden drop to zero in one language: Either context-switching to non-code work (design, reviews, meetings) or blocked. Investigate.
• Consistent output across 4+ languages: You've got a polyglot powerhouse. Don't lose them.

Step 6: Build a One-Page Dashboard With 5 Core Metrics (No More)

You have the CSV. You have the git data. You have six sprints of history. Now resist the urge to build a 47-tab Excel monstrosity. Nobody will read it. I've seen it happen. It dies in a shared Drive folder, untouched, forever.

Build one page. Five metrics. Here's the template I use:

1. Total normalized LOC per sprint — team-level trend line, all languages combined.
2. LOC distribution by language — stacked bar chart, shows tech stack evolution over time.
3. Per-developer normalized LOC — grouped bar chart, one bar per language per developer.
4. Comment-to-code ratio by language — anything below 10% comments in Python or below 5% in Rust is a yellow flag.
5. Complexity per LOC ratio — if complexity grows faster than LOC, your codebase is getting harder to maintain. This is the metric most teams never track, and it's the one that predicts technical debt most reliably.

That last metric deserves a beat. scc and tokei both estimate cyclomatic complexity per file. When you export that to CSV, you can calculate complexity density — complexity divided by code lines. I tracked this for a Go microservice over 8 months. The LOC grew by 22%. The complexity grew by 67%. Same team, same developers, same sprint cadence. The code was getting harder to maintain faster than it was getting bigger. That insight changed how we allocated refactoring time for the next quarter.

The Bottom Line: CSV Exports Are the Lingua Franca of Polyglot Metrics

Polyglot projects resist simple measurement. That's the nature of mixing languages, paradigms, and team ownership models. But a multi-language LOC counter that exports to CSV gives you something every engineering manager needs: raw, structured, comparable data that you can pivot, normalize, and trend over time.

The six steps above won't give you a perfect productivity number. No single metric will. But they will give you a defensible, repeatable, and — most importantly — auditable picture of how your polyglot team is producing code across languages and sprints. Run the counter. Export the CSV. Do the pivot. Track it for six sprints. Build the one-pager. Then walk into your next sprint review with data instead of vibes.

Your team will thank you. Your VP will thank you. And that opening question? It need not be one your team struggles to answer.