How fast are you supposed to write code?
Pages: 12
This is a question for those who are working as programmers or retired coders.
While at work, how many lines per minute on average are you supposed to write at a minimum before your boss decides you lack XP and fires you?
Open source and private projects do not count, I just wanna know how fast are you supposed to be, it doesn't have to be per minute because ofc., deubgging for ex. doesn't imply writing code so it depends, but on average, how much code?
While at work, how many lines per minute on average are you supposed to write at a minimum before your boss decides you lack XP and fires you?
Open source and private projects do not count, I just wanna know how fast are you supposed to be, it doesn't have to be per minute because ofc., deubgging for ex. doesn't imply writing code so it depends, but on average, how much code?
I think it depends on what you are doing... new code or enhancement, at the very least, but also whether its a large amount of 'easy' code or tougher work where you need to go slowly and think through it.
Usually you want the middle -- up to a point (where its hard to read or modify) less code is more usually, so working smarter should be rewarded. Every line you write has to be debugged and later, read by someone in order to modify it or debug it or whatnot.
I am not sure there is any one answer. On an easy, from scratch project, I can probably produce 5 or more pages in a workday. But on harder stuff, like debugging or retrofitting or whatever... I have had days where even 10 lines is tough. I recently had to fix an issue in a project I inherited where it said something like if (x == y) and it compiled, ran, and was totally broken. It needed if (x.foo() == y) ... but I was unfamiliar with the objects at hand and it was already coded up wrong, so spotting the error took over 2 days because someone had allowed the object to cast itself back to a legal but wrong value in the original == statement.
Usually you want the middle -- up to a point (where its hard to read or modify) less code is more usually, so working smarter should be rewarded. Every line you write has to be debugged and later, read by someone in order to modify it or debug it or whatnot.
I am not sure there is any one answer. On an easy, from scratch project, I can probably produce 5 or more pages in a workday. But on harder stuff, like debugging or retrofitting or whatever... I have had days where even 10 lines is tough. I recently had to fix an issue in a project I inherited where it said something like if (x == y) and it compiled, ran, and was totally broken. It needed if (x.foo() == y) ... but I was unfamiliar with the objects at hand and it was already coded up wrong, so spotting the error took over 2 days because someone had allowed the object to cast itself back to a legal but wrong value in the original == statement.
> While at work, how many lines per minute on average are you
> supposed to write at a minimum before your boss decides you
> lack XP and fires you?
Your boss clearly doesn't understand how software is written.
It isn't some repetitive task like an assembly line.
Nowhere I've ever worked in some 35+ years has ever measured productivity in this way.
The amortised average is something line one line of code per day, when you spread that time across the whole lifecycle.
- requirements aka "what do you want?" - LOC written = 0. Get this wrong, and you'll throw all of your later work away.
- design aka "how you're going to do it?" - LOC written = 0. Get this wrong, and you're rewriting large chunks of code.
- implementation/test/debug - in this 10% of the project lifecycle alone, you write a good 90% of the code. Here, you could be looking at high hundreds to low thousands of LOC per day. UI boilerplate code is easy, complex algorithms less so.
- system testing - depending on how well you did the previous steps, various amounts of code get changed. It could be just a few lines per week if you did your job well up front.
- release/maintenance - weeks or months may pass before a bug appears or your customer wants something added/changed.
> supposed to write at a minimum before your boss decides you
> lack XP and fires you?
Your boss clearly doesn't understand how software is written.
It isn't some repetitive task like an assembly line.
Nowhere I've ever worked in some 35+ years has ever measured productivity in this way.
The amortised average is something line one line of code per day, when you spread that time across the whole lifecycle.
- requirements aka "what do you want?" - LOC written = 0. Get this wrong, and you'll throw all of your later work away.
- design aka "how you're going to do it?" - LOC written = 0. Get this wrong, and you're rewriting large chunks of code.
- implementation/test/debug - in this 10% of the project lifecycle alone, you write a good 90% of the code. Here, you could be looking at high hundreds to low thousands of LOC per day. UI boilerplate code is easy, complex algorithms less so.
- system testing - depending on how well you did the previous steps, various amounts of code get changed. It could be just a few lines per week if you did your job well up front.
- release/maintenance - weeks or months may pass before a bug appears or your customer wants something added/changed.
| While at work, how many lines per minute on average are you supposed to write at a minimum before your boss decides you lack XP and fires you? |
Well you could easily write say 20 lines of gibberish compilable lines of any code per minute, every minute. The code would probably be nonsense and will likely not produce any expected output - but would satisfy your boss on this criteria.
If your boss is going down this road then a much more realistic measurement is average number of correct, working, tested and debugged lines of code per day for new code. But as program design is a very important part of programming and doesn't produce a single line of code how is your boss going to measure this?
As per Salam_c above, I've never been involved with this type of productivity measurement in practice. If one of my old managers had tried to introduce something like this, I'd have left.
Last edited on
Thank you guys, I get your point and agree with that.
I'm not employed nor did I ever work as programmer so I don't know what a company would want from me, I was just curious about how fast real world coders are.
The reason why I asked this is because I was looking at my commits on GitHub and then computed the average per minute, which is btw. 1 line per minute.
I don't know if that's fast or slow but I do spend a lot of time on design and thinking, if I ever get employed and the boss tells me I should write more and think less then I would surely quit a job before he fires me lol.
I suppose you agree with me as well.
I'm not employed nor did I ever work as programmer so I don't know what a company would want from me, I was just curious about how fast real world coders are.
The reason why I asked this is because I was looking at my commits on GitHub and then computed the average per minute, which is btw. 1 line per minute.
I don't know if that's fast or slow but I do spend a lot of time on design and thinking, if I ever get employed and the boss tells me I should write more and think less then I would surely quit a job before he fires me lol.
I suppose you agree with me as well.
| if I ever get employed and the boss tells me I should write more and think less then I would surely quit a job before he fires me lol. |
:) :)
The only time I'm aware of when measuring lines written per minute was employed was for the old designation of 'coder' who took a flowchart produced from an analyst and slavishly translated that flowchart design into code - no thinking required! But this type of 'job' went the way of the dodo many decades ago...
One of my most productive days was throwing away 1,000 lines of code.
— Ken Thompson
Honestly, it does not make any sense at all to measure how many lines of code per minute a programmer writes, because it totally ignores code quality, or how complex the problem is that you are working on. Contributing to a project is not necessarily about adding more code. In fact, adding a lot of "sloppy" code can easily ruin a project! It's all about improving the code and coming up with a "good" design, which ensures maintainability in the long term. Often, a shorter and more condensed code can be much better – and take a lot more time to come up with than a longer/sloppier solution. Carefully designing a 10 lines function may require more skill and time than dashing off a 1000 lines function. Furthermore, in a real world project, you can easily spend days hunting for a nasty bug, just staring at the code. In the end, the fix will often come down to changing/fixing a single line of code. Still, getting rid of the bug will be a very valuable achievement.
— Ken Thompson
Honestly, it does not make any sense at all to measure how many lines of code per minute a programmer writes, because it totally ignores code quality, or how complex the problem is that you are working on. Contributing to a project is not necessarily about adding more code. In fact, adding a lot of "sloppy" code can easily ruin a project! It's all about improving the code and coming up with a "good" design, which ensures maintainability in the long term. Often, a shorter and more condensed code can be much better – and take a lot more time to come up with than a longer/sloppier solution. Carefully designing a 10 lines function may require more skill and time than dashing off a 1000 lines function. Furthermore, in a real world project, you can easily spend days hunting for a nasty bug, just staring at the code. In the end, the fix will often come down to changing/fixing a single line of code. Still, getting rid of the bug will be a very valuable achievement.
Last edited on
| One of my most productive days was throwing away 1,000 lines of code. |
This, of course, begs the question - where was the design? :) :)
The quote is in 'The Art Of Unix Programming'
draft - https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.110.5490&rep=rep1&type=pdf
final - https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.126.543&rep=rep1&type=pdf
The book is well worth a read - if you don't use/program Unix.
Last edited on
Meaningless productivity stats such as LOC result in
rather than
Hey, give that first guy a 3x pay-rise. He's obviously so much better than that other slacker.
|
|
rather than
|
|
Hey, give that first guy a 3x pay-rise. He's obviously so much better than that other slacker.
^^ and another one, counting ;s leads to
//;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
as a break between functions or to surround comment blocks etc.
//;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
as a break between functions or to surround comment blocks etc.
salem c, I'm sure we all saw even uglier code style than that, but we are talking about work place, I don't think at work every coder has it's own style.
Everybody eventually writes some code.
I always wondered, how much do people at work have tabs open in web browser to docs and similar while working?
One person may spend hours reading docs, another one may waste less time, obviously the one which doesn't read docs as often is able to write more.
Everybody eventually writes some code.
I always wondered, how much do people at work have tabs open in web browser to docs and similar while working?
One person may spend hours reading docs, another one may waste less time, obviously the one which doesn't read docs as often is able to write more.
> I always wondered, how much do people at work have tabs
> open in web browser to docs and similar while working?
All the time.
It's impossible to remember every nuance of a sprawling API.
> obviously the one which doesn't read docs as often is able to write more.
Write more mistakes - sure.
Or ends up reinventing the wheel when there was an API call to do that work.
Or ...
Being a programmer has nothing to do with how fast you can press keys.
90% is understanding the problem and knowing how to solve it - it's all brain work. If you don't know those things, you're screwed.
Memorising an API doesn't make you a programmer any more than eating all the meals at a restaurant will make you a chef.
> open in web browser to docs and similar while working?
All the time.
It's impossible to remember every nuance of a sprawling API.
> obviously the one which doesn't read docs as often is able to write more.
Write more mistakes - sure.
Or ends up reinventing the wheel when there was an API call to do that work.
Or ...
Being a programmer has nothing to do with how fast you can press keys.
90% is understanding the problem and knowing how to solve it - it's all brain work. If you don't know those things, you're screwed.
Memorising an API doesn't make you a programmer any more than eating all the meals at a restaurant will make you a chef.
| 90% is understanding the problem and knowing how to solve it - it's all brain work. If you don't know those things, you're screwed. Memorising an API doesn't make you a programmer any more than eating all the meals at a restaurant will make you a chef. |
Very interesting, I think I'm going to look for a job then some time.
My impression was that one needs to have API's memorized to be efficient, the only thing I still don't know is networking and assembly but that shouldn't be too hard to learn.
In broad terms, knowing what an API is capable of is a good thing.
Basically, read the overviews carefully a few times, and maybe dig into some of the areas that particularly interest you.
Like you're writing a UI. You need a button, and you know the API can create buttons, and you know roughly where in the documentation to find out how to use a button. A few seconds later, you're golden.
But if all you know about the same API is how to bash pixels on the screen, you're screwed, no matter how good you are elsewhere.
For example, I want to find a string within a string.
Is it
char *strstr(const char *haystack, const char *needle);
or
char *strstr(const char *needle, const char *haystack);
I know it exists for sure. But if I haven't used it in a while, and I'm at all unsure about what order the parameters are, I'd just look the damn thing up in the manual and get on with life.
Or you make a bad guess and spend the next several hours trying to figure out why the program doesn't work.
Intelligent code editors that know about the APIs make this an awful lot easier, since they can immediately show you in a tooltip what the parameters are and in what order.
Basically, read the overviews carefully a few times, and maybe dig into some of the areas that particularly interest you.
Like you're writing a UI. You need a button, and you know the API can create buttons, and you know roughly where in the documentation to find out how to use a button. A few seconds later, you're golden.
But if all you know about the same API is how to bash pixels on the screen, you're screwed, no matter how good you are elsewhere.
For example, I want to find a string within a string.
Is it
char *strstr(const char *haystack, const char *needle);
or
char *strstr(const char *needle, const char *haystack);
I know it exists for sure. But if I haven't used it in a while, and I'm at all unsure about what order the parameters are, I'd just look the damn thing up in the manual and get on with life.
Or you make a bad guess and spend the next several hours trying to figure out why the program doesn't work.
Intelligent code editors that know about the APIs make this an awful lot easier, since they can immediately show you in a tooltip what the parameters are and in what order.
I cannot imagine that we could evaluate some productivity according to the lines of code that a dev writes in a time lapse T. However I understand what you mean. Sometimes I can write something quickly - more than 500 lines in a single day adding some parts which I have made before. Sometimes I suck totally working all day - and finally I erase what I made because it doesn't work as expected. Every is relative - only the final release matter ++
90% of programming is "paperclip twiddling." You bend open a paperclip and twiddle it between your thumb and forefinger, thinking about the problem. It drives inexperienced software managers crazy because they think you aren't doing anything.
The three or four very best, most productive times of my career have occurred while I was in the shower and had some insight to the problem.
Another guy and I once spent a month searching for a bug that was fixed with a one-line change. That's about 5*10-5 lines/minute.
I seem to recall years ago hearing that 20 lines/day was about average for an experienced professional programmer.
Dave
The three or four very best, most productive times of my career have occurred while I was in the shower and had some insight to the problem.
Another guy and I once spent a month searching for a bug that was fixed with a one-line change. That's about 5*10-5 lines/minute.
I seem to recall years ago hearing that 20 lines/day was about average for an experienced professional programmer.
Dave
| I seem to recall years ago hearing that 20 lines/day was about average for an experienced professional programmer. |
That's debugged and tested non-comment statements/day for a high level-language (excluding assembler etc).
In the book 'Mythical Man Month', the author discusses 10 lines per developer per day.
https://www.amazon.co.uk/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/ref=sr_1_1
There is also the quote by Dijkstra "if we wish to count lines of code, we should not regard them as 'lines produced but as 'lines spent'".
There's absolutely loads of discussion on this topic on the web.
Now how about a benchmark for comparing time actually programming to time used for research/background info/looking at interesting related stuff...
I write code at the speed of interest. Which lately is close to nil.
But then I am not now, nor ever been nor ever really want to be a professional programmer. I am too old and wizened for that adventure.
It also doesn't help I have zero academic instruction in how to program. Everything I know, or think I know, is from self-teaching.
Being a programming hobbyist is what I am. No more, no less.
But then I am not now, nor ever been nor ever really want to be a professional programmer. I am too old and wizened for that adventure.
It also doesn't help I have zero academic instruction in how to program. Everything I know, or think I know, is from self-teaching.
Being a programming hobbyist is what I am. No more, no less.
Last edited on
Your comments guys are so insightful and encouraging...
I'm currently implementing code for automatic layout of controls within a window.
I want to be able to put a bunch of controls onto a window without much hardcoded positions and sizes and then simply say something like:
And voila all controls are perfectly adjusted for font and DPI with just a few function calls, how productive.
But as it stands now, I spent some 4 days doing this, but these 4 days will pay out 1000 times over because there won't be need to type magic coordinates any more.
I mean, agree with you that thinkering and wasting time without writing much code in the end brings more benefit than just blindly bloating code.
I'm currently implementing code for automatic layout of controls within a window.
I want to be able to put a bunch of controls onto a window without much hardcoded positions and sizes and then simply say something like:
|
|
And voila all controls are perfectly adjusted for font and DPI with just a few function calls, how productive.
But as it stands now, I spent some 4 days doing this, but these 4 days will pay out 1000 times over because there won't be need to type magic coordinates any more.
I mean, agree with you that thinkering and wasting time without writing much code in the end brings more benefit than just blindly bloating code.
Last edited on
Nice. I am not the only one - as I thought :)
Hello. I thought about your question during this week-end developing my project for the 53rd LudumDare - and starting from scratch in order to fit with the rules (compo entry). As synthesis, in less than 10 hours I wrote more or less 800 lines of C++ code. Some of them have been erased, modified or improved during the dev session. I am proud of what I made - and I learnt many things again. Maybe I could do something better improving the first release, but it is good enough for a game jam with a restricted time. A fun stuff made this week-end ++
https://ldjam.com/events/ludum-dare/53/the-overlooker
| most productive times of my career have occurred while I was in the shower and had some insight to the problem |
Hello. I thought about your question during this week-end developing my project for the 53rd LudumDare - and starting from scratch in order to fit with the rules (compo entry). As synthesis, in less than 10 hours I wrote more or less 800 lines of C++ code. Some of them have been erased, modified or improved during the dev session. I am proud of what I made - and I learnt many things again. Maybe I could do something better improving the first release, but it is good enough for a game jam with a restricted time. A fun stuff made this week-end ++
https://ldjam.com/events/ludum-dare/53/the-overlooker
Last edited on
Pages: 12