Very interesting to reflect on the amount of time needed to write a technical book on a programming language. If I compare that to amount of time taken to write code (and forgive me for the horrible KLOC metric), I think one could easily average about 300 lines of good C++ code (including tests) per day on a new project -- probably more if you are working alone, but let's keep it conservative. So about 37.5 lines per hour * 1350 hours = ~50KLOC. Say half of it is tests, so that's a medium sized app.
I don't know why, but writing a book seems waaay more effort than churning out ~25 KLOC of tested C++. I guess it is what you are used to...
* 300 lines per day is what I averaged over a multi-year period when I was a C++ programmer. But that was more than a decade ago, so I'm guessing it would take less lines of code with "Effective Modern C++" ;-) (and yes, I measured it for interest sake...)
> I don't know why, but writing a book seems waaay more effort than churning out ~25 KLOC of tested C++.
It is. I wrote a programming book, and the code for each chapter was always a breeze compared to writing the prose.
I rationalize it by thinking of English as a programming language. It has a fantastically complex syntax and semantics, tons of undefined behavior, and a few billion interpreters out there, each with a large number of quirks and bugs.
Writing a program in English that does the more or less correct thing on all of those interpreters ain't easy.
I'm actually finding it hard because I feel like I need to re-write all the old chapters each time I write a new one.
The problem is as I go from A to B to C when I get to D I realize I really want the code to be in a different shape. But to do that I either need to make a C' where I take a timeout to explain why I'm refactoring the code before I move on to D. Or, I need to go re-write A, B, and C so they fit directly into D.
Making C` sucks because it's irrelevant to whatever the topic is. But re-writing is also a ton of work.
You could argue I should start at Z and work backward but I'm writing as I go so I don't know what Z is yet.
Ditto. I'm almost finished writing a book Ansible (self published on LeanPub), and most of the difficult sections have had the code samples ready to go for months. Getting the code organized an laid out in a logical fashion with appropriate, short intros, descriptions, and summaries requires much more effort than the code itself!
300 lines of code per day ? Really, the LOC -measurement is highly dependent on what kind of project you are working on, and really doesn't tell much about what is going on with the project.
Don't know what the good metric is. Maybe functionality instead of lines of codes or kilobytes in the final binary. But how to measure functionality ?
300 lines per day sustained? that seems really high to me. what were you working on? didn't you ever spend days optimizing or refactoring with <= 0 net lines added?
300 lines is about what I averaged (I can't remember the exact number, but I remember it was about 50:50 split between test code and production code with 150 lines of production code a day). As another commenter mentioned, it was new code and it was C++ (old style). It's easy to crank out header files (as long as they don't contain templates...) Definitely spent time both optimizing and refactoring large portions. It's the average over time. So some days I might write 1000 lines and others, net negative code.
As another person mentioned it really depends on the project. If you are using big frameworks then you can't write code nearly as quickly because you are constrained by the design of the framework. Also if you are green fielding everything, then you get to write a lot of infrastructure code. I get paid to write Ruby on Rails code these days (among other things) and there is no way that I would average 300 lines of code a day even with tests. A huge part of my day is wrestling with Rails and trying to understand what the heck it is doing.
Lots of other things can slow you down. Your coworkers for instance -- constant squabbling over one issue or another can easily eat up half the day (or more). Having a constant stream of requirements is really important too. It's easy to get stalled trying to figure out what you should be doing. It's also easy to get paralysed by indecision and be afraid to write code because you don't want to fix it later. Many, many things can slow you down. If you have a situation where these things aren't getting in the way, you can write quite a lot of code.
At the time I was measuring my output, I was on a phenomenal team. We were writing Windows applications (notably without MFC ;-) ). Working with them pretty much approximated what I think I could do if working alone (i.e., the communication overhead was pretty much 0), so I thought it was a reasonable comparison.
I don't know why, but writing a book seems waaay more effort than churning out ~25 KLOC of tested C++. I guess it is what you are used to...
* 300 lines per day is what I averaged over a multi-year period when I was a C++ programmer. But that was more than a decade ago, so I'm guessing it would take less lines of code with "Effective Modern C++" ;-) (and yes, I measured it for interest sake...)