4 ms·

The whole thing is ridiculous. He compares a curious nerd with the hacktoberfest disaster in order to discourage people, and then describes what happens in a pr

The whole thing is ridiculous. He compares a curious nerd with the hacktoberfest disaster in order to discourage people, and then describes what happens in a professional context where you are paid to code. A "senior" developer with less than 10 years of experience, an empty GitHub repo, and a fake degree should be more humble. Sorry for the rant but he’s not helping anyone. There are abuses, but we should encourage juniors, not describe the open source world like that.

pauby 3y ago
> A "senior" developer with less than 10 years of experience, an empty GitHub repo, and a fake degree should be more humble. This says more about you than it does about them. The author is offering an opinion. You can disagree without resorting to this. You need to be better than that.
- BoingBoomTschak 3y ago
  Attacking the authority of people who start their article with an appeal to said authority isn't really far-fetched.
  - erikbye 3y ago
    Another red flag is "I use Arch Linux, btw"
janosdebugs 3y ago
Open source can be a wonderful thing when people come together and build something cool. Unfortunately, maintainer burnout has been a thing recently and part of the reason is that IT and open source are seen as a way to get a lucrative job. Some (and by no means all) people disregard the consequences of their actions to get there. Juniors should absolutely be encouraged to either build a project on their own or collaboratively, or to start by joining the community and listening before starting to write code. This is something that's lost on many and "drive-by PRs" happen a lot on high profile projects from people just wanting to say "I'm an X contributor" on their CV or get a coveted t-shirt and never come back again. These drive-by PRs come in a variety of forms. Some are just absolute nonsense, some rename things for no good reason, some refactor a part of the code that nobody asked for, and some do add a tiny bit of value, but are extremely bad quality to the point where rewriting it would take less time than going through several (dozen) review rounds explaining to the budding contributor how to write code. (Or how to even use git. Rebasing a PR is a problem for a lot of people, for example.) Maintainers of open source projects typically didn't sign up for being mentors to people who barely know how to code. More than that, these random PRs increase the noise level in the project by a lot and take away time from the contributors, junior or not, who put in way more effort that a drive-by PR author did. Leaving PRs to rot is bad because they will start having conflicts, so not reviewing them is not an option. Each of these PRs needs to be properly reviewed because they have a maintenance cost later that rests on the shoulders of the maintainers, not the contributor. Each PR carries the risk of someone introducing malicious code. Answering these PRs politely but firmly also takes quite a bit of effort. Yes, juniors should be encouraged, but realistic expectations should be set. Contributing code to a highly complex project probably isn't going to happen. They should try and contribute to small projects that they themselves know and use. That way they understand what is good an what is bad for that piece of software. Also, they should "read the room" and the contribution guide before jumping in. The best way to start is with small things: reporting issues, fixing docs bugs, and once they are comfortable with the workflow, move up to writing code. Unfortunately, communication is hard and getting this message across ("be considerate") to the right people is harder. This post has a good analogy for that with the bricks.
- lelanthran 3y ago
  > This is something that's lost on many and "drive-by PRs" happen a lot on high profile projects from people just wanting to say "I'm an X contributor" on their CV or get a coveted t-shirt and never come back again. I have a fairly controversial take on drive-by PRs: They're great IFF the submitter is an experienced developer. I did a drive-by PR on LucasChess. I tried to use LC on a Linux desktop, and there were showstopper GUI bugs. I tried on a few different distros with the same result. I looked into the code and found that a few Qt values in the Python-GUI portion had "wrong" values (i.e. they were ignored on Windows, but were honored on Linux). I made a fix. I did a few tests. I submitted the PR with a message about the bug, how to reproduce and how exactly the patch will fix the problem, and went on with my life (the very definition of a drive-by PR). The project accepted the PR as is. That's literally how projects get better: someone takes the time to diagnose a problem, make a fix, submit the fix and move on whether or not the fix is accepted. When enough people are doing this the project maintainer might be using all their project time only reviewing PRs, but at some point there's just too few bugs left in the product to take up much time on the maintainer's part. The problem is when an inexperienced developer makes a PR. Odds are good that they didn't diagnose the root problem, didn't chase down the docs (for Qt, in this case) for explanations, didn't try to replicate on different systems, didn't document what the bug is, didn't explain in the PR how to reproduce the bug, didn't test the fixes and/or never used the product themselves (I still use LC almost daily). "Experience" means "I know how to do all of the above, and have done so in the past".
  - janosdebugs 3y ago
    To me, what you are describing doesn't constitute a drive-by PR. You used the software, saw a bug, fixed it. This is the very best part of open source. (I hope the text in its entirety made that clear.) The kind of PRs I'm talking about are from people who have never and likely never will use the software, but want the badge of questionable honor of having contributed to a well-known project. The only reason they looked at the code is because they saw it in the news or someone told them to "go contribute to open source" to help their career. I don't mind a junior going to fix a but that they themselves found and know how they want the software to work. I do mind if someone goes randomly looking for something to contribute without understanding the software, how it's supposed to be used, and proceeds to expect maintainers to hand-hold them through the process of getting their contribution in so they can put it on their CV or satisfy a teachers assignment. I think what's rarely spoken about is the fact that each PR needs maintainer time. Maintainers are typically few and their time should be used to further the project, not for personal gain.
