5 ms·

Does anyone who writes code for a living here actually spend 90% of their time reading code?

bastawhiz 7y ago
Yes, for better or for worse. I deal with a very complex system in my daily work, and I'm often (a dozen or more times each week) tasked with answering questions along the lines of "Why did this happen?" or "What would the system do if (something) were to happen?" Being a mere moral, I must consult the code to find an answer.
pcl 7y ago
The general rule is that of the time you spend with code, 90% is reading and 10% is writing. This does not mean that 90% of your time is spend reading code. There are other tasks that programmers do during their day. I would say that the 90% number sounds roughly true for me. And probably I read my own code somewhat less than that, but spend more time reading others’ code, either due to code reviews or just to understand things before making changes to existing systems.
kstenerud 7y ago
I spend 90% of my "code time" (meaning time interacting with actual source code in some way) reading it rather than writing it. At the moment I'm reading https://github.com/golang/go/blob/master/src/encoding/json/encode.go https://github.com/golang/go/blob/master/src/encoding/json/e... to diagnose a problem in my code. Overall, the readability is good. My only complaint is the terse variable names, which makes the more complex methods more time consuming to follow (because you have to keep going back to refer to their definitions to remember what they are). For example, https://github.com/golang/go/blob/master/src/encoding/json/encode.go#L704 https://github.com/golang/go/blob/master/src/encoding/json/e...
- seanmcdirmid 7y ago
  The variable naming scheme in that code is incredibly consistent with respect to type. That should alleviate some of the problems, and I think the code would be more annoying to read if the variable names weren’t terse (like Simonyi Hungarian).
  - fouc 7y ago
    The consistency/types help a lot, but I would rather read 'destination' instead of 'dst', 'value' instead of 'v' etc in methods or blocks that are more than 2-3 lines. I don't want to have to guess or think about what the variable is supposed to be about.
    - seanmcdirmid 7y ago
      I actually feel like this would hinder readability, since we should be trying to read it like code rather than English. Destination is just as vague to me as dst, ditto for value and v, and I don’t have to move my eyes as much horizontally to read a line of code, not to mention that more verbose makes would sacrifice readability of the algorithmic structure for more context that quickly becomes redundant.
  - kstenerud 7y ago
    Type isn't the important information; PURPOSE is. When you dive into the code, especially at the point I chose, you are presented with: e.string(kv.s, opts.escapeHTML) And so, you have the following questions: What is e? What is kv? What is s in kv? To answer these, you have to scan upwards. e is encodeState. OK, not too bad. kv is maybe key-value of something? it comes from sv (string value maybe?), which comes from: sv := make([]reflectWithString, len(keys)) So a string value? Or a list of string keys? A list of structs, OK. s might be a string value inside, which has ... some meaning I guess? Digging around, I see it defined as: type reflectWithString struct { v reflect.Value s string } So it is a string, but I still don't know what its purpose is. After a bunch of digging around to see how it's used, it looks like s is a string representation of the value, but I'd need to look over more code to be 100% sure. Now, contrast this with: encoderState.string(keyValue.asString, opts.escapeHTML) Now I know what this calling string() on the encoder state, using the string representation of the key value. "string" is still a bit cryptic. It could be renamed. Looking inside "string" I see that it's writing things, so maybe a better name is: encoderState.writeString(keyValue.asString, opts.escapeHTML) With this version, I know without having to look at any other lines that this code is supposed to write the string representation of a key value to the encoder state, doing HTML escapes. I don't need to look inside the guts of anything to figure this out. I don't even have to leave this line. This is code U/X.
