Ask HN: How much code do you write a day? | Hacker News Reader

Ask HN: How much code do you write a day?

20 pointsaaronarduino41 comments

I'm curious about how much code most people write in a normal working day as a programmer.

I am looking into changing careers to become a programmer and want to know how much code one would be expected to write in a day.

Example:

Profession/position: --

Code: - x amount lines of code / x amount of issues, etc.. closed

View on HN

Lines of code is a terrible way to measure the output of a programmer. If the company you're joining bases anything around lines, you should consider looking for another company.

One reason is that high quality code is concise leading to less lines. If devs are measured by how many lines they write, that leads to writing verbose / long / bad code. I really enjoy pushing up a negative lines pull request.

There really aren't any good objective metrics. I've seen and heard of some companies measuring programmers by scrum points, but then it leads to either inflating the point numbers, or shipping large amounts of low quality code to look better on paper. Really what it does is shift the burden of fixing your code and making it production grade onto the other members of the team.

I've always wondered if the productivity metric chosen could adversely affect the code quality. I think this answers that well. The more LOC you have the higher technical debt you will have and thus to have LOC or scrum points as a metric is basically encouraging technical debt.

scrum points are different then lines of code. scrum points are based on the complexity of the problem and LOC is based on how inefficiently you can code a problem.

^ I agree with this. My main point is that LoC is always a bad metric. Scrum points can be a bad metric if misused for purposes other than estimating the effort required to solve a given problem.

One thing to consider is if the programmer "owns" the code through deployment into production. If that is the case then the focus is working software not LOC or story points or velocity or tickets closed.

It's much better to have a flow that allows for continuous delivery of working software with monitoring, etc. rather than focusing on counts of things that don't matter. Do customers care about how many story points happened last sprint?

If management is focusing more on metrics than working software - then they will get people to focus on that as well over working software.

I used to track "time in production" along with "lines written". It was really interesting to weigh "time in production" for lines of code to see how rushing to get more lines in ended in us rewriting more and more of a developer's code.

How much of the long serving lines are bit's that no one wants to touch anymore and are constantly worked around? Sometimes those lines will have enough technical debt attached that the business will not even consider updating/extending those parts of an application.

Those are what we call 'core components' and they are never 'rewritten'. Because it's cheaper to throw more cloud RAM at it than to rewrite it.

> The more LOC you have the higher technical debt you will have and thus to have LOC or scrum points as a metric is basically encouraging technical debt.

There's a correlation, but it's more subtle than that. Often simpler but repetitive code is less technical debt than the less code but more complicated version.

The more complicated and harder to understand the code the longer it takes to change/fix/refactor leading to wasted time.

You wouldn't know this because you're new to the industry, but lines of code is considered a very poor metric for productivity. If you encounter an employer who is tracking your productivity by lines of code, that's a really bad sign, and you should try to avoid working with such a company.

The same is true of number of issues closed. Some issues are short and quick, and some issues take a whole day. Sometimes an issue will seem small and turn out to be large. Handling these things is part of good management.

I personally measure people more on how many bugs they don't produce. A single bug can cause losses of revenue that are equivalent to weeks of a developer's time. Bug-free code is so much more cost-effective than fast code.

Thanks, your answer has shed some light on what would be expected. I am glad that the industry does not base productivity on LOC. I also, now know some red flags.

What matter is not the number of lines of code you write. IT's what value you create, how much revenue you generate, or help generate. You can have the worst code, and still make hundreds of millions of dollars. At the end of the day, for a business, that's what matters. Once you are coming to the scale of the code (modularity or lack thereof, etc), you can always rewrite.

Not directly about development, but this should be somewhat of a rule of thumb in general: https://www.slideshare.net/dmc500hats/best-strategy-is-speed...

Time is important. More important than you think.

The value created for the company seems to be the best way to track productivity. It seems that how accurate the chosen metric for the value created is the key thing to watch out for.

Err, I will disagree on this. It all depends on where you work at.