lelanthran 3y ago
> A "senior" developer with less than 10 years of experience, an empty GitHub repo, and a fake degree should be more humble. Is this a reference to the author? How can you tell that he has a fake degree?
- notresidenter 3y ago
  GP, There's no need to attack the author? "42 School" which is the "school" his degree comes from is a glorified boot camp. It's one of the popular ones (in France) It's an immediate red flag for many French tech companies when hiring. Rant: I dislike this boot camp for what it does to parents of teenagers who are promised their child will have a career in tech, but then are not taught the skills they need to grow, so they come on the job market with -2 years of experience because they have to relearn everything (but often don't want to put the effort to do so) because they are attracting lost teenagers that like playing video games, not teenagers that actually want to learn CS and/or Software Dev. So, you get unmotivated people with a bad attitude and no useful skill, as they need babysitting. Source: I've interviewed many ppl coming from this school and talked with n>10 founders about their experience hiring from there
  - firesteelrain 3y ago
    Now that you post this it puts things in a totally different light
    - datascienced 3y ago
      OTOH it is gatekeeping you need a degree to code. And a bootcamp completion is not a fake degree. No more than a CS degree is a fake programming vocational qualification.
      - firesteelrain 3y ago
        Computer Science is and was never intended to be a pathway to programming. If you want a career in software engineering then you should get a degree in Software Engineering and also a Masters in Systems Engineering. Coding bootcamps aren’t bad but in my opinion they should accompany a CS/SWE degree + Masters. You should have systems thinking skills and be a lifelong learner. It’s not a one shot
imtringued 3y ago
Coordination is real work. I have spent way too much time working on something only to realize the developer of the project knows it better than me, writes the code quickly and by the time I am about to send a pull request the developer already came up with a better solution. The problem is that most developers don't really have a "hiring strategy". People who want to commit to a project for three months or so don't really have a place to go, so they throw pull requests up and then get mad when they get rejected.
david_allison 3y ago
> an empty GitHub repo Eh? This is more than reasonable. https://github.com/samuelfaure/ https://github.com/samuelfaure/
BeetleB 3y ago
> A "senior" developer with less than 10 years of experience, an empty GitHub repo, and a fake degree should be more humble. It's hard for me to listen to anyone who judges people based on their Github repo.
- cjpearson 3y ago
  Typically, yes I agree. But if you're evaluating someone's expertise in open source contributing, looking at their open source contributions is fair game.
