Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nobody's just reading your code

akkartik.name

Post reply on HN
Print view View original

151–160 of 188 posts

Re: Nobody's just reading your code

#151

Post by Bartweiss »

_asummers wrote: post #101
marcosdumay wrote: post #86

Earlier quoted context omitted.

> It's also extremely hard to estimate so gets avoided in scrum. So, one more time Scrum seems to be unable to support actual development needs.

The inability to justify time spent in Scrum doesn't make the time not get spent, it just gets hidden, defeating the whole point. I abhor Scrum, but I would also argue that in this case the development task weight just gets inflated for "unknowns" on the task.Instead of a 5 maybe it's an 8, or whatever.

I sometimes wonder what fully-honest Scrum would look like.

I mean... 3 points: dealing with ticketing system. 5 points: looking into bugs/issues which will become new tickets. 5 points: taking questions and talking process on other people's tickets.

The list goes on. I like agile, and I don't hate Scrum, but it's unpleasantly easy to end up running a planning/scheduling process which is completely distinct from one's actual schedule.

Re: Nobody's just reading your code

#152

Post by andrewaylett »

bsimpson wrote: post #149
thiht wrote: post #128

Earlier quoted context omitted.

I don't follow, the code in node_modules is readable and allows to navigate through the original sources. Is it not always the case?

I think they're saying that code on NPM may be written with a bunch of experimental Babel features or in some niche language like Elm, and then translated to vanilla JS. In those cases, you might find code that's been machine translated or minified in node_modules, not the original source.

Exactly :).

Re: Nobody's just reading your code

#153

Post by to3m »

chiefalchemist wrote: post #81
bsimpson wrote: post #2

One of the things that sets a good programmer apart is the willingness to fearlessly dig into someone else's code. I've heard it said before that you're responsible for every line of code you ship to your users. It follows that you shouldn't treat your dependencies as black boxes. Getting a stack trace that's 3 or 4 levels deep in Django/React/ ? Dig under the covers and understand what's happening. Include that info…

"...open a PR offering to fix it..." Perhaps I've been asking to wrong people (at the wrong time) - forgive me - but (as dar as I can tell) git has no easy / reasonable way to repo'tize a (vendor/) dependency. That means you have to bend over backwards (read: make too much extra effort) to patch such a library local and then eventually PR that change. This feels like a fairly significant flaw in the current OSS "ecos…

Use git submodules. git submodules interact tolerably neatly with GitHub's PR functionality; if you make changes to your submodule, then it's straightforward to turn that into a PR that you can submit to the upstream repo. And since your updates are a git branch like any other, if the upstream repo won't accept your changes then you can just keep doing fetch+merge/rebase to keep on top of the changes at their end.

Of course, this is git, so the UX is a total disaster, and it's very easy to get yourself in a pickle. But Stockholm syndrome will set in after a while and you'll begin to find it tolerable.

Re: Nobody's just reading your code

#154

Post by lummax »

jesperlang wrote: post #88

Reading code always felt awkward, slow and ineffective. The cognitive load is huge, you have to compute some things while memorizing others and at the same time keep track of flows. Thats why I always have pen and paper while diving into a new big code base, you simply can't keep it in your head. But something we forget often is... the goal of reading code is almost always to understand a system or some part of it. A…

Code as a city: https://wettel.github.io/codecity.html

Re: Nobody's just reading your code

#155

Post by dalore »

curtis wrote: post #6
bsimpson wrote: post #2

One of the things that sets a good programmer apart is the willingness to fearlessly dig into someone else's code. I've heard it said before that you're responsible for every line of code you ship to your users. It follows that you shouldn't treat your dependencies as black boxes. Getting a stack trace that's 3 or 4 levels deep in Django/React/ ? Dig under the covers and understand what's happening. Include that info…

> ... willingness to fearlessly dig into someone else's code. I've done this many times. The problem is that it takes a lot of time, and there's no way you can dig through more than a fraction of a large codebase. You gotta pick your battles.

A nice middle ground is to step through with the debugger when you're in your own code and see what other code it's calling that isn't yours. You don't/can't read all of it as you said. But perhaps knowing the bits your interacting with helps a lot.