You can have a bugfree code, but release it in 6 months. Or you can have a code that creates outages once per month, but release it in 3 months (figure of speech, 6 months is optimistic for some projects).

By trying to optimize for 0 bugs, you are losing on the 3 month of business opportunity of high revenue. At FANG scale, that's a lot of money.

Disclaimer: G employee, but this is my own opinion etc.

I think you've intentionally taken what I said to an extreme that makes it absurd. Of course I wasn't saying people should comb through a program until it's bug-free before releasing it.

That said, no one (in their right mind) intentionally releases buggy code. They may release incomplete or under-tested code, of course. But that's not what I'm talking about.

I'm saying that when someone feels like they're "done" (in a reasonable amount of time), some people will end up with more bugs than others. If the trade-off is 3 more hours of work for 1 fewer bug, that's an incredible economy.

And, of course, no metric is perfect or comprehensive. But "bugs per hour" is much better than LoC per hour.

FANG = Facebook, Amazon, Netflix, Google

Surprisingly little! Now that my project for behavioral and cognitive changes (http://willyoudidyou.com) is built out, a lot of my writing is actually... writing. Which is something I never thought I would be doing, as a web developer launching a software project.

So a lot of my energy has shifted from wring clean(ish) and maintainable(ish) code, to writing coherent articles for content marketing.

But when I was building it out? some days I would sling quite a lot. Other days were spent just tinkering with CSS to get the layout or experience down right, or doing research on the best way to do something.

Some people also, write really fast code. and other people are more methodical. So, take any comparisons you make in that regard with some salt; what's possible for others might not be for you, and visa versa.

But generally, the expectations are based on todos like adding a feature or interface, which is known to represent some kind of easy/medium/hard difficulty - which may also be contextual to the developer when domain knowledge comes into play. So the expectations vary from one dev to another based on experience, familiarity, and known unknowns.

Almost always a small fraction of the code that I read in the process of finding out how exactly to add an enhancement to existing code. Read, think how the problem fits in, read more, maybe code some little experiments to see how part of the problem will be interfaced, read more, etc. More skimming than perusing, if it's part of the codebase that you're familiar with.

Number of issues closed: Depends on what I'm doing. Short little maintenance things can take less time, and you can clear a bunch in a day. Some individual features will take weeks or months to code, depending on how deeply new changes need to infiltrate into old code, the size of the change, how much work you depend on other teams to do to provide ancillary features to support your work, etc.

My team's more of a "fulfill the requirements; do it right" than a "move fast and break things", because our products are backup applications. I suspect that this changes the tempo of the work, compared to how other teams might function.

I've found, in recently returning to writing software as the main role, that I spend more time thinking about what to write and maybe doodling out some diagram-like pictures then actually typing characters.

Now that may be different if you are starting a greenfield project or banging out a prototype.

There are a lot of repetitive things we do, which can drain your brain, and like any other job you are also likely doing the work for a company/someone else which means they define what it is you are building/fixing. So make sure you are motivated to be a professional about programming. That means being able to grind through the "this is just like that other thing, but slightly different enough that I can't re-use that other thing", etc.

The reason I became a programmer was to not have a repetitive lifestyle and I think it's pretty easy to accomplish that. I always have new problems to solve which require new techniques to be used and anything that gets done repetitively? Just automate it.

Although I do completely agree that about 90% of my work is actually thinking about how to implement a problem as opposed to actually implementing it.

If you're rewriting tens of functions that are almost identical, you should probably consider finding a different way of organising your code (even if there are minor differences between the functions).

I was more referring to the repetitive nature of CRUD apps and how work sort of repeats at a high level but details are different enough that it feels a little repetitive. Also keeping tests isolated tends to lead to repetition since you don't really want dependencies there.

It's almost impossible to say. Last week I wrote a serializer for a specific subsystem. I spent two days screwing around; on the third day I wrote the whole thing; fixed a couple of bugs on the morning of the fourth and then refactored it a bit to improve error resilience and to integrate with some recovery routines for network transience. Friday I checked in some test routines which caused me to read through everything and tweak a couple of things in the implementation.

By then end, perhaps 1500 lines of code, but how long did I spend writing it? Four days? Three? One? (the fourth day's work ultimately didn't add many lines of code though every file was touched and had to be checked in again).

As previously mentioned, that metric is not at all helpful. Recently I ended up just committing a single digit for the day and researched all day what the appropriate number would be.

For me, when creating a project, research seems to be where my effort goes. I spend a lot of time finding a good way to solve a particular problem or learning how to use a specific API. So this thread has been encouraging, knowing that I am not pressured to write lots of code but to have well-working code that solves a problem correctly and provides value to the company.

It would depend upon the project. Pretend your question was:

* I'm thinking of writing a book, how many words should I use?

The answer is very varied. I read a book to my son at the weekend. 20 words, at the most. The book I'm currently reading is in the region of 1500 pages. Many words.

Code is like that. Today I might have written negative 100 lines, and been productive. Tomorrow I might write a template-generation system and have a net positive of a few thousand. It all depends, so much.

it depends, when implementing an algorithm it can be 10 lines of code, if working on new GUI feature it can be 500-1000 lines

Varies wildly. It's like trying to measure a driver's performance in degrees-of-steering-wheel-turned-per-hour.

Overly-aggressive negative LoC competition can also increase technical debt and support issues, if taken too far.

I think being quick and responsive to consistently deliver what customers need is more important... because without profitability and useful utility, code is mostly academic.

(Moderation in all things, including moderation.)

Some days, you can spend the whole day just reading and tracing code and trying to make sense of what it does. After that, implementing a feature or bug fix might involve changing just 15-20 lines.

Hence, taking time to write more readable code may lead to writing code sooner and/or faster in the future.

For the most recent machine learning code I wrote I spent 20 hours thinking into 10 lines of code.

I started a project about a year ago. I've spent about 70% of my work days on it and wrote about 50% of the code.

git diff --author="<me>" initial_commmit..@ --shortstat

969 files changed, 29501 insertions(+)

Total LOC for the project is 17514.

I don't know if that helps you, but it was fun to look up.

Is there a one-liner that I can point to git, so it'll display the amount of lines updated? Caveat: it has to ignore days without commits (weekends, days off).

My favorite application to do this is git-quick-stats[0]. Then just multiply by something value (maybe 7/4.8) to calculate an estimate of the number per workday. For me, it appears to be roughly 500 lines per day. However, this is just a side project I work on in my spare time. This is a mean though, not a median (which would probably be more fitting), so should definitely be taken with a pinch of salt.

[0] https://github.com/arzzen/git-quick-stats

amount of time

coding: 20-30%

designing(thnking) issues:

unit testing: less than I should

documentation: 20%

on HN: more than I should

on the internet researching an issue/feature: 10%

in useless meetings: 10 hours a week

in productive meetings: ?

talking/chatting/emailing about an issue/feature: 20-30%

It depends on the day. One day I might bust out a 1000 other days like 10-15. Way too many meetings, design reviews, code reviews etc. So much waste of time.

Meetings are often useless because they're put on too much, but I find that code & design reviews are one of the most important parts. Not only does it benefit the company (having cleaner & more efficient code will remove later code bloat), but it also benefits you by learning from other peoples experience. That being said, there have been times where code reviews aren't done well. If code reviews are based upon fact, I find they often go significantly better than those based upon opinion.

I've been trying to debug something all morning. So I've written about six debug statements so far today.

In case anyone was wondering, it was a caching issue. One of these day I'll remember to look there first before pouring through the code for hours.

iOS developer

So far today: 13 lines of code. 5 issues closed.

333 lines today. No issues closed yet. On days when I am fixing issues, I average about 1 1/2 issues closed a day.

Reply on news.ycombinator.com