jackcviers3 3y ago
Gatekeeping is part of running a project -- you have the right to refuse the contributions for any reason you'd like. They, likewise, have the right to fork your project and run a new one how they see fit. Do it too much though, and you'll drive the popularity of your project way down and nobody will use it. Even with free (in both senses of the word) products, the market will always work itself out.

pauby 3y ago

> A "senior" developer with less than 10 years of experience, an empty GitHub repo, and a fake degree should be more humble. This says more about you than it does about them. The author is offering an opinion. You can disagree without resorting to this. You need to be better than that.

BoingBoomTschak 3y ago
Attacking the authority of people who start their article with an appeal to said authority isn't really far-fetched.
- erikbye 3y ago
  Another red flag is "I use Arch Linux, btw"

janosdebugs 3y ago

Open source can be a wonderful thing when people come together and build something cool. Unfortunately, maintainer burnout has been a thing recently and part of the reason is that IT and open source are seen as a way to get a lucrative job. Some (and by no means all) people disregard the consequences of their actions to get there. Juniors should absolutely be encouraged to either build a project on their own or collaboratively, or to start by joining the community and listening before starting to write code. This is something that's lost on many and "drive-by PRs" happen a lot on high profile projects from people just wanting to say "I'm an X contributor" on their CV or get a coveted t-shirt and never come back again. These drive-by PRs come in a variety of forms. Some are just absolute nonsense, some rename things for no good reason, some refactor a part of the code that nobody asked for, and some do add a tiny bit of value, but are extremely bad quality to the point where rewriting it would take less time than going through several (dozen) review rounds explaining to the budding contributor how to write code. (Or how to even use git. Rebasing a PR is a problem for a lot of people, for example.) Maintainers of open source projects typically didn't sign up for being mentors to people who barely know how to code. More than that, these random PRs increase the noise level in the project by a lot and take away time from the contributors, junior or not, who put in way more effort that a drive-by PR author did. Leaving PRs to rot is bad because they will start having conflicts, so not reviewing them is not an option. Each of these PRs needs to be properly reviewed because they have a maintenance cost later that rests on the shoulders of the maintainers, not the contributor. Each PR carries the risk of someone introducing malicious code. Answering these PRs politely but firmly also takes quite a bit of effort. Yes, juniors should be encouraged, but realistic expectations should be set. Contributing code to a highly complex project probably isn't going to happen. They should try and contribute to small projects that they themselves know and use. That way they understand what is good an what is bad for that piece of software. Also, they should "read the room" and the contribution guide before jumping in. The best way to start is with small things: reporting issues, fixing docs bugs, and once they are comfortable with the workflow, move up to writing code. Unfortunately, communication is hard and getting this message across ("be considerate") to the right people is harder. This post has a good analogy for that with the bricks.

