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.
Is this a reference to the author? How can you tell that he has a fake degree?
"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
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
I think there's a clear distinction between CS and Software Dev.
The latter _can_ be self-taught, or learned with a bootcamp, if it's good. It's essentially a trade which means practice is everything. And also includes a good bit of project management.
The former is a scientific field, much like physics, sociology, etc. and having a CS degree is useful for doing research (which in CS could mean coding, and could mean writing software, e.g a new type of database/algorithm/other) hence the confusion between the two. And some/most Software Devs need to understand/improve/adapt artifacts from the field of CS, so a CS degree is often beneficial for software devs, but not needed.
So, I don't think it's fair to say that it's a 'fake programming vocational qualification', it's not what it's for, and people that say the contrary misunderstand what a CS degree is.
It's hard for me to listen to anyone who judges people based on their Github repo.
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.
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".
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.
I agree with the GP's definition. I consider a drive-by PR to be one made by someone who doesn't intend to become a regular contributor to the project but does have real motivation as a user of the project to get their "itch scratched" (a bug fixed or some feature that matters to them added).
I also understand the type of PR you're describing (and agree with you that it's a bad idea) but I think it needs another term to describe it. Maybe "non user PR" or "CV driven PR" or "Vanity PR"?
(edit sp)
Drive-by PR simply means that the PR author is not a known community member resp. doesn't plan to become a regular contributor.
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.
Even with free (in both senses of the word) products, the market will always work itself out.
Eh? This is more than reasonable. https://github.com/samuelfaure/
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.