← Back to context

Comment by owenpalmer

1 year ago

> The average developer averages 10 lines of finished code per day

This is a ridiculous statement. Citation needed.

Hopefully it's clear that:

- code is not the only output produced by a developer. Communication, design, documentation, testing and tests, diagnosing and debugging, etc.

- I can and do write hundreds of lines of working code in a given day (and I'm not an IC). But "finished" was meant to describe something that doesn't get touched again unless new work requires it. A lot of code today is written more iteratively, with mvps, experiments, baselining, refactoring, etc. An mvp is not (yet) finished.

- 10 lines may be a low estimate today, but 100 is probably fair. (yeah varies a lot with language, boilerplate, etc)

I hope the general agreement would be that the amount of characters of code written is definitely not the largest part of a developer's output, but reaching the point where a given line of code is "finished" involves a number of processes and lot of typing. And editors are an important part of many of those processes.

  • Hmm... This might be where my process differs, I guess?

    In my normal process (not exploratory work), I don't write a single character until I'm sure of how the thing I'm making will fit into the overall design (such as the API it will have, how it will interact with other components, its placement in the overall architecture, what its responsibilities are and how to structure it so as to minimize potential confusion and make what it is doing clear to a reader, mentally walking through code paths to make sure other components can use it as intended, etc). All of that happens in my head, not in an editor (although I might have a few notes jotted down if it's a big change or a whole new feature).

    Then, once I know exactly what I intend to write, I just dump it all down into the source files. 80% of it is already "finished code" in that I won't be changing it again unless I've made a serious design error.

    • My process is in that case quite different. When working in Python I’ll typically write thousands of tiny snippets of code directly in the interpreter to check that simple things work as I expect. Those are gradually distilled into parts of a .py file with accompanying pytest tests. Then those are refactored into classes and separate files as needed. Overall, I think I type and edit way more than you :)

Last I saw, the stat was 40ish per day. It's partially testable though. You presumably have a codebase at hand with a few contributors. Just git stat that code and average the lines changed by the top 5 contributors. Count deletions as "finished" lines of code too. Add in some auto-generated lockfiles and whatnot if you still haven't hit that 40 line-per-day mark. Report back if you're able to exceed it.

> This is a ridiculous statement

Ten lines per day?? Over my 20-year career in Big Tech I figure I've averaged about 10 lines of shipping code per week. I've been working in a domain-specific field and have shipped several kernel features. These days I'll sometimes go an entire quarter without writing a single line of code.

Not all of us went down the "Java code monkey" career path.

  • I work on big tech and average far more lines of production code per day because where my project falls on this spectrum. The biggest thing that I've seen slow things down is scale (both size of codebase as well as users), followed by testing culture. This and a few other factors dictate the rate at which you invest in feature development. Not everything is a heavily undertested behemoth that has hundreds of millions of users. Therefore your experience may differ greatly from others and that means no one has the right experience. Even different roles within an organization making a common product can experience great variance based on subdivision (infra vs platform vs product vs security, seniority, etc).

>finished code

I think the commenter suggests that you can just write those right away and the 100s of lines along the way don't exist