lelanthran 3y ago
> This is something that's lost on many and "drive-by PRs" happen a lot on high profile projects from people just wanting to say "I'm an X contributor" on their CV or get a coveted t-shirt and never come back again. I have a fairly controversial take on drive-by PRs: They're great IFF the submitter is an experienced developer. I did a drive-by PR on LucasChess. I tried to use LC on a Linux desktop, and there were showstopper GUI bugs. I tried on a few different distros with the same result. I looked into the code and found that a few Qt values in the Python-GUI portion had "wrong" values (i.e. they were ignored on Windows, but were honored on Linux). I made a fix. I did a few tests. I submitted the PR with a message about the bug, how to reproduce and how exactly the patch will fix the problem, and went on with my life (the very definition of a drive-by PR). The project accepted the PR as is. That's literally how projects get better: someone takes the time to diagnose a problem, make a fix, submit the fix and move on whether or not the fix is accepted. When enough people are doing this the project maintainer might be using all their project time only reviewing PRs, but at some point there's just too few bugs left in the product to take up much time on the maintainer's part. The problem is when an inexperienced developer makes a PR. Odds are good that they didn't diagnose the root problem, didn't chase down the docs (for Qt, in this case) for explanations, didn't try to replicate on different systems, didn't document what the bug is, didn't explain in the PR how to reproduce the bug, didn't test the fixes and/or never used the product themselves (I still use LC almost daily). "Experience" means "I know how to do all of the above, and have done so in the past".
- janosdebugs 3y ago
  To me, what you are describing doesn't constitute a drive-by PR. You used the software, saw a bug, fixed it. This is the very best part of open source. (I hope the text in its entirety made that clear.) The kind of PRs I'm talking about are from people who have never and likely never will use the software, but want the badge of questionable honor of having contributed to a well-known project. The only reason they looked at the code is because they saw it in the news or someone told them to "go contribute to open source" to help their career. I don't mind a junior going to fix a but that they themselves found and know how they want the software to work. I do mind if someone goes randomly looking for something to contribute without understanding the software, how it's supposed to be used, and proceeds to expect maintainers to hand-hold them through the process of getting their contribution in so they can put it on their CV or satisfy a teachers assignment. I think what's rarely spoken about is the fact that each PR needs maintainer time. Maintainers are typically few and their time should be used to further the project, not for personal gain.

lelanthran 3y ago

> A "senior" developer with less than 10 years of experience, an empty GitHub repo, and a fake degree should be more humble. Is this a reference to the author? How can you tell that he has a fake degree?

notresidenter 3y ago
GP, There's no need to attack the author? "42 School" which is the "school" his degree comes from is a glorified boot camp. It's one of the popular ones (in France) It's an immediate red flag for many French tech companies when hiring. Rant: I dislike this boot camp for what it does to parents of teenagers who are promised their child will have a career in tech, but then are not taught the skills they need to grow, so they come on the job market with -2 years of experience because they have to relearn everything (but often don't want to put the effort to do so) because they are attracting lost teenagers that like playing video games, not teenagers that actually want to learn CS and/or Software Dev. So, you get unmotivated people with a bad attitude and no useful skill, as they need babysitting. Source: I've interviewed many ppl coming from this school and talked with n>10 founders about their experience hiring from there
- firesteelrain 3y ago
  Now that you post this it puts things in a totally different light
  - datascienced 3y ago
    OTOH it is gatekeeping you need a degree to code. And a bootcamp completion is not a fake degree. No more than a CS degree is a fake programming vocational qualification.
    - firesteelrain 3y ago
      Computer Science is and was never intended to be a pathway to programming. If you want a career in software engineering then you should get a degree in Software Engineering and also a Masters in Systems Engineering. Coding bootcamps aren’t bad but in my opinion they should accompany a CS/SWE degree + Masters. You should have systems thinking skills and be a lifelong learner. It’s not a one shot

imtringued 3y ago

Coordination is real work. I have spent way too much time working on something only to realize the developer of the project knows it better than me, writes the code quickly and by the time I am about to send a pull request the developer already came up with a better solution. The problem is that most developers don't really have a "hiring strategy". People who want to commit to a project for three months or so don't really have a place to go, so they throw pull requests up and then get mad when they get rejected.

david_allison 3y ago

> an empty GitHub repo Eh? This is more than reasonable. https://github.com/samuelfaure/ https://github.com/samuelfaure/

BeetleB 3y ago

> A "senior" developer with less than 10 years of experience, an empty GitHub repo, and a fake degree should be more humble. It's hard for me to listen to anyone who judges people based on their Github repo.

cjpearson 3y ago
Typically, yes I agree. But if you're evaluating someone's expertise in open source contributing, looking at their open source contributions is fair game.

jackcviers3 3y ago

Gatekeeping is part of running a project -- you have the right to refuse the contributions for any reason you'd like. They, likewise, have the right to fork your project and run a new one how they see fit. Do it too much though, and you'll drive the popularity of your project way down and nobody will use it. Even with free (in both senses of the word) products, the market will always work itself out.