4 ms·

Self-reported or observational data capturing time spent for categories of task ala every other similar study in this space? This isn't exactly novel territory

Self-reported or observational data capturing time spent for categories of task ala every other similar study in this space? This isn't exactly novel territory, here, Simon. Let's not pretend I'm asking for something strange, unprecedented, or unreasonable.

simonw 2mo ago
How's this? https://simonwillison.net/2026/Jul/13/datasette-code-frequency/ https://simonwillison.net/2026/Jul/13/datasette-code-frequen... I have similar charts across my three main open source projects: https://github.com/simonw/datasette/graphs/code-frequency https://github.com/simonw/datasette/graphs/code-frequency https://github.com/simonw/llm/graphs/code-frequency https://github.com/simonw/llm/graphs/code-frequency https://github.com/simonw/sqlite-utils/graphs/code-frequency https://github.com/simonw/sqlite-utils/graphs/code-frequency
- qsera 2mo ago
  I don't think volume of code changed was the metric the other commenter was asking for.
  - deleted 2mo ago
    [deleted]
- the_af 2mo ago
  Isn't this falling into the "lines of code" trap TFA mentions? More code written is not a good measure of productivity. It could be garbage, or redundant code, or simply not addressing the real or more pressing needs, it could be building the wrong thing, etc. Like TFA mentions, it's been known for decades LoC is a misleading metric for productivity. It's one of the lessons of software engineering.
  - simonw 2mo ago
    I'm planning an article at the moment in defense of lines of code. Saying "lines of code are a bad measurement" is too easy! It's about time someone presented an opposing argument. In my specific case, lines of code for my published open source projects is a metric that I trust, because I have high standards for those. I have plenty of other projects where I'll accept poor quality, unreviewed code (almost all of https://github.com/simonw/tools https://github.com/simonw/tools for example), but Datasette, sqlite-utils and LLM are not that. Of course, that's only useful for me personally and for people who trust me to stick to my own self-declared high standards!
    - otabdeveloper4 2mo ago
      > Lines of code are akshually a good metric now, because that's the only metric LLMs can optimize and I really, really, really love LLMs, they're the bee's knees. Really now?
      - simonw 2mo ago
        No.
    - skydhash 2mo ago
      > Saying "lines of code are a bad measurement" is too easy! It's about time someone presented an opposing argument. Maybe because there is none. One of the main quality of good codebase is simplicity. Which is about how easy for someone else to understand the code. It’s hard to define what simplicity looks like, so the best bet is to avoid the other side, making the code too complex. And you can make the code complex by shortening variable name, doing code golfing with quicks of the platforms, so smaller LoC. You can also go the other way and increase the LoC by adding unneeded abstractions, repeating slices of code,… There’s a window where the LoC is perfect to attain simplicity, but that amount is an effect of striving for simplicity, not a cause of it. And it’s variable for every problem. So you got something where the correct value is a different for each case. And trying to manipulate it artificially often results in complex code. And you want to say that is a good metric for productivity? And in the cases of your projects, there are a lot more info could share that are interesting, like the amount of issues (reported or found by you) that are tied to implementation bugs (coding, libraries API breakage,…) or design issues (requirements conflicts,…), documentation improvement,… Anything that is tied to the actual usefulness of the projects, and not fumbling around with code.
- unknownfuture 2mo ago
  The article mentions that coding is only a fraction of dev time and thus accelerating that part of the job can only create incremental gains, and oh PS, lines of code and similar metrics are a bad way if measuring dev productivity, anyway, and we've known that for decades. The OP claims AI accelerates non-coding parts of the job, too, and so the article is misguided. I ask for evidence. In response you give me... code output metrics?
  - simonw 2mo ago
    I don't have anything else to hand that I can think of. I don't keep a time tracking diary.
    - discreteevent 2mo ago
      > I don't keep a time tracking diary. That's why Microsoft did a study (referenced in the article), where they measured the time spent on things, so they could get to the truth of how much time people spend coding using "a shape of evidence would you find convincing"
      - kylecazar 2mo ago
        The Microsoft study concerns the ideal vs. actual developer workweek. They conclude that developers using AI tools "heavily" are both more productive and more satisfied. And, surprise, that devs hate meetings and want to code more.

