4 ms·

I don't think this is an unfair generalization. You need at least one of the three: patience, skill, experience. I am not sure who would argue with that. If you

I don't think this is an unfair generalization. You need at least one of the three: patience, skill, experience. I am not sure who would argue with that. If you lack skill and experience, it's no problem. But if you begin to get frustrated as soon as you receive feedback... you're going to have a bad time. I've seen some truly impressive contributions over the years and the common element that stands out isn't the authors' skills or experience (even those can't always help you) but _patience_. Be kind, expect to be treated kindly, and just take your time. Breathe. If you receive feedback that bothers you, put it away. Sit on it and come back to in a week, or month, or whatever. Or walk away -- it's your choice. But the ones who are patient almost always succeed. And if it's the maintainers who lack patience, or they've dropped off the face of the earth -- just fork and move on with your life. That's the spirit of the whole thing, after all.

klelatti 5y ago
> bug ridden garbage > expect to be treated kindly Do you see why the first might make someone doubt the second?
- xyzzy_plugh 5y ago
  I didn't give that feedback to a contributor. I didn't encourage maintainers to insult contributors. If you don't know what you're doing and you don't know that you don't know what you're doing, then yes it's likely what you produce will be both bug ridden and garbage. It takes time and patience to refine it into something good. It doesn't mean you shouldn't try. If you, or anyone else -- colleague, stranger, whatever -- submitted bug-ridden garbage, I'd spend time and energy to review your contribution, give you constructive feedback to the best of my ability, and hope for the best. Hell, most _production_ software is bug-ridden garbage. I've written lots of bug-ridden garbage. I'm just calling a spade a spade. If this turns you off contributing to open source, I don't know what to tell you. It's just reality.
  - ghusbands 5y ago
    Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind, which will be visible in other ways and will turn some people away. It can help your outlook on the world and your impact on others to make an effort to think less negatively.
    - coldtea 5y ago
      >Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind Or an accurate depiction of reality.
    - zozbot234 5y ago
      > Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind Far from it. In fact, the best thing about a correctness-oriented language like Rust is that you can immediately tell when stuff does not compute (the compiler will error out with a useful diagnostic, or else it will be in a small 'unsafe' block with easy to check safety conditions). Which makes it way easier to be less judgmental about all sorts of stuff.
      - carlmr 5y ago
        This really describes quite well why Rust is such a joyful language to work in. You might still write garbage, but the compiler constrains the types of garbage you can write to a much smaller subset. Whenever people say that a skillful programmer can write well-working C++, I don't disagree, but in my experience it continues to fail on projects with more people involved. If your project has size N=1, and you're skillful it's not an issue, if you have N=2 or N=3, you might still be able to review everything and find very competent contributors. But for bigger N, at some point you'll have average or below average skilled contributors in the project, you won't be able to review all contributions. A strongly typed language, strict compiler, standard formatter, and standard linter however can scale in this way. Rust offers all of these.
    - he_is_legend 5y ago
      Sometimes honesty and truth can hurt. Sometimes you have to accept that and move on. Alternatively you can coddle people so that they think every thing that they do is wonderful and a gift to all of mankind. Or you can take offence at honest criticism everything and ... well here we are. Word policing, and overbearing nicety as form of karma currency are not good things. Adults sometimes call each other not nice names. The world is not a cosy blanket left in the sun covered with kittens.
- bluedino 5y ago
  It's a harsh reality. The best team can't be welcoming to sub-par players. At least not on game day.
  - khalladay 5y ago
    This is a weird stance to take. Software development is not sports. There is no "game day," and the best teams I've worked on have managed to treat folks with respect while still maintaining a high degree of quality. You can treat people kindly without having to agree with their opinions, or taking their PRs. If you are already going to reply or interact with them, it costs the same to be kind as it does to be a jerk.
    - SomeCallMeTim 5y ago
      >You can treat people kindly without having to agree with their opinions, or taking their PRs. I think that having your PR rejected, no matter how "kindly" you phrase the rejection, is not going to feel good. So "treating them kindly" and "rejecting their PR outright" is a contradiction. Sometimes you just have to tell someone their PR isn't going to work out; that it doesn't just need a few tweaks, but rather a start-from-scratch approach that's 100% different. Flowery language aside, that's going to sting. The "game day" analogy is maybe not a great one, but I get what they're saying: Sometimes you can't afford to spend the time that would be required to educate everyone on exactly how to change their PR so it would be appropriate. Where truly "treating people kindly" would take more of a time commitment than writing the code yourself the correct way, where it would really mean training a junior developer up to mid-tier or senior developer level? It's just not compatible with getting the work done you're responsible for. You can't spend all of your time coddling every potential contributor. So sometimes you just have to say, "Sorry, no, this PR just won't work." Where that's the kindest thing you can say given your constraints. Maybe that's all you mean by "kindness," but the person receiving that comment probably won't see it as very kind. Rejection simply never feels good.
oreally 5y ago
'patience' that's why these projects never get many things moving forward and those higher up in the project's hierarchy seem to contribute way more. Also this is why younger, hungrier contributors should avoid these types of organizations and why these orgs will suffer sooner or later from certain bias. Ever heard of the quantity vs quality pottery story? You want to make mistakes and iterate on those to quality. Get the software working, then worry about styles and idiomatics. That seems lost on people nowadays.
- mixedCase 5y ago
  That's what code review in a PR is for. Iterate all you need, and people experienced in the codebase will help you point out your mistakes so you can iterate some more until the maintenance burden you're shifting onto someone else is reasonable.
  - oreally 5y ago
    Sure you can do it in a PR. But this assumes that the feature is tested in isolation and not in conjunction with the rest the software. And the software really should be worked on as a whole.
bluedino 5y ago
> You need at least one of the three: patience, skill, experience. I had a boss who was a self-admitted terrible programmer. I witnessed some of the worst practices ever while working there. His quote was, "don't underestimate a persistent idiot (programmer) with a lot of time on his hands. He'll get it 'almost right', eventually"

klelatti 5y ago

> bug ridden garbage > expect to be treated kindly Do you see why the first might make someone doubt the second?

xyzzy_plugh 5y ago
I didn't give that feedback to a contributor. I didn't encourage maintainers to insult contributors. If you don't know what you're doing and you don't know that you don't know what you're doing, then yes it's likely what you produce will be both bug ridden and garbage. It takes time and patience to refine it into something good. It doesn't mean you shouldn't try. If you, or anyone else -- colleague, stranger, whatever -- submitted bug-ridden garbage, I'd spend time and energy to review your contribution, give you constructive feedback to the best of my ability, and hope for the best. Hell, most _production_ software is bug-ridden garbage. I've written lots of bug-ridden garbage. I'm just calling a spade a spade. If this turns you off contributing to open source, I don't know what to tell you. It's just reality.
- ghusbands 5y ago
  Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind, which will be visible in other ways and will turn some people away. It can help your outlook on the world and your impact on others to make an effort to think less negatively.
  - coldtea 5y ago
    >Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind Or an accurate depiction of reality.
  - zozbot234 5y ago
    > Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind Far from it. In fact, the best thing about a correctness-oriented language like Rust is that you can immediately tell when stuff does not compute (the compiler will error out with a useful diagnostic, or else it will be in a small 'unsafe' block with easy to check safety conditions). Which makes it way easier to be less judgmental about all sorts of stuff.
    - carlmr 5y ago
      This really describes quite well why Rust is such a joyful language to work in. You might still write garbage, but the compiler constrains the types of garbage you can write to a much smaller subset. Whenever people say that a skillful programmer can write well-working C++, I don't disagree, but in my experience it continues to fail on projects with more people involved. If your project has size N=1, and you're skillful it's not an issue, if you have N=2 or N=3, you might still be able to review everything and find very competent contributors. But for bigger N, at some point you'll have average or below average skilled contributors in the project, you won't be able to review all contributions. A strongly typed language, strict compiler, standard formatter, and standard linter however can scale in this way. Rust offers all of these.
  - he_is_legend 5y ago
    Sometimes honesty and truth can hurt. Sometimes you have to accept that and move on. Alternatively you can coddle people so that they think every thing that they do is wonderful and a gift to all of mankind. Or you can take offence at honest criticism everything and ... well here we are. Word policing, and overbearing nicety as form of karma currency are not good things. Adults sometimes call each other not nice names. The world is not a cosy blanket left in the sun covered with kittens.
bluedino 5y ago
It's a harsh reality. The best team can't be welcoming to sub-par players. At least not on game day.
- khalladay 5y ago
  This is a weird stance to take. Software development is not sports. There is no "game day," and the best teams I've worked on have managed to treat folks with respect while still maintaining a high degree of quality. You can treat people kindly without having to agree with their opinions, or taking their PRs. If you are already going to reply or interact with them, it costs the same to be kind as it does to be a jerk.
  - SomeCallMeTim 5y ago
    >You can treat people kindly without having to agree with their opinions, or taking their PRs. I think that having your PR rejected, no matter how "kindly" you phrase the rejection, is not going to feel good. So "treating them kindly" and "rejecting their PR outright" is a contradiction. Sometimes you just have to tell someone their PR isn't going to work out; that it doesn't just need a few tweaks, but rather a start-from-scratch approach that's 100% different. Flowery language aside, that's going to sting. The "game day" analogy is maybe not a great one, but I get what they're saying: Sometimes you can't afford to spend the time that would be required to educate everyone on exactly how to change their PR so it would be appropriate. Where truly "treating people kindly" would take more of a time commitment than writing the code yourself the correct way, where it would really mean training a junior developer up to mid-tier or senior developer level? It's just not compatible with getting the work done you're responsible for. You can't spend all of your time coddling every potential contributor. So sometimes you just have to say, "Sorry, no, this PR just won't work." Where that's the kindest thing you can say given your constraints. Maybe that's all you mean by "kindness," but the person receiving that comment probably won't see it as very kind. Rejection simply never feels good.

oreally 5y ago

'patience' that's why these projects never get many things moving forward and those higher up in the project's hierarchy seem to contribute way more. Also this is why younger, hungrier contributors should avoid these types of organizations and why these orgs will suffer sooner or later from certain bias. Ever heard of the quantity vs quality pottery story? You want to make mistakes and iterate on those to quality. Get the software working, then worry about styles and idiomatics. That seems lost on people nowadays.

mixedCase 5y ago
That's what code review in a PR is for. Iterate all you need, and people experienced in the codebase will help you point out your mistakes so you can iterate some more until the maintenance burden you're shifting onto someone else is reasonable.
- oreally 5y ago
  Sure you can do it in a PR. But this assumes that the feature is tested in isolation and not in conjunction with the rest the software. And the software really should be worked on as a whole.

bluedino 5y ago

> You need at least one of the three: patience, skill, experience. I had a boss who was a self-admitted terrible programmer. I witnessed some of the worst practices ever while working there. His quote was, "don't underestimate a persistent idiot (programmer) with a lot of time on his hands. He'll get it 'almost right', eventually"