Going Fast Slowly
varnish-cache.org
Going Fast Slowly
1–10 of 29 posts
Re: Going Fast Slowly
#2Is this is pinnacle of vapid blog spam headlines?
Re: Going Fast Slowly
#3>> Varnish has been in existence for 10 years, so that's 15K lines per year. 200 workdays a year makes that 75 lines a day. 7.5 hours of work per day gives 10 lines per hour.
You can't really say that, though.
Let's roll back the clock to when the project was new and say, only 10k lines of code. Maybe that first 10k was written in a month. Fleshing things out, then adding features like crazy. Coding in a euphoric state.
Once you've reached a certain amount of code, you're doing maintenance. Fixing bugs. Re-factoring code. I can see 10 lines of code per day. I notice that in my own projects. I might write a few thousand lines in a week and then as time goes on, I write a few hundred, then a few tens, then maybe just a couple edits.
Re: Going Fast Slowly
#4>> Varnish has been in existence for 10 years, so that's 15K lines per year. 200 workdays a year makes that 75 lines a day. 7.5 hours of work per day gives 10 lines per hour. You can't really say that, though. Let's roll back the clock to when the project was new and say, only 10k lines of code. Maybe that first 10k was written in a month. Fleshing things out, then adding features like crazy. Coding in a euphoric sta…
> Coding in a euphoric state.
You must be fun to code with.
Re: Going Fast Slowly
#5Slovak proverb: "ponáhľaj sa pomaly" -- Be not hasty, when you hurry.
Re: Going Fast Slowly
#6"I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided."
Good quote. Took me until my 30s before I started realizing this myself. Seems obvious in retrospect.
Re: Going Fast Slowly
#7Looking at the static picture is somewhat misleading. The lines of code you see in the current baseline snapshots are not all the lines that were ever written for that project.
A fairly large and extensive commit affecting many lines can have a small impact on the absolute number of lines (which can even shrink). We change as well as delete existing lines, not only add new ones.
The lines which are replaced by new lines should be regarded as deleted lines, and so the figure of how many lines there are now should be supplemented with how many lines were deleted since the beginning of the project: how many additional lines of code exist in the repo's history, which no longer appear in the current baseline.
The invisible lines that disappeared in the history are the underpinning for the current lines; they enabled the new lines to be figured out, which took work. Someone had to write each line, and it has to be counted in the LOC output.
It is not entirely clear cut. If you make a trivial change in some existing line, it's not the same thing as a brand new line. Yet, according to the line-based diff tools, it looks like a deletion and addition of an entire line. Minus this, plus that.
Re: Going Fast Slowly
#8Is this is pinnacle of vapid blog spam headlines?
[deleted]
Re: Going Fast Slowly
#9"I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." Good quote. Took me until my 30s before I started realizing this myself. Seems obvious in retrospect.
I'm only one year out of uni and I figured this too. Lines of code are features and state that will increase the cost of other new features. So adding lines is a cost. The hard part is figuring out what lines of code (features) to add, do them well, and which ones you should not even make.
Re: Going Fast Slowly
#10"I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." Good quote. Took me until my 30s before I started realizing this myself. Seems obvious in retrospect.
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” -- Bill Gates