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

171–180 of 188 posts

Re: Nobody's just reading your code

#171

Post by jandrese »

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…

I wonder if part of the reason this worked so well is that the Unix kernel was written in a fairly straightfoward top down style? It's a lot harder to do a code reading if you're hitting different abstractions on every other line and having to make digressions to track down exactly what that abstraction is doing.

Re: Nobody's just reading your code

#172

Post by svat »

stenecdote wrote: post #112
svat wrote: post #36

Peter Seibel, the author of the Coders at Work book mentioned in the post, actually discussed this in a blog post: http://www.gigamonkeys.com/code-reading/ It's not quite true that none of the programmers interviewed in the book routinely read code for fun. In his blog post, Seibel mentions the exceptions: > First, when I did my book of interviews with programmers, Coders at Work, I asked pretty much everyone about c…

Upvoted for careful scholarship and a useful addendum (I'm OP)! I sometimes wonder whether a lot of Knuth's greatness comes from doing more of the stuff everyone knows they should do but don't. If you read this interview ( https://github.com/kragen/knuth-interview-2006 ) with Knuth, he talks about how he was nervous he wouldn't be able to learn calculus so just decided to do all the problems instead of just the assig…

Yes exactly. It's always inspiring to see how (in his case) you just start doing things simply and methodically with focus, and eventually you get very far and become better than anyone else.

Re: Nobody's just reading your code

#173

Post by RobertRoberts »

gt_ wrote: post #97
RobertRoberts wrote: post #56

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

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.

>...unless they have reached a certain level of legend

That is a similar tactic I use now for anything core. I know I commented that we don't have any dependencies in our core systems, but as an afterthought, this isn't entirely accurate. We do, but as you said they are "legendary", and don't change a whole lot anymore.

I think you are on the right track. :)

Edit: Keep business practicality in mind, if using a 3rd party library means you feed your family or are productive for the business, you need to weigh these considerations carefully.

It's likely you need to use a dependency to get your work done, and then later when you are more profitable, you can clean it out if need be. Maybe that is how I should have worded my first comment in retrospect.

Re: Nobody's just reading your code

#174

Post by marcosdumay »

Bartweiss wrote: post #151
_asummers wrote: post #101

Earlier quoted context omitted.

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'…

Tickets based development can not work very well.

We need tickets (hell, I have to write them for myself on personal projects, otherwise I get locked), but we need something else too. I also wonder how we can formalize that something else - time-boxing it is harmful, full attention to it is harmful, having to explain it too much is harmful.

Re: Nobody's just reading your code

#175

Post by boogiewoogie »

bryanrasmussen wrote: post #58
RobertRoberts wrote: post #56

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…

I enjoy Clojure dependencies. They are usually more succinct than other languages.

Re: Nobody's just reading your code

#176

Post by karmakaze »

djhworld wrote: post #108

The thing about code reading for me is you have to have decent tooling. It's pointless reading code in Github, especially for a codebase you are not familiar with, you need to get the codebase open in an IDE to be able to dive in quickly and back again to build the map out in your head. I don't think you can read a portion of code from top to bottom without having tooling....unless the piece of code is really short a…

Absolutely this. You can always tell a PR reviewed via web. Unless it's very localized, I always open up the branch in an IDE and follow the flow through the abstractions and see if the changes make sense, and if there are additional opportunities or less clear gray areas of operation.

It will be even better when web tools catch up. Could be even better if they can navigate across repos in different languages even without even checking out a single file.

Re: Nobody's just reading your code

#177

Post by LasersGoPew »

wolfgke wrote: post #162
Ace17 wrote: post #131

Earlier quoted context omitted.

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 p…

> There are three reasons for this: > 1) [...] > 2) [...] Where is the third reason?

Classic off-by-one error.

Re: Nobody's just reading your code

#178

Post by jacinabox »

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.

And then there's the problem that you can't hardly convince the maintainer that something is an issue unless they have the issue on their OS and configuration.

Re: Nobody's just reading your code

#179

Post by convolvatron »

hinkley wrote: post #124
dingo_bat wrote: post #46

Earlier quoted context omitted.

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…

10 points for tricking it. often times its not completely broken, but may have been written with different assumptions, be failing on an avoidable edge case, or have an issue with a dependency.

knowing and deciding you can't reasonably fix it is a much better position to be in than shrugging and hoping it gets fixed in a later release, trying lots of versions or trying to refactor around it.

Re: Nobody's just reading your code

#180

Post by guruz »

wkz wrote: post #115
djhworld wrote: post #108

The thing about code reading for me is you have to have decent tooling. It's pointless reading code in Github, especially for a codebase you are not familiar with, you need to get the codebase open in an IDE to be able to dive in quickly and back again to build the map out in your head. I don't think you can read a portion of code from top to bottom without having tooling....unless the piece of code is really short a…

The one online tool that I use for this kind of work is Woboq Code Browser. It's only C/C++ projects and not many are freely available. The Linux kernel is though and I spend a lot of time in that code base. glibc, gcc and llvm are also available. https://code.woboq.org/

Which projects would you like to see on code.woboq.org? Maybe we can add them.
Post reply on HN