I did some trivial math. Redis is composed of 100k lines of code, I wrote at least 70k of that in 10 years. I never work more than 5 days per week and I take 1 month of vacations every year, so assuming I work 22 days every month for 11 months:<p><pre><code> 70000/(22*11*10) = ~29 LOC / day
</code></pre>
Which is not too far from 10. There are days where I write 300-500 LOC, but I guess that <i>a lot</i> of work went into rewriting stuff and fixing bugs, so I rewrote the same lines again and again over the course of years, but yet I think that this should be taken into account, so the Mythical Man Month book is indeed quite accurate.<p>However this math is a bit off because in the course of such 10 years I wrote quite a number of side projects, but still, max ~50 LOC / day.
What annoys me most about these metrics is that some days zero lines are written. Anything up to a month without results to show.<p>Where, then, does all this time go? Sometimes it's reading existing code. Sometimes it's learning about a new algorithm by reading blogs and papers. Sometimes it's developing test programs to iron out a bug or test out some new code.<p>There used to be one chap in the office that got all the hard problems - the seriously hard problems. Some of this was figuring out why USB couldn't transition from low-speed mode to high-speed mode reliably (USB is quite hard to probe due to frequency), or figuring out why the application crashed one in a million boots.<p>Some of our most valuable developers committed the least amount of code, but saved our arses more times than I can count.
Not quite sure what point the author is trying to make? He agrees that lines of code are a bad measure of productivity because, yet claims that the average he computes can help him predict future development times. Then he explicitly points out that different parts of the codebase required different amounts of work, apparently unrelated to their code line count, yet does not relate this to the previously mentioned points. Also, what is up with the random comment about code coverage at the end? That doesnt fit in with the rest of the article either...
My current task is to implement a feature and I wrote about 50 lines during the last 2-3 weeks. I'm not slacking off, just examining the codebase and planning. I did collect about ~25-50 lines of notes per day though, so it's not like I'm keeping everything in my head. To be fair, the codebase is new to me, so I don't expect to keep this tempo for very long.<p>If I had been pressured to start writing code immediately it would have been more difficult to comprehend the codebase, thus slower, or even worse I would have introduced anti-features or bugs.
<i>a professional developer will write on average 10 lines of code (LoC) day.</i><p>My experience so far is a <i>team</i> of developers can deliver 30-100 LoC per day of front-end code.<p>The team size is of little consequence. It's been hilariously consistent across projects and companies I've been in.
10 lines per developer day - this is so outdated it should be disregarded entirely. Not much is gained from writing articles around this "10 lines a day" assertion unless you're writing something about computing history.<p>Maybe this was true when people were writing operating systems in assembly language - which is the time and context in which The Mythical Man Month was written.<p>Lines of code per day really is a pretty meaningless measure but having said that there is at least some truth to it, in that any developer who is writing a typical 21st century application and getting only 10 lines of code per day written, should really examine if they are in the right job.
Anyone else feel sad when you remove a bunch of code? All those man-hours it took to write that code, and now I'm deleting it all. I believe it's called sunk cost fallacy. I often wish I had a time machine so that I could go back in time and say, hey, this will all be deleted a year from now, go with the other solution instead.
My company has been experimenting with doing our feature estimations in LOC changed instead of points (1, 2, 3, 5). The general idea being that point estimation can vary between engineers based on ability, but LOC changed should be similar among engineers. This is supposed to make it easier to answer management's favorite question of "How long is this gonna take?". The answer is calculated using a team's historical average LOC/hr rate.<p>It remains to be seen if our estimates are any better.
Over the last 2 months I’ve managed about 3k new loc and 90 classes, so that’s about 60ish lines per work day. I don’t feel like I was that productive though and spent a lot of time refactoring. Eg, last 1k lines barely added any features<p>What do you do to keep up a fast pace in a big project without throwing quality out? They say TDD increases your speed overall, according to a few case studies I found (15% longer to code, but 40% less bugs, so faster finish times overall etc)
That book was written in the seventies, 45 years ago. It still has valid points but obviously a few things have changed in terms of how we do things. For example, we use version control systems these days and have sophisticated refactoring tooling.<p>But one of the things that hasn't changed is that we haven't really come up with any better metrics than time spent and nr. of things changed per time unit. There are a lot of people complaining these things are not representative (for the last five decades) but not a whole lot of people coming up with better productivity metrics and even fewer that did the leg work of actually validating their work in something that might pass scientific scrutiny (which is hard). If you do work in this space, you'll find yourself citing articles that are decades old.<p>These days, I tend to look at the activity statistics on github projects when joining a new project. It tells me in a glance of an eye who are the movers and shakers on a project in terms of lines of code added/removed and amount of commits and the time distribution of those commits. It's not perfect and doesn't tell you the complete story but it it's rarely completely wrong. Usually it's quite easy to spot patterns like Weekends, Christmas, vacations, and that people tend to get back energized from a good break (a little spike in productivity).<p>Also these numbers confirm the notion of a 10x programmer: a handful of people tends to be responsible for the vast majority of commits and line changes. Not all software engineers are created equally. Diffstats on pull requests tell me a lot as well; though of course these numbers are inflated by e.g. refactorings (more so on languages that have proper tools for this). But refactoring is a good thing and combined with code reviews tell you a lot about the quality of engineering.
We should probably be using the absolute value of lines of code, so abs(LOC) as the metric, or something like a least squares mean for estimating the moving average of LOC per day.<p>Anymore, my daily average LOC is probably negative since I tend to rescue floundering projects. I usually avoid object-oriented (OO) programming whenever possible, as I've found that functional one-shot code taking inputs and returning outputs, with no side effects, using mostly higher order functions, is 1 to 2 orders of magnitude smaller/simpler than OO code.<p>Also I have a theory that OO itself is what limits most programs to around 1 million lines of code. It's because the human mind can't simulate the state of classes with mutable variables beyond that size. Shoot, I have trouble simulating even a handful of classes now, even with full tracing and a debugger.<p>I'd like to see us move past LOC to something like a complexity measurement of the intermediate code or tree form.<p>And on that note, my gut feeling is that none of this even matters. The world's moving towards results-oriented programming, where all that matters is maximizing user satisfaction over cost of development. So acceptance test-driven development (ATDD) should probably be highest priority, then behavior-driven tests (BDD), then unit tests (TDD). On that note, these take at least as long to write as the code itself. I'd even argue that they express the true abstractions of a program, while the code itself is just implementation details. Maybe we should be using user stories implemented per day as the metric.
My project at work is 60k LOC, developed over the course of 3 years. It's in production and works quite well. I wrote it all by myself. My hobby project is 100k LOC (2.5 years of development in free time). Both are UI + service code in C++. I code several hours a day. Maybe 3-5 on average.<p>10 LOC/day is ridiculous. Think about Brad Fitzpatrick, Fabrice Bellard, John Carmack. They would never accomplish anything like they did with those 10 LOC.<p>You have to have dedication and really good text editing skills. Being smart is nothing if you can't write code fast enough. Good skills with tools like shell, debugger, version control are important as well.<p>Another problem is that dev collectives these days tend to bully and punish those with higher performance. There are several reasons for that 1) most devs do an absolute minimum just not to get fired 2) job security is a thing, you won't make your project look too simple or complete as this might end your contract 3) at least 90% of hype is from idiots and by idiots. Idiots are a heavy tax on any engineering 4) frameworks, tools and methodologies are often designed for a different scale 5) ceremonia, overcomplication of development processes, treating devs like anonymous, interchangeable units<p>I'm male in my 40s with a CS degree. I work from home most of the time.
Guys, can I be honest? I have never actually met anyone who has worked in a LOC-optimized company. This stuff seems like the outrage porn of software engineering.
I did some analysis of my own projects and came up with around 50 LOC per day:
<a href="https://successfulsoftware.net/2017/02/10/how-much-code-can-a-coder-code/" rel="nofollow">https://successfulsoftware.net/2017/02/10/how-much-code-can-...</a><p>But:
-As a 1-man-band I also do the support, documentation, testing, website, marketing etc. So coding is only part of what I do.
-I don't think the article defines what a LOC is. Does it include headers? Does it include auto generated code?
Another post currently on the front page has a great example of this: <a href="https://news.ycombinator.com/item?id=22306002" rel="nofollow">https://news.ycombinator.com/item?id=22306002</a><p>How do you score this for lines of code per day. ?<p>> I've added 700k lines of code and deleted 747k (yay negative!).<p>Interesting that if you divide the added lines by the 7 years, and figure 250 days/year, he's phenomenally productive<p>700,00 / 7 / 250 = 400 lines of code per day, sustained over 7 year!
I wish I had a job where writing 10LOCs per day would be enough. I wrote quarter of a million LOCs at Google alone, and I wasn't the most prolific programmer on the team, not even close. I wrote about as much code since I left Google, too. And it's not Java code either, where your IDE has to crap out 100 lines of boilerplate before you even begin to do anything meaningful. This is mostly C++ and in the last few years Python as well.
The 10 LOC/day includes the entire project, including analysis, requirements, design, documentation (user and tech), test, management etc, in a large project. Saying (as many do) that an individual programmer has produced hundreds of LOC per day is to miss the point.<p>You have to start by defining your terms of reference and make sure you are comparing like with like.
If you are doing a good refactoring, you may have a massive negative LoC at the end.<p>LoC added or removed is not a very good metric for anything.<p>Except if I see a big negative number on a PR, it is usually a great thing. I still have to check what was removed but it usually mean that things are easier to understand.
I'm not sure I add 10 lines of code, on average, to our products a day. Most days are probably negative, to be honest.<p>Of course, any time I have to add a new Windows Forms dialog to our install/config utility, there's a couple thousand lines of code-behind added to the repo...
How I explain why LoC is a bad metric to non-techsavvy people.<p>3 +<p>3 +<p>3 +<p>3 +<p>3 +<p>3 +<p>3 +<p>3 +<p>3 +<p>3 +<p>3 +<p>3 +<p>3 +<p>3 +<p>3 = 45<p>And so is 3 * 15.
I've never found LOC as a useful metric for productivity. Lines of code are most definitely not born equal.<p>So what's this obsession about it? Is it managers who can't or don't want to properly evaluate the performance of the people they're managing?
A good bricklayers places MORE bricks in a day than others.<p>A good construction engineer builds a house using LESS concrete that others.<p>I'd rather be a good software engineer than a "x10 developer".
Does anyone else question the mythical man month? If I accept the basic assumption of the mythical man month then I also have to accept that NYC is a myth - there is no way that a city that size can possibly function. Lets start out with ten people in NYC and they add ten more people .... My own belief is the MMM is an apologists view of how we currently collaborate to develop software and products.
Seems about right, on the average day, you put about 500 in. the average year later, you're lucky if 10 of those are left.<p><i>sits back waiting to be told how badly I suck and something about code churn and patterns</i>
Am I mad? Did anybody actually read the article? Why is everybody piling on LoC/day when the article is about average LoC over a period of time and how it correlates to the work you're doing and what a realistic average LoC might look like for a sane project. From this point of view, it doesn't matter at all if you deleted 20k lines and have a negative LoC for the day. That's missing the forest for the trees.
Web devs: don't think this applies to you.<p>If you're pushing up 0 lines of code on a day where you had no meetings or interruptions, and you aren't working on something truly novel and near-impossible, you took the day off on the company dime. And everybody you worked with noticed, and if you do it regularly - they are just waiting for everybody to reach their breaking point with you so they can push to get rid of you. Sure, you'll find a new job and do it again, but you'll still not have anybody's respect.