Live data from Hacker News

Nobody's just reading your code

akkartik.name

121–130 of 188 posts

Re: Nobody's just reading your code

#121
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…

Isn't it the purpose of blackboxes, to abstract me from doing this? I'm here to get the work done and hopefully having to debug only code of my colleagues, why would I want to waste time on debugging something that should have been battle tested by myriads of people before me? Argument like this almost justifies leaky abstractions as something to be praised.

Isn’t the purpose of open source also to empower you, the developer using the library, to fix the bug you find so that everyone may benefit?

Re: Nobody's just reading your code

#122

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.

This is the only reason (at least for now) that makes me dig into a library code. And I always got some benefit from it. I think we often treat libraries as voodoo blackboxes, but they're more often thatn not created by normal people with great skills. Sometimes it's a great way to learn a way to code, or even better, to understand the behaviour of a library. I found myself doing it more often when the IDE itself dow…

The blackbox vodoo view- sometimes is just a excuse for lazy evaluation. One can profile a black box- but many fear the moment they discover that there beloved "I know all the api calls from memory alone" library shows bad perfRomance.

Re: Nobody's just reading your code

#123

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…

I find it useful to write comments about what's happening in the code as I am trying to figure it out.

Re: Nobody's just reading your code

#124
post #6

Earlier quoted context omitted.

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

Also, when you're using 3rd party proprietary code, you don't get the option of fixing it. So delving into it can feel silly.

But there are often times when you can trick it into doing what it’s supposed to do.

And a really targeted bug report can often get a bug fixed pretty quickly. Several times I’ve been working at a place where the goddamned IP lawyers were so power mad that I could not file a patch for a bug even though I knew how to fix it, but filing a bug with an exact line number and description of what’s wrong with it can get it fixed anyway.

Filing a razor sharp bug report seems to be a rare skill, but if you can learn it your quality of life is better.

Re: Nobody's just reading your code

#125
post #9
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…

I always get an uneasy feeling when this is not (practically) possible. Whenever I add a dependency to a project I will at least skim through the source to get an idea of what it is I’m adding, and it pleases me a lot when a library is well written and self contained enough that this does not mostly leave me confused or overwhelmed. There’s a similar reason why I have such mixed feelings about some build tools and co…

> as long as it works as it should.

Maybe confirmation bias, but I can’t think of a single library where this stayed true for the entire life of a project. Software is written by humans.

“To err is human. To really fuck up requires the aid of a computer.”

Re: Nobody's just reading your code

#126
Somebody read my code once and commented on my improper use of 'mod' or something like that. It then turned into a long discussion on how they might be incorrect, and so on and so forth on Reddit, back and forth on Lisp.

I love Lisp. It's a great language with great programmers.

Re: Nobody's just reading your code

#127

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…

Assuming I can, I always study code with a debugger and various simplification techniques (say throw in `abort()` or raise an exception to get a stack trace or throw in `printf()` on interesting objects). Usually I just start it up with `gdb ./program` and step through and see where it takes me. If the code is complex enough, I'll even start ripping out parts to see where it's required (often it's not in whatever simple case you're interested in).

If I can't use a debugger (i.e. my initial assumption fails), I usually run for the hills...

Re: Nobody's just reading your code

#128
post #9

Earlier quoted context omitted.

I always get an uneasy feeling when this is not (practically) possible. Whenever I add a dependency to a project I will at least skim through the source to get an idea of what it is I’m adding, and it pleases me a lot when a library is well written and self contained enough that this does not mostly leave me confused or overwhelmed. There’s a similar reason why I have such mixed feelings about some build tools and co…

What frustrates me about the JS world is that all too often, what you get from NPM is the output, not the input. Maven might not be universally loved, but you do at least get to navigate through the original Java source and stand _some_ chance of finding what you're looking for.

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?

Re: Nobody's just reading your code

#130
post #6

Earlier quoted context omitted.

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

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.

Absolutely, but I find in many cases, people are just too lazy to want to dig into another piece of code, and just give up prematurely.
Post reply on HN