d4mi3n 7y ago
Writing code is generally much easier than reading it. Additionally, once you write code, you usually end up needing to change or maintain it. 90% is not uncommon. It's also generally a good sign if you spend less time writing code, because the hard part is usually in the design/planning phase of a new system or product. Days of programming saves hours of planning.
quickthrower2 7y ago
Of course. You need to read code to modify it. Typing is quick due to IDE assistance and copy/paste, so I don’t spend too much time on that part.
james_ab 7y ago
I think it's "worse" than that. Last week, I wrote four classes. They weren't very long. I spent most of the time trawling through libraries I was using trying to figure out how to write those four classes. But it felt like quite a productive week: they were the "right" four classes, and I could have written a lot more code that did the job less concisely.
jspash 7y ago
Absolutely! I would say 90% isn't high enough when you consider the amount of time reviewing pull requests on a large team. Add to that the reading required when deciding on an external library (yes, some people simply use only popularity metrics and Github repo signals like number of issues etc. Fair enough. Our team tries to skim the entire code at least once.) We also do team code reviews on a big screen over pizza twice a month. It gives a chance for the entire team to learn something new without being under pressure. So yea, lots of reading happens around here. The side-effect is some pretty good (and readable) code IMHO.
jondubois 7y ago
For personal side projects, I spend at least 80% of my time thinking about the code that I'm going to write, 5% writing it and 15% reading it. The more experienced I become, the less time I spend writing code and the more time I spend thinking about it and drawing diagrams on paper. Coding should not be the bottleneck. The bottleneck should be deciding what solution to choose because there are usually a lot of factors to consider and it takes a while to identify all the main ones. It's not unusual for me to spend multiple days just thinking through different technical solutions without writing any code. IMO developers who commit often and too many lines are juniors. Most of these lines will have to be rewritten because there wasn't enough thought behind them.
- seanmcdirmid 7y ago
  Coding is also a way of thinking. Too much planning up front also has a name (water fall?), the other option is to write now to get understanding and rewrite later as that understanding accumulates (I think that way if working has a name also). Of course, there are many kinds of valid working styles in between. I personally would rather see juniors write, make mistakes, and rewrite than just be paralyzed with thought/planning anxiety, which is perhaps more effective for more experienced developers.
  - adrianhel 7y ago
    I like to plan by coding prototypes. It depends on the task at hand, but for certain problems it can be nice to create a new branch or repo even and test out my ideas. I'll often write sketches on my phone too.
  - jondubois 7y ago
    You don't necessarily need to plan everything up front. You can identify critical decisions points within your project as you go along. Personally, I try to keep interfaces between modules as simple and restrictive as possible (as simple as they can be while still meeting business requirements) but I keep the option open to add more flexibility/complexity later if it turns out to be absolutely necessary. Often it turns out to not be necessary. Having simple and restrictive module interfaces is extremely valuable if you can figure out what the right restrictions are.
capitol_ 7y ago
I spend at least 90%. I need to read and understand all the connected code before i make any modifications.
speedplane 7y ago
I've written so much code that I've forgotten far more than I know. I spend a ton of my time reading my own code.
pjc50 7y ago
In any maintenance-mode organisation that's the reality for everyone. As is spending increasingly large chunks of time that result in almost no lines of code being committed, because you're debugging more and more complex problems. Two weeks to find a stray minus sign. Four weeks to change some numbers in a table. Another month to determine a PCB change is needed. That kind of thing. (We could do with a serious version of "thedailywtf" for interesting debugging stories, I think it would open a few eyes)
C4stor 7y ago
Yes. Even by being a solo developer for quite some time, I ended up spending about that amount of time reading code, with a good portion being spent reading my own old code. It's been a ramp up of course, starting with a totally blank codebase, I started with 100% of time "writing" code (quotes meaning : thinking about and then actually writing, I assume it goes together).

Yes, for better or for worse. I deal with a very complex system in my daily work, and I'm often (a dozen or more times each week) tasked with answering questions along the lines of "Why did this happen?" or "What would the system do if (something) were to happen?" Being a mere moral, I must consult the code to find an answer.

pcl 7y ago

The general rule is that of the time you spend with code, 90% is reading and 10% is writing. This does not mean that 90% of your time is spend reading code. There are other tasks that programmers do during their day. I would say that the 90% number sounds roughly true for me. And probably I read my own code somewhat less than that, but spend more time reading others’ code, either due to code reviews or just to understand things before making changes to existing systems.

kstenerud 7y ago

I spend 90% of my "code time" (meaning time interacting with actual source code in some way) reading it rather than writing it. At the moment I'm reading https://github.com/golang/go/blob/master/src/encoding/json/encode.go https://github.com/golang/go/blob/master/src/encoding/json/e... to diagnose a problem in my code. Overall, the readability is good. My only complaint is the terse variable names, which makes the more complex methods more time consuming to follow (because you have to keep going back to refer to their definitions to remember what they are). For example, https://github.com/golang/go/blob/master/src/encoding/json/encode.go#L704 https://github.com/golang/go/blob/master/src/encoding/json/e...

seanmcdirmid 7y ago
The variable naming scheme in that code is incredibly consistent with respect to type. That should alleviate some of the problems, and I think the code would be more annoying to read if the variable names weren’t terse (like Simonyi Hungarian).
- fouc 7y ago
  The consistency/types help a lot, but I would rather read 'destination' instead of 'dst', 'value' instead of 'v' etc in methods or blocks that are more than 2-3 lines. I don't want to have to guess or think about what the variable is supposed to be about.
  - seanmcdirmid 7y ago
    I actually feel like this would hinder readability, since we should be trying to read it like code rather than English. Destination is just as vague to me as dst, ditto for value and v, and I don’t have to move my eyes as much horizontally to read a line of code, not to mention that more verbose makes would sacrifice readability of the algorithmic structure for more context that quickly becomes redundant.
- kstenerud 7y ago
  Type isn't the important information; PURPOSE is. When you dive into the code, especially at the point I chose, you are presented with: e.string(kv.s, opts.escapeHTML) And so, you have the following questions: What is e? What is kv? What is s in kv? To answer these, you have to scan upwards. e is encodeState. OK, not too bad. kv is maybe key-value of something? it comes from sv (string value maybe?), which comes from: sv := make([]reflectWithString, len(keys)) So a string value? Or a list of string keys? A list of structs, OK. s might be a string value inside, which has ... some meaning I guess? Digging around, I see it defined as: type reflectWithString struct { v reflect.Value s string } So it is a string, but I still don't know what its purpose is. After a bunch of digging around to see how it's used, it looks like s is a string representation of the value, but I'd need to look over more code to be 100% sure. Now, contrast this with: encoderState.string(keyValue.asString, opts.escapeHTML) Now I know what this calling string() on the encoder state, using the string representation of the key value. "string" is still a bit cryptic. It could be renamed. Looking inside "string" I see that it's writing things, so maybe a better name is: encoderState.writeString(keyValue.asString, opts.escapeHTML) With this version, I know without having to look at any other lines that this code is supposed to write the string representation of a key value to the encoder state, doing HTML escapes. I don't need to look inside the guts of anything to figure this out. I don't even have to leave this line. This is code U/X.

d4mi3n 7y ago

Writing code is generally much easier than reading it. Additionally, once you write code, you usually end up needing to change or maintain it. 90% is not uncommon. It's also generally a good sign if you spend less time writing code, because the hard part is usually in the design/planning phase of a new system or product. Days of programming saves hours of planning.

quickthrower2 7y ago

Of course. You need to read code to modify it. Typing is quick due to IDE assistance and copy/paste, so I don’t spend too much time on that part.

james_ab 7y ago

I think it's "worse" than that. Last week, I wrote four classes. They weren't very long. I spent most of the time trawling through libraries I was using trying to figure out how to write those four classes. But it felt like quite a productive week: they were the "right" four classes, and I could have written a lot more code that did the job less concisely.

jspash 7y ago

Absolutely! I would say 90% isn't high enough when you consider the amount of time reviewing pull requests on a large team. Add to that the reading required when deciding on an external library (yes, some people simply use only popularity metrics and Github repo signals like number of issues etc. Fair enough. Our team tries to skim the entire code at least once.) We also do team code reviews on a big screen over pizza twice a month. It gives a chance for the entire team to learn something new without being under pressure. So yea, lots of reading happens around here. The side-effect is some pretty good (and readable) code IMHO.

jondubois 7y ago

For personal side projects, I spend at least 80% of my time thinking about the code that I'm going to write, 5% writing it and 15% reading it. The more experienced I become, the less time I spend writing code and the more time I spend thinking about it and drawing diagrams on paper. Coding should not be the bottleneck. The bottleneck should be deciding what solution to choose because there are usually a lot of factors to consider and it takes a while to identify all the main ones. It's not unusual for me to spend multiple days just thinking through different technical solutions without writing any code. IMO developers who commit often and too many lines are juniors. Most of these lines will have to be rewritten because there wasn't enough thought behind them.

seanmcdirmid 7y ago
Coding is also a way of thinking. Too much planning up front also has a name (water fall?), the other option is to write now to get understanding and rewrite later as that understanding accumulates (I think that way if working has a name also). Of course, there are many kinds of valid working styles in between. I personally would rather see juniors write, make mistakes, and rewrite than just be paralyzed with thought/planning anxiety, which is perhaps more effective for more experienced developers.
- adrianhel 7y ago
  I like to plan by coding prototypes. It depends on the task at hand, but for certain problems it can be nice to create a new branch or repo even and test out my ideas. I'll often write sketches on my phone too.
- jondubois 7y ago
  You don't necessarily need to plan everything up front. You can identify critical decisions points within your project as you go along. Personally, I try to keep interfaces between modules as simple and restrictive as possible (as simple as they can be while still meeting business requirements) but I keep the option open to add more flexibility/complexity later if it turns out to be absolutely necessary. Often it turns out to not be necessary. Having simple and restrictive module interfaces is extremely valuable if you can figure out what the right restrictions are.

capitol_ 7y ago

I spend at least 90%. I need to read and understand all the connected code before i make any modifications.

speedplane 7y ago

I've written so much code that I've forgotten far more than I know. I spend a ton of my time reading my own code.

pjc50 7y ago

In any maintenance-mode organisation that's the reality for everyone. As is spending increasingly large chunks of time that result in almost no lines of code being committed, because you're debugging more and more complex problems. Two weeks to find a stray minus sign. Four weeks to change some numbers in a table. Another month to determine a PCB change is needed. That kind of thing. (We could do with a serious version of "thedailywtf" for interesting debugging stories, I think it would open a few eyes)

C4stor 7y ago

Yes. Even by being a solo developer for quite some time, I ended up spending about that amount of time reading code, with a good portion being spent reading my own old code. It's been a ramp up of course, starting with a totally blank codebase, I started with 100% of time "writing" code (quotes meaning : thinking about and then actually writing, I assume it goes together).