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

131–140 of 188 posts

Re: Nobody's just reading your code

#131

Post by Ace17 »

RobertRoberts wrote: post #90
bryanrasmussen wrote: post #58

Earlier quoted context omitted.

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…

> 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? nope, I am just saying what I said, I never regretted not using one, and have regretted investing in a few that later caused more headaches than they were worth. When we switched from inhouse code to a dependency, we never regretted doing it on our own to start with because there w…

Yeah, this also matches my (+10 year) experience as a professionnal dev ... with one exception, though: the "maintainance-can-of-worm" packages. These are packages which, by design, can never be considered as finished, and periodically need to be updated to stay relevant in your application.

There are three reasons for this:

1) Those packages implement an ever-growing pile of tricks/heuristics to convincingly solve problems from the domain. They include: physics engines, SMT solvers, compilers/jitters/optimizers, computational geometry packages, video encoders ...

2) Those packages implement an unification layer over an ever-growing/evolving set of underlying APIs/protocols/formats. They include: SDL, ncurses, curl, ImageMagick ...

(these are not to be confused with "bug-factories" packages, which might not solve a complex problem, but still require constant updating to fix the current bugs, and benefit from the new ones).

Re: Nobody's just reading your code

#132

Post by mannykannot »

stenecdote wrote: post #107
mannykannot wrote: post #83

I must disagree with this sentiment, though I understand where it is coming from: "Clean, solidified abstractions are like well-marked, easy-to-follow paths through a forest — very useful if they lead in the direction we need to go, but less useful when we want to blaze arbitrary new paths through the forest." Using the same analogy, if you want to blaze a new trail through the woods, you need a map of the territory,…

To push back on this point a little bit, I think we agree that a map is one of the most useful things you can have but disagree on what the right type of map is. While I'm not anti-abstraction, I think people often impose poorly chosen high-level abstractions on top of messy lower-level components (akkartik calls this Authoritarian High Modernism in a comment ( https://lobste.rs/s/gtxi5y/nobody_s_just_reading_your_co…

Yes, the start of your last paragraph states what I would like to see, and the statement I took issue with specifically dismisses 'clean, solidified' abstractions, not messy, failed attempts at it, yet I am also very well aware, from personal experience, that we often have to deal with code that is not like that (even though, in some cases, written by people who thought they were doing SOLID work.)

The question is what to do about it, especially given that abstraction and the separation of concerns are not suddenly going to fix things after all these years of being more honored in the breach. I do not think that there is a programming style that leads to the writing of understandable code without having a coherent vision of the big picture, because I do not think you can understand the purpose of code in the small without knowing its place in the big picture (except insofar as the author has successfully separated the independent concerns, which brings us back to my original point about the value of abstraction.)

One can still modify such code, but the less you understand about it, the more likely it is that you will make mistakes, and there is also a real possibility that the result will be harder to understand than the original - this vicious circle is one reason why much-modified code is usually difficult to understand.

While I don't hold out much hope for programming style to save us from this situation, I think we might do better with tools to help us understand code. In particular, I sometimes find myself doing program slicing by hand (what ways are there to get from A to B that modify X, for example), and there is some tool support for doing so, though availability is spotty at best.

Re: Nobody's just reading your code

#133

Post by marcosdumay »

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

The inability to justify time makes people avoid doing the work. Some people will strongly avoid it, other people will just weakly avoid it, but nobody will be more inclined to do it than if the time was taken into account.

If your methodology makes people avoid doing important work, it's a bad methodology.

Re: Nobody's just reading your code

#134

Post by bitL »

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.

That's kinda illusion. If you start digging into some really complex code, like distributed processing core, meta-programming framework, low-level optimizations, it can take you years to understand all that is going on. Often it's more economical just to rewrite it, even if the previous system was far better than what you'll produce. Whether companies like it or not, projects live with original team members and once they move on, it's getting complicated to maintain or extend them.

Re: Nobody's just reading your code

#135

Post by gt_ »

FLUX-YOU wrote: post #118
gt_ wrote: post #97

Earlier quoted context omitted.

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.

This is a normal feeling. But one weakness of this approach for javascript is that it's easier to become popular because you have a much larger base of developers.

That makes sense. I use Python the for most part. I feel like I have seen this happen with old libraries where they used to be very popular and maintained then became abandoned a few years ago.

Re: Nobody's just reading your code

#136

Post by neuland »

alister wrote: post #67

Reading code just for fun was a thing in the early and mid years of UNIX (eg., 7th edition or System V). People eagerly passed around faint 10th generation photocopies of Lion's printout of and commentary[1] on the UNIX source code. The annual USENIX conference had a popular short course in which they went through the entire UNIX kernel line by line. Why was that a thing back then and not now? Certainly UNIX was an a…

Is there any material around still from the USENIX course that went through UNIX line by line?

It looks like the Lions commentary also does that to a certain extent as well. There's even a version of the book online [0].

[0] http://www.lemis.com/grog/Documentation/Lions/index.php

Re: Nobody's just reading your code

#137

Post by mikelward »

radicalbyte wrote: post #20
curtis wrote: 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.

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.

Or it could be handled as a Spike.

It's not perfect, but it captures the idea of uncertainty by having a time-boxed investigation, the end result of which is an estimate of how long it will take to fix.

https://www.leadingagile.com/2014/04/dont-estimate-spikes/ https://www.scrumalliance.org/community/articles/2013/march/...

Re: Nobody's just reading your code

#138

Post by shortoncash »

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…

Take all my upvotes and offer a newsletter for subscription please.

The lack of digging is a frustration I have with a lot of new guys who join the team. For example, they might create something new and tack on some new, untested piece of code without reading whether something already exists within the same codebase. Even in a startup environment where documentation is scarce, it's worthwhile to ask the question of, "Did someone else here think of this problem here before me? What did they do?"

Re: Nobody's just reading your code

#139

Post by taeric »

sanxiyn wrote: post #48
taeric wrote: post #13

Earlier quoted context omitted.

Don't let survivorship and confirmation bias cloud your judgment. What sets many successful people apart is not any one thing, but that they were successful. Many are willing to dive into other people's code in methods that are far deeper than I can comprehend, and yet they have failed at whatever task they were going about. So, yes. By and large, you shouldn't stop at your dependency boundaries. However, your job is…

Forking is perfectly doable. Rust project forks LLVM, adds patches, and forward ports them when upgrading LLVM version. It's manageable.

If you are a large enough team, definitely. And not just in people, but in momentum.

That is, yes, it can be done. It is more work, though. Account for it.

Re: Nobody's just reading your code

#140

Post by taeric »

heavenlyblue wrote: post #74
icebraining wrote: post #42

Earlier quoted context omitted.

Forking is not that bad, unless upstream has a lot of activity yet takes a long time to accept patches. Many projects are mostly dormant, so keeping a patchset and occasionally rebasing is easy enough. We use git-aggregator[1] for easily applying pending PRs/MRs over the upstream branch, and for the most part, conflicts are rare. [1] https://pypi.python.org/pypi/git-aggregator

The thing I find with python/ruby ecosystems - is that the versions are generally pinned, so if you do fork a change for your specific need; you'll end up using it for the project. If the change isn't merged - then at least you may use it yourself.

These are both valid choices. I had not meant it to be that it is not possible.

However, in both cases you now have a new line of work. It is common in my experience to find folks are behind in their first job, so adding a new one is dangerous.

Post reply on HN