6 ms·

> Think you found a bug? Fork the repo, add a failing test Ugh. No. 999 times out of 1000, the person maintaining the code actually knows what it does and how

> Think you found a bug? Fork the repo, add a failing test Ugh. No. 999 times out of 1000, the person maintaining the code actually knows what it does and how it works. And if I'm not that person, I don't. I found a problem. The problem affects me. It also probably affects other people. I'm an intelligent, capable, curious, knowledgeable, and caring professional software developer. I write code for fun, but I write _my_ code for fun. And after that I don't have the energy or the inclination to learn how your shit works deep down where it matters. Because what will take you a minute, will take me a month unless I stop going to work every day. I will do my best to describe what I was doing when the problem occurred, what I expected to happen, and what happened instead, but screw you if you think I need to understand your codebase or your testing infrastructure in order to report a problem.

blazespin 9y ago
You're being sarcastic, right? This is OS. It's fundamental underpinning is that if you want to use it (or at least engage its maintainers), you have to care. That being said, maybe there could be a "found problem, not sure is a bug" flag that defaults to on. Or a warning dialog that says "without example code or detailed repro, this issue probably won't be looked at."
- BugsJustFindMe 9y ago
  > You're being sarcastic, right? This is OS. It's fundamental underpinning is that if you want to use it (or at least engage its maintainers), you have to care. Ugh. My partner, who doesn't know the first thing about code, understands the value of FOSS. Caring about FOSS doesn't fix bugs. A month ago (more?) I encountered a bug in LibreOffice Writer, which I use because it's really good, where track changes on a docx file wasn't working properly in a particular situation involving the deletion of tracked comments across saves. QUICK! Find the line of code that caused it! Find the mechanism for creating a test case! I'll wait here. Back here in the real world I was able to report the bug and have it fixed by someone who knows what the code does.
  - tinus_hn 9y ago
    You can't really compare a huge end-user product to a developer library though. Developers are supposed to be able to write code.
    - BugsJustFindMe 9y ago
      The world isn't all NPM left-pad modules. Code is arbitrarily complex.
    - cortesoft 9y ago
      There are libraries that are as complex as a large end-user product.
      - yjftsjthsd-h 9y ago
        Don't stop there: plenty of libraries are more complex than the applications using them. More complex, more general, used by more people. I mean, just libc and curl probably dwarf most applications that consume them.
      - tinus_hn 9y ago
        > ... turned off github issues on one of his smaller projects. ...
  - joeberon 9y ago
    Please stop saying "ugh" this teenage talk stuff is really annoying.
    - BugsJustFindMe 9y ago
      Ugh. Stop giving me a reason to say it.
  - blazespin 9y ago
    You're confusing an application versus an API which is what this thread was about.
robotresearcher 9y ago
Do whatever you want. But if the developer who gave you the fruits of their labour for free proposes a way to report bugs that works best for them, take it or leave it, or recommend a different approach in a civil tone if you must. But 'screw you'? Not classy. Also, many Github-hosted projects are critical infrastructure for some people. They will make it as easy as possible for the developer to fix their bugs, if they are rational.
- BinaryIdiot 9y ago
  > But 'screw you'? Not classy. To be fair that's exactly the tone I read the gist in as well. It seems a bit overly hostile to users who may have questions or suggestions but either don't or cannot contribute code for whatever reason. Emotional comments beget emotional comments.
  - robotresearcher 9y ago
    That's very true. But the relationship between developer and user is not symmetrical. I'll give the grumpy developer a pass that grumpy end user didn't earn. Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Once you have a few thousand users your inbox is a source of frequent misery.
    - BinaryIdiot 9y ago
      > But the relationship between developer and user is not symmetrical. I disagree. I see them as identical. Yes you're offering a free product but it's still a product, even if you don't want to call it one. The developers are your users. They are the ones using it. But even a developer may not know how your code works well enough to submit a PR. > Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Once you have a few thousand users your inbox is a source of frequent misery. For sure but I don't know how you avoid this without also isolating yourself from likely valuable feedback / information. Similar to fielding customer requests for a product a good 96% of the ideas / things customers want are going to be a terrible idea. If I've learned anything from running products it's this: make it as stupid easy as possible for your customers to give you feedback / get ahold of you. When you do that you're going to get an absolute ton of noise but the bits of signal hidden in there can be amazing and you'll be able to directly help those along the way. From there it's learning how to manage the flow of information coming to you and trying not to take the bad personally (which is very hard to do when it's your baby / code).
nperez 9y ago
So you take code you don't understand and don't want to understand, and you use it to power someone else's business? Doesn't sound safe or professional to me. You don't need to understand everything about every dependency, but you should absolutely be willing to dig in a little
- BugsJustFindMe 9y ago
  > So you take code you don't understand and don't want to understand, and you use it to power someone else's business? This is what we call a strawman. Also, I guarantee that you do exactly what you're glibly dismissing every day of your life.
  - deleted 9y ago
    [deleted]
  - rocky1138 9y ago
    Yeah. I mean, taken to the nth degree, even driving a car is doing that. Surely the parent gets on a bus, drives a car, rides a bicycle, etc.
- shusson 9y ago
  > So you take code you don't understand and don't want to understand, and you use it to power someone else's business? Doesn't sound safe or professional to me That attitude sounds crippling to being productive. At some point you have to trust code based on usage, brand, peer-reviews etc.
- makomk 9y ago
  Aside from the fact that everyone relies on code that they don't understand, looking at the code probably isn't going to tell you all that much about how it's meant to work, which is rather important when trying to fix a bug.
