201–210 of 212 posts
How do you score this for lines of code per day. ?
> I've added 700k lines of code and deleted 747k (yay negative!).
Interesting that if you divide the added lines by the 7 years, and figure 250 days/year, he's phenomenally productive
700,00 / 7 / 250 = 400 lines of code per day, sustained over 7 year!
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.
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.
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
I'm male in my 40s with a CS degree. I work from home most of the time.
Earlier quoted context omitted.
Code is both asset and liability; the asset is the feature set, while the liability has an interest payment in the form of maintenance. The way you put it, you're optimizing for only one side of the books. The fact is that the value in a company is not in minimal clean code; it's in a recurring revenue stream, and ideally profits. Provide the most value with code which has low interest payments. Everything else being…
The distinction here is between code thats clear and concise or code that hacky and confusingly compact. Few people would recommend try and pack a 4-5 line function into a super complex and confusing one liner, but it is reasonable to put a 10k line class into a 20 line function. It's on us, as the developers, to make that tradeoff. I think the spirit of the comment you replied to was closer to the "clear and concise…
Earlier quoted context omitted.
Interesting so maybe the more accurate way to measure is increase LOC + decrease LOC.
Or even better, don't measure LOC.
Apply a few of these kinds of comparisons using different metrics, and you may be able to improve your estimates.
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: 70000/(22*11*10) = ~29 LOC / day Which is not too far from 10. There are days where I write 300-500 LOC, but I guess that a lot of work went into rewriting stuff and fixing bu…
I remember when I was prototyping an OpenGL thing on SunOS or a Renderman on same (maybe Solaris?), I was working ALL of the time and cranking out LOTS of code. Then refactor-refactor, fix technical debt, slowly add features without breaking, more automated tests, more platforms, and then, tada! My effective rate of coding (measured by LoC) was depressingly low.
I guess that I'm happy that it appears that I'm effective and relatively efficient, but I'm not the LoC-cranking-out machine that I thought I was. Sobering.
Earlier quoted context omitted.
Yes, this is exactly the type of boilerplate I am talking about. All those usings and try/catch blocks which add needless code. It is possible to compose all of this into an aspect which then decorates your methods. Maybe I'm not being clear, so here is what I mean. Say you have a method that does some work, but calls some other thing to do some auditing. The auditing is nice, but it failing shouldn't halt the world.…
There should only be one using/try catch block on the highest level. All of the methods being called within that using block should just throw errors. You could put the logic in attributes but I don’t consider a transaction a cross cutting concern. It would create a spooky action at a distance situation.
What annoys me most about these metrics is that some days zero lines are written. Anything up to a month without results to show. 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. There used to be one chap in the office that got all the…
It is of course the main metric for global warming, but it can be used badly or very well. Just like Lines of Code, it's hard to even get the measurement right. Do you measure it in the sun, or the shade? Do you measure it in a city which is relevant to the where most people feel the effects, or in the country so you get a repeatable environment. Similarly does LOC include comments and blank lines, what about patches - how do you count them? In terms of LOC per day, so you measure a single person who is churning out the code, or the entire team including the designers and documenters, and do you include the time after the project is completed doing support because of bugs?
I don't think you can blame the "temperature metric" for the bad ways it's measured or used. And I don't think you can blame Lines Of Code all of it's bad outcomes either.
Web devs: don't think this applies to you. 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 yo…
This is why people push the most difficult tasks to the most junior developers. Because a dev stuggling to do the 'impossible' looks the exact same way. That way others get to protect themselves from blame.
Who does that?
The correct thing is to manage expectations and then do the work. Unfortunately there are many lazy developers (or people in any sort of job) who won't be productive with even the most simple tasks.
Earlier quoted context omitted.
Whenever I spend a week without progress I feel like dying. In college I was used to be able to churn immense amount of code. Even if most of it was useless, I'm not well adjusted for long productive-less periods. How did your manager react to these times ? no remarks ? nagging ? trusting ?
College coding is very misleading. It's usually clean-sheet, by yourself, with idealized requirements and few dependencies. It's rarely robust or tested extensively, and its lifespan is short. It's also a hell of a lot of fun... which is why it's not really what you get paid for. What you get paid for is the long, tedious slog of the real world: maintaining existing business logic, teasing out user requirements in a…