Re: Nobody's just reading your code

#156

Post by klenwell »

jesperlang wrote: post #88

Reading code always felt awkward, slow and ineffective. The cognitive load is huge, you have to compute some things while memorizing others and at the same time keep track of flows. Thats why I always have pen and paper while diving into a new big code base, you simply can't keep it in your head. But something we forget often is... the goal of reading code is almost always to understand a system or some part of it. A…

> But something we forget often is... the goal of reading code is almost always to understand a system or some part of it. And reading code for me is a terrible way to do it.

Good point. A couple famous quotes that speak to this[0]:

Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious.

-- Fred Brooks, The Mythical Man-Month

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

-- Linus Torvalds

[0] https://news.ycombinator.com/item?id=9487819

Re: Nobody's just reading your code

#157

Post by goldfire »

mjevans wrote: post #21

One of the reasons I love golang* is how the entire source code for the standard library is just a few easy clicks away from the documentation on how to use it. As an example: When I want to do something and the interfaces I'm seeing provide friction (XML parsing not /quite/ handling normal, slightly incorrect, HTML) I can get a better idea of what the library is doing behind the scenes. I got an example of how to us…

Rust's library documentation has this feature as well; each item has a [src] link that takes you straight to the code being documented; see for instance [0], and you'll find the link to the right side of the heading. This even works for crates not in the standard library because it's actually a feature provided by rustdoc, the standard documentation generator; for example, you can get to the source for functions in serde (the most popular Rust serialization library) directly from its documentation [1].

[0] https://doc.rust-lang.org/std/vec/struct.Vec.html#method.tru...

[1] https://docs.serde.rs/serde_json/ser/fn.to_string_pretty.htm...

Re: Nobody's just reading your code

#158

Post by rtkwe »

curtis wrote: post #6
bsimpson wrote: post #2

One of the things that sets a good programmer apart is the willingness to fearlessly dig into someone else's code. I've heard it said before that you're responsible for every line of code you ship to your users. It follows that you shouldn't treat your dependencies as black boxes. Getting a stack trace that's 3 or 4 levels deep in Django/React/ ? Dig under the covers and understand what's happening. Include that info…

> ... willingness to fearlessly dig into someone else's code. I've done this many times. The problem is that it takes a lot of time, and there's no way you can dig through more than a fraction of a large codebase. You gotta pick your battles.

Along those lines are there any tools that are really good for that? I'm looking for a program that can do some things like IDA does for assembly where there's the ability to label blocks/variables and then see where it's used elsewhere etc.

Re: Nobody's just reading your code

#159

Post by zanny »

mjevans wrote: post #21

One of the reasons I love golang* is how the entire source code for the standard library is just a few easy clicks away from the documentation on how to use it. As an example: When I want to do something and the interfaces I'm seeing provide friction (XML parsing not /quite/ handling normal, slightly incorrect, HTML) I can get a better idea of what the library is doing behind the scenes. I got an example of how to us…

Rust does this too. Since docs are generated from sources every docs page has a [src] button that has the context the docs were generated from, which means the function source. Super easy and intuitive to switch between the two.

Its good that most newer / modern languages have learned how valuable both easy documentation and pairing the docs with the code are.

Re: Nobody's just reading your code

#160

Post by lloyd-christmas »

deckard1 wrote: post #52
nathanaldensr wrote: post #19

Earlier quoted context omitted.

Pragmatism wins the day, for sure. I'll happily read someone else's code (e.g., an open-source GitHub repository I rely on) if it's necessary to troubleshoot issues or implement a feature. There needs to be a reason (i.e., motivation) to read code.

On github and the node/JS ecosystem, the way this will play out: 1. Spend hours digging through layers and layers of crufty JS. 2. Find the issue (and the package responsible for the issue). 3. Find out there is a Github Issue for the issue. 4. Find out there is a pull request for the issue. 5. Find out the pull request is sitting in position #35 of #128 pull requests going back to 2015. 6. Go binge drinking.

In my last 4 years of working in node, I've had this issue once. I think you people need to pick better dependencies.
Post reply on HN