Live data from Hacker News

Nobody's just reading your code

akkartik.name

91–100 of 188 posts

Re: Nobody's just reading your code

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

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.

Re: Nobody's just reading your code

#92
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 just write that the library's function at hand is unreliable and can't be used this way.

Re: Nobody's just reading your code

#93

Earlier quoted context omitted.

This is sadly why I keep my dependencies to a minimum. After coding for almost 20 years now, full time, I have never regretted not using a dependency. But I have regretted using one multiple times. (the regret is like a walk of shame during the "separation and cleanup" phase at the end, which makes me question the "got work done faster" phase at the beginning....)

In 20 years you've never started work on something and after a bit said damn it I think I'll use that library that other guy developed? If you've ever switched out dependency X for dependency Y I suppose you regretted not using Y to begin with. If you've ever stopped working on your own solution to a problem and instead used a solution provided in a library didn't you regret not just using the library from the beginn…

one of the reasons that I switched from using node.js to ringo.js

Re: Nobody's just reading your code

#94
post #6
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.

Picking your battles may in fact be (one of) the things that'd set one apart. You can get bogged down in the weeds of dependencies. You can also end up with kludgy half-solutions to persistent problems by treating them like black boxes.

But, before you you can pick battles you need to treat such things as possibilities, something you've done before an feel comfortable doing.

Re: Nobody's just reading your code

#95

Earlier quoted context omitted.

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

It's not really so much that _git_ is lacking the functionality -- it's actually much more possible to do reasonable vendoring with git than with (say) subversion, as you can use submodules to point at your fork. To my mind the issue is more with tooling: you don't typically want to vendor your code, most of the time you want to use a published module. And the process for publishing your fork is too complex to be wor…

I understand there are workarounds, but they are just that. I mean, for example, I'm working away but hit a bug in a dependency. Now i have to fork, submodule, etc.

I'm not expecting frictionless per se. But it just feels like there's more overhead than there needs to be.

Also, it's possible (in rare cases) the vendor folder is not .gitignore'd. Now what? Submodules is out.

Again, given the nature of most modern dev (i.e., dependencies) vit feels underprepared.

Re: "...but by switching away from the original you lose tooling support for telling you when you need to make that update..."

Yes. But doesn't this actually support the idea (mentioned above) not to treat your dependencies like black boxes? That is, no pain no gain? Yeah, perhaps some sort of simple notification your fork needs an update. Just the same, ALL code should, in theory, be treated as your own. You wouldn't blindly merge/commit a colleague's work, so why shouldn't your dependencies be semi thoroughly reviewed as well?

Are we too busy to do the right thing(s)?

Re: Nobody's just reading your code

#96
post #3

Earlier quoted context omitted.

No mention of time in the article or in your comment. With infinite time we could fix a lot of things.

Of course you can expand this to be unreasonable - you could also make a strawman argument about how you need to understand all the compilers, OS APIs, and chip architectures that support your product. Obviously, that's not what I'm saying. I'm making a few assumptions: the code you're depending on was written by people like you (e.g. other open source volunteers with expertise in the same language as you); the limit…

>it's probably worth a week or two to figure out what's wrong and fix it

Ha! I'm convinced that people who say stuff like this haven't worked where their paycheck comes from actual paying customers, as opposed to VC dollars or subsidies from other parts of the business's revenue.

> Still, I implore you to not let yourselves be afraid of Other People's Code.

Wtf? Nobody said they were and what is with the Condescending Proper Noun?

>It's probably not as scary as you think it is

Nobody said it was.

Re: Nobody's just reading your code

#97
post #54

Earlier quoted context omitted.

This is not always an optimal solution. Because by doing this you have essentially became a maintainer of a dependency you initially wanted to 'just' use.

This is sadly why I keep my dependencies to a minimum. After coding for almost 20 years now, full time, I have never regretted not using a dependency. But I have regretted using one multiple times. (the regret is like a walk of shame during the "separation and cleanup" phase at the end, which makes me question the "got work done faster" phase at the beginning....)

I have only been coding for 1.5 years and this kind of comment is validating what I worry is a very bad habit. I hate using dependencies unless they have reached a certain level of legend in the community.

Re: Nobody's just reading your code

#98
post #62

This is a bit western centric maybe, because I see Chinese developers reading tons of code, to the point that I receive an incredible amount of Redis PRs about conceptual bugs that can never happen in practice, since some Chinese developer is reading the code and doing the math in her/his head.

Any case you could share a link to one of these, if possible? A matter of curiosity.

First PR I saw on redis GH: https://github.com/antirez/redis/pull/4714

That same user also made https://github.com/antirez/redis/pull/4685

This may be? https://github.com/antirez/redis/pull/4622

This was apparently critical, but also kind of an edgecase: https://github.com/antirez/redis/pull/4568

& one more from someone else: https://github.com/antirez/redis/pull/4568

Re: Nobody's just reading your code

#99
One thing that helps me make reading code in code reviews less passive is to add occasional temporary print statements and then run the unit tests again that cover the code I am reading. Seeing variable values satisfies some curiousity. Sometimes I will use a debugger to step through code I am reviewing but for some reason I prefer print statement to satisfy any curiousity I have about how the code works.

Re: Nobody's just reading your code

#100

Earlier quoted context omitted.

This. I'm not afraid of it, but it can take a lot of time. It's also extremely hard to estimate so gets avoided in scrum.

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

My experience too. Velocity trumps everything else. IMHO, Scrum is like Communism. Okay in theory, but never implemented properly. And it's always the people at the bottom who suffer.
Post reply on HN