simonw 2mo ago

How's this? https://simonwillison.net/2026/Jul/13/datasette-code-frequency/ https://simonwillison.net/2026/Jul/13/datasette-code-frequen... I have similar charts across my three main open source projects: https://github.com/simonw/datasette/graphs/code-frequency https://github.com/simonw/datasette/graphs/code-frequency https://github.com/simonw/llm/graphs/code-frequency https://github.com/simonw/llm/graphs/code-frequency https://github.com/simonw/sqlite-utils/graphs/code-frequency https://github.com/simonw/sqlite-utils/graphs/code-frequency

qsera 2mo ago
I don't think volume of code changed was the metric the other commenter was asking for.
- deleted 2mo ago
  [deleted]
the_af 2mo ago
Isn't this falling into the "lines of code" trap TFA mentions? More code written is not a good measure of productivity. It could be garbage, or redundant code, or simply not addressing the real or more pressing needs, it could be building the wrong thing, etc. Like TFA mentions, it's been known for decades LoC is a misleading metric for productivity. It's one of the lessons of software engineering.
- simonw 2mo ago
  I'm planning an article at the moment in defense of lines of code. Saying "lines of code are a bad measurement" is too easy! It's about time someone presented an opposing argument. In my specific case, lines of code for my published open source projects is a metric that I trust, because I have high standards for those. I have plenty of other projects where I'll accept poor quality, unreviewed code (almost all of https://github.com/simonw/tools https://github.com/simonw/tools for example), but Datasette, sqlite-utils and LLM are not that. Of course, that's only useful for me personally and for people who trust me to stick to my own self-declared high standards!
  - otabdeveloper4 2mo ago
    > Lines of code are akshually a good metric now, because that's the only metric LLMs can optimize and I really, really, really love LLMs, they're the bee's knees. Really now?
    - simonw 2mo ago
      No.
  - skydhash 2mo ago
    > Saying "lines of code are a bad measurement" is too easy! It's about time someone presented an opposing argument. Maybe because there is none. One of the main quality of good codebase is simplicity. Which is about how easy for someone else to understand the code. It’s hard to define what simplicity looks like, so the best bet is to avoid the other side, making the code too complex. And you can make the code complex by shortening variable name, doing code golfing with quicks of the platforms, so smaller LoC. You can also go the other way and increase the LoC by adding unneeded abstractions, repeating slices of code,… There’s a window where the LoC is perfect to attain simplicity, but that amount is an effect of striving for simplicity, not a cause of it. And it’s variable for every problem. So you got something where the correct value is a different for each case. And trying to manipulate it artificially often results in complex code. And you want to say that is a good metric for productivity? And in the cases of your projects, there are a lot more info could share that are interesting, like the amount of issues (reported or found by you) that are tied to implementation bugs (coding, libraries API breakage,…) or design issues (requirements conflicts,…), documentation improvement,… Anything that is tied to the actual usefulness of the projects, and not fumbling around with code.
unknownfuture 2mo ago
The article mentions that coding is only a fraction of dev time and thus accelerating that part of the job can only create incremental gains, and oh PS, lines of code and similar metrics are a bad way if measuring dev productivity, anyway, and we've known that for decades. The OP claims AI accelerates non-coding parts of the job, too, and so the article is misguided. I ask for evidence. In response you give me... code output metrics?
- simonw 2mo ago
  I don't have anything else to hand that I can think of. I don't keep a time tracking diary.
  - discreteevent 2mo ago
    > I don't keep a time tracking diary. That's why Microsoft did a study (referenced in the article), where they measured the time spent on things, so they could get to the truth of how much time people spend coding using "a shape of evidence would you find convincing"
    - kylecazar 2mo ago
      The Microsoft study concerns the ideal vs. actual developer workweek. They conclude that developers using AI tools "heavily" are both more productive and more satisfied. And, surprise, that devs hate meetings and want to code more.