nine_k 9y ago
If you can reproduce an issue with your code, you mostly have a failing test already. The open-source product in question seems to be a library. For a command line tool you can write a shell script demonstrating the problem.
vxNsr 9y ago
Just ran into this at work, I have a manger who was maintaining an internal app and he asked me to take over because there was a bug and he was transitioning away from the techinicial aspects of his job. Anyway like, 2 days later he asks if I've fixed it yet. No I haven't fixed your cobbled together app that has no comments and generic variable names.

blazespin 9y ago

You're being sarcastic, right? This is OS. It's fundamental underpinning is that if you want to use it (or at least engage its maintainers), you have to care. That being said, maybe there could be a "found problem, not sure is a bug" flag that defaults to on. Or a warning dialog that says "without example code or detailed repro, this issue probably won't be looked at."

BugsJustFindMe 9y ago
> You're being sarcastic, right? This is OS. It's fundamental underpinning is that if you want to use it (or at least engage its maintainers), you have to care. Ugh. My partner, who doesn't know the first thing about code, understands the value of FOSS. Caring about FOSS doesn't fix bugs. A month ago (more?) I encountered a bug in LibreOffice Writer, which I use because it's really good, where track changes on a docx file wasn't working properly in a particular situation involving the deletion of tracked comments across saves. QUICK! Find the line of code that caused it! Find the mechanism for creating a test case! I'll wait here. Back here in the real world I was able to report the bug and have it fixed by someone who knows what the code does.
- tinus_hn 9y ago
  You can't really compare a huge end-user product to a developer library though. Developers are supposed to be able to write code.
  - BugsJustFindMe 9y ago
    The world isn't all NPM left-pad modules. Code is arbitrarily complex.
  - cortesoft 9y ago
    There are libraries that are as complex as a large end-user product.
    - yjftsjthsd-h 9y ago
      Don't stop there: plenty of libraries are more complex than the applications using them. More complex, more general, used by more people. I mean, just libc and curl probably dwarf most applications that consume them.
    - tinus_hn 9y ago
      > ... turned off github issues on one of his smaller projects. ...
- joeberon 9y ago
  Please stop saying "ugh" this teenage talk stuff is really annoying.
  - BugsJustFindMe 9y ago
    Ugh. Stop giving me a reason to say it.
- blazespin 9y ago
  You're confusing an application versus an API which is what this thread was about.

robotresearcher 9y ago

Do whatever you want. But if the developer who gave you the fruits of their labour for free proposes a way to report bugs that works best for them, take it or leave it, or recommend a different approach in a civil tone if you must. But 'screw you'? Not classy. Also, many Github-hosted projects are critical infrastructure for some people. They will make it as easy as possible for the developer to fix their bugs, if they are rational.

BinaryIdiot 9y ago
> But 'screw you'? Not classy. To be fair that's exactly the tone I read the gist in as well. It seems a bit overly hostile to users who may have questions or suggestions but either don't or cannot contribute code for whatever reason. Emotional comments beget emotional comments.
- robotresearcher 9y ago
  That's very true. But the relationship between developer and user is not symmetrical. I'll give the grumpy developer a pass that grumpy end user didn't earn. Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Once you have a few thousand users your inbox is a source of frequent misery.
  - BinaryIdiot 9y ago
    > But the relationship between developer and user is not symmetrical. I disagree. I see them as identical. Yes you're offering a free product but it's still a product, even if you don't want to call it one. The developers are your users. They are the ones using it. But even a developer may not know how your code works well enough to submit a PR. > Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Once you have a few thousand users your inbox is a source of frequent misery. For sure but I don't know how you avoid this without also isolating yourself from likely valuable feedback / information. Similar to fielding customer requests for a product a good 96% of the ideas / things customers want are going to be a terrible idea. If I've learned anything from running products it's this: make it as stupid easy as possible for your customers to give you feedback / get ahold of you. When you do that you're going to get an absolute ton of noise but the bits of signal hidden in there can be amazing and you'll be able to directly help those along the way. From there it's learning how to manage the flow of information coming to you and trying not to take the bad personally (which is very hard to do when it's your baby / code).

nperez 9y ago

So you take code you don't understand and don't want to understand, and you use it to power someone else's business? Doesn't sound safe or professional to me. You don't need to understand everything about every dependency, but you should absolutely be willing to dig in a little

BugsJustFindMe 9y ago
> So you take code you don't understand and don't want to understand, and you use it to power someone else's business? This is what we call a strawman. Also, I guarantee that you do exactly what you're glibly dismissing every day of your life.
- deleted 9y ago
  [deleted]
- rocky1138 9y ago
  Yeah. I mean, taken to the nth degree, even driving a car is doing that. Surely the parent gets on a bus, drives a car, rides a bicycle, etc.
shusson 9y ago
> So you take code you don't understand and don't want to understand, and you use it to power someone else's business? Doesn't sound safe or professional to me That attitude sounds crippling to being productive. At some point you have to trust code based on usage, brand, peer-reviews etc.
makomk 9y ago
Aside from the fact that everyone relies on code that they don't understand, looking at the code probably isn't going to tell you all that much about how it's meant to work, which is rather important when trying to fix a bug.

nine_k 9y ago

If you can reproduce an issue with your code, you mostly have a failing test already. The open-source product in question seems to be a library. For a command line tool you can write a shell script demonstrating the problem.

vxNsr 9y ago

Just ran into this at work, I have a manger who was maintaining an internal app and he asked me to take over because there was a bug and he was transitioning away from the techinicial aspects of his job. Anyway like, 2 days later he asks if I've fixed it yet. No I haven't fixed your cobbled together app that has no comments and generic variable names.