7 ms·

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

by curtis 9y ago

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

nathanaldensr 9y ago
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.
- andrea_sdl 9y ago
  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 downloaded and linked the sources. (Lazy, I know).
  - TeMPOraL 9y ago
    > I found myself doing it more often when the IDE itself downloaded and linked the sources. (Lazy, I know). Same here. It's about trivial inconveniences. I sometimes can be bothered to download and read through the codebase of a dependency, but most of the times I end up in third-party code happen when it's just a single jump-to-definition keypress away - the same keypress (M-.) which I use all the time for my code. That seamless browsing really blurs the difference.
  - WillReplyfFood 9y ago
    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.
- deckard1 9y ago
  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.
  - rudasn 9y ago
    7. (next morning) Fork the project, apply your PR and any others you like, and use your fork in your codebase. 8. (optional) Thank the creators and maintainers for the time and effort they put into it.
    - yoz-y 9y ago
      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.
      - RobertRoberts 9y ago
        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....)
        bryanrasmussen 9y ago
        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 beginning?
- WingH 9y ago
  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.
  - jandrese 9y ago
    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.
- deleted 9y ago
  [deleted]
radicalbyte 9y ago
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.
- sanxiyn 9y ago
  The thing is, "digging into someone else's code" is a skill, so you can get better at it, and it takes less time as you get better. It makes sense to invest some time at this skill.
- marcosdumay 9y ago
  > 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.
  - timrichard 9y ago
    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.
  - _asummers 9y ago
    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.
    - marcosdumay 9y ago
      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.
    - Bartweiss 9y ago
dingo_bat 9y ago
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.
- hinkley 9y ago
  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.
  - convolvatron 9y ago
    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.
giancarlostoro 9y ago
bsimpson still raised a good opportunity to do this: when you get a stack trace. Another idea is whenever you have no idea how something works... Or when the documentation for a certain piece does it no justice, it sure woudln't hurt to try and look under the hood to see what it's doing, sometimes you might even find comments that do a better job than the docs.
dalbasal 9y ago
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.
dalore 9y ago
A nice middle ground is to step through with the debugger when you're in your own code and see what other code it's calling that isn't yours. You don't/can't read all of it as you said. But perhaps knowing the bits your interacting with helps a lot.
rtkwe 9y ago
Along those lines are there any tools that are really good for that? I'm looking for a program that can do some things like IDA does for assembly where there's the ability to label blocks/variables and then see where it's used elsewhere etc.

by curtis 9y ago

nathanaldensr 9y ago

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.

andrea_sdl 9y ago
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 downloaded and linked the sources. (Lazy, I know).
- TeMPOraL 9y ago
  > I found myself doing it more often when the IDE itself downloaded and linked the sources. (Lazy, I know). Same here. It's about trivial inconveniences. I sometimes can be bothered to download and read through the codebase of a dependency, but most of the times I end up in third-party code happen when it's just a single jump-to-definition keypress away - the same keypress (M-.) which I use all the time for my code. That seamless browsing really blurs the difference.
- WillReplyfFood 9y ago
  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.
deckard1 9y ago
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.
- rudasn 9y ago
  7. (next morning) Fork the project, apply your PR and any others you like, and use your fork in your codebase. 8. (optional) Thank the creators and maintainers for the time and effort they put into it.
  - yoz-y 9y ago
    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.
    - RobertRoberts 9y ago
      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....)
      - bryanrasmussen 9y ago
        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 beginning?
WingH 9y ago
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.
- jandrese 9y ago
  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.
deleted 9y ago
[deleted]

radicalbyte 9y ago

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.

sanxiyn 9y ago
The thing is, "digging into someone else's code" is a skill, so you can get better at it, and it takes less time as you get better. It makes sense to invest some time at this skill.
marcosdumay 9y ago
> 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.
- timrichard 9y ago
  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.
- _asummers 9y ago
  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.
  - marcosdumay 9y ago
    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.
  - Bartweiss 9y ago

dingo_bat 9y ago

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.

hinkley 9y ago
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.
- convolvatron 9y ago
  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.

giancarlostoro 9y ago

bsimpson still raised a good opportunity to do this: when you get a stack trace. Another idea is whenever you have no idea how something works... Or when the documentation for a certain piece does it no justice, it sure woudln't hurt to try and look under the hood to see what it's doing, sometimes you might even find comments that do a better job than the docs.

dalbasal 9y ago

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.

dalore 9y ago

A nice middle ground is to step through with the debugger when you're in your own code and see what other code it's calling that isn't yours. You don't/can't read all of it as you said. But perhaps knowing the bits your interacting with helps a lot.

rtkwe 9y ago

Along those lines are there any tools that are really good for that? I'm looking for a program that can do some things like IDA does for assembly where there's the ability to label blocks/variables and then see where it's used elsewhere etc.