Hacker News Reader

Comment by hellllllllooo | Hacker News Reader

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

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.

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/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/e...

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).

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.

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.

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.

Type is purpose. And anyways, the English alternatives are still vague and aren’t really improvements. KV is incredibly standard, even in English conversations (KV store is said more often than key value store). E is not descriptive, but neither is encodeState (WTF does that even mean?). S is a perfect abbreviation for a generic string, calling it string instead isn’t much better, really! It’s obvious in this case that it is only meant to be a generic string (what else could be meant by reflectWithString?).

I do prefer method names to be descriptive, so verbs are nice. Well, unless we are dealing with very generic lambda code, then there might not be better options beyond f, g, and p.

Also, as a rule of thumb: the more rarely something is used, the more descriptive its name needs to be. If something is used often in some code, terseness is more forgivable and even desirable in many cases.

A great example of this is "i" as a standard indexer, or "x" and "y" as horizontal and vertical coordinates. They are used often therefore terseness can be applied and is useful. Also why "KV" is often used to be mean key-value, the concept is just very pervasive. The terseness for variable names in the linked to code seems more acceptable because those variables of consistency and repeated usage.

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.

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.

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.

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.

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.

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.

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.

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).

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)

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.

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.

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.

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

Reply on news.ycombinator.com