Live data from Hacker News

Nobody's just reading your code

akkartik.name

161–170 of 188 posts

Re: Nobody's just reading your code

#161

I agree most programmers are too quick to write before they read, but I'm not sure why it has to be "for fun". Reading code takes effort, just like understanding any new complex thing. The primary virtue here is patience . It's a lot like debugging actually: the goal is to understand. Setting aside the "for fun", of course I read my co-workers' code, but also I read my dependencies' code quite often. In particular wh…

This is what I've been working on for the past few months. I've been writing a lot of spaghetti code in the past and come back to find how poorly I organized it. I'm suppressing the urge to immediately write code, but rather, look at the big picture first, digesting the information, even if it means prolonging writing anything for a day or several hours.

I usually write pseudocode first before doing anything now. Either on paper, as code comments, or as a list. Sometimes I find myself writing tests on paper as well, it helps out a lot too. A programming language is just a means to an end, what they all have in common is a set of logic to follow.

Then I debug. I just fork the code, comment things out, add a little bit of functionality, etc. When I have a grasp on it write some TDD

I find the easiest codebase that I refer a lot is the todomvc, or any similar ones that have different implementations (differnet languages) for the same general solution. All the core logic between languages is mostly the same, so its easy to dig through and understand a different programming language / how its generally organized.

One thing I remember learning about from experience polyglot programmers. Its extremely helpful to have an existing codebase you've written (such as todoMVC), and using that same example / porting it over in a different language to learn that languages nuances.

Re: Nobody's just reading your code

#162
post #131

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

> There are three reasons for this:

> 1) [...]

> 2) [...]

Where is the third reason?

Re: Nobody's just reading your code

#163

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…

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

I can't speak for him and I don't know about you, but while deciding whether I would start to work on something, I'm actually deciding if I'm capable of doing it and looking at all the pieces needed to do it. I'm not starting work until I know I have all the pieces in place. Sometimes I may doubt that some piece is missing or might be hard to do, so I make a very small prototype of that system only (this usually takes a couple of hours tops). Once I make a decision and start working, I never go back.

Just like him, I have never regretted doing it myself, but have regretted using another developer's library many times.

Re: Nobody's just reading your code

#164
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,…

It comes down to unknown unknowns. Should I poll my supervisor/co-worker about every problem to see if there is already a solution? As the new guy, I have no idea who or what I should poll people about.

The second problem is that people will keep stuff hidden. Have that sweet script that creates 1000 users for testing? You might share it with the team, you might also think its too trivial to bother sharing.

That being said, I can see how it can be frustrating. We have packages upon packages of existing functionality, languishing somewhere in source control, used maybe only once. In the meantime, someone is going through the cycle, not only of ignoring what someone put on gitub, but what has already been tested and qa'd by their own company.

Re: Nobody's just reading your code

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

Do you consider the OS a "library"? Who checks the OS's code before shipping a program? What about the programming language's code? Do you code in assembly to reduce the amount of dependencies?

Re: Nobody's just reading your code

#166

Earlier quoted context omitted.

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

It comes down to unknown unknowns. Should I poll my supervisor/co-worker about every problem to see if there is already a solution? As the new guy, I have no idea who or what I should poll people about. The second problem is that people will keep stuff hidden. Have that sweet script that creates 1000 users for testing? You might share it with the team, you might also think its too trivial to bother sharing. That bein…

> Should I poll my supervisor/co-worker about every problem to see if there is already a solution? As the new guy, I have no idea who or what I should poll people about.

It helps to have a company culture that encourages openness and asking questions. My current company goes so far as to have a Slack channel, #askanything, where folks can ask anything. We'd much rather you ask early in the development process than pursue a path that will lead to duplication.

Re: Nobody's just reading your code

#167

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…

Solid upvote and the map analogy is great. I think this is a very important point. We often think of a 'program' as a flat blog of text, but we really should have tools to explore various projections of both static and dynamic constructs that form the program. We should be able to view the high level system view of the running program, and query various interconnections.

Re: Nobody's just reading your code

#168

Earlier quoted context omitted.

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.

webpack. My dependency was webpack.

It was a dependency of webpack that was broken (you can pick your bride, but you can't pick your bride's family). And the package owner, in a Github Issue said "not my problem, this package should never be used with webpack and should only be used with Browserify." Looking at the date, that Issue discussion occurred in 2015. Which makes sense. But a WONTFIX on a package that obviously is broken (I looked at the code), and is still an issue in 2018 is clearly a problem. The node world is a circular firing squad where no one wants to take responsibility for fixing their shit because each person thinks they are doing the right thing. When, thanks to the mess of npm, no one really knows who the "user" of their package is and you can't just dictate that so-and-so shouldn't be using your package that way. Because someone will use your package that way.

WONTFIX, issues just suddenly "closed" without reason (why, dammit??), or pull request queues 100+ long and obviously unmaintained are way too common for me. I've lost track of the number of times this has occurred.

Re: Nobody's just reading your code

#169
post #130

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.

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.

Or they look at the tradeoff of:

1. I could dive into the code, find the bug, submit the report and hope the developer accepts the patch. Hopefully this bug isn't there because it is required by some other feature the developer actually cares about.

2. That module wasn't doing that much, I can just redo it by hand and dump the dependency.

3. I could hunt around for a different module that does basically the same thing and use it instead. This might be necessary if the module is doing a lot of work, like an ASN.1 parser or something.

Re: Nobody's just reading your code

#170
post #135

Earlier quoted context omitted.

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.

That can be okay. Depending on the nature of the library it might legitimately be "done." Personally, I would rather see this than a bug fix being committed every week. That makes me question how many more bugs there are and how much I'm going to have to babysit updating the dependency.

That's a great point. Hmmm... I wasn't considering that. Oops. I'm glad I mentioned it! Thanks!
Post reply on HN