"WhY nOt MaKe An OpEn SoUrCe CoNtRiBuTiOn?", they say

Because it's almost never worth it, you fvcking dumbass.

The context

I could have ended the whole blog post there, but I being the benevolent person I am (?) decide to tell more about the story. This reddit post, one day, showed up in my feed. (now that I think about it this is actually pretty messed up to post in r/learnprogramming). Now, if this does not sound like those not-junior-anymore-but-not-quite-senior-enough feel-good mediocre's bullshittery, I don't know what else is.

Everyone with a rudimentary understanding of human society's navigating strategies would almost certainly (if not definitely) agree that if something is certain to yield a profit, then everyone would start thinking about doing it; and if the thing in question is easy, then everyone would definitely be doing it. Profit, in this case, with "getting hired" being a competition, can have both ways:

Now, with the rules said above, we can conclude two reasons why people aren't doing that much "OpEn SoUrCe CoNtRiBuTiOn" as this "hiring manager" would like to see:

The "Too Long; Didn't Read"

To conclude:

The problem of reading other people's code

Because the person in question is a "HiRiNg MaNaGeR", chances are he/she/they are already far away from the dev work for a long time. Maybe back in the junior years he did the same thing and somehow succeeded with serious luck, got his job with serious luck, got promoted with serious luck, did not have to read big code bases without any kind of previous knowledge all on his/her/their own (like I did[1]) with serious luck, thus somehow believing all of that luck is his/her/their own abilities and everybody should be able to do the same thing. What kind of serious cluelessness is that!?

Listen well. To contribute meaningful work on a code base requires you to firstly understand the code base, which has always been a pain in the ass without exceptions, especially more so if there's not enough documentation. People write shitty code all the time, no matter how good they are. Code base quality deteriorates all the time. Code readability is fundamentally a myth, because code does not represent knowledge of any kind, code is merely artifact. Creating something anew almost always cost less than fixing things in this industry, that's why it's always the case that everybody wants to rewrite an old existing project but nobody dares to refactor, and if all you do is hiring people chances are you never had any sensible idea about all this.

The greatest common divisor

Strategies of the employees are shaped by the requirements of the employer. If we *are* talking about getting a job - if one becomes a software dev solely for the money, you can bet your uncultured ass he/she/they will "pick the low-hanging fruits" to maximize the chance of them landing a job in the most efficient way possible, which currently involves grinding LeetCode (bleh), memorizing interview questions and - surprise, surprise - "turtorial projects" built with the most popular, the newest shiniest languages and frameworks - because instead of some random open source project out on the Internet, companies actually use these techs for their projects! When the extra effort does not necessarily translate to a higher chance of employment, good luck having anyone truly believing and following your self-entitled employment "aDvIcEs".

But let's consider the most impossible case, the case where the stars aligned. To effectively execute all this, it requires:

Then, and only then, did all the time and energy spent on every single aspect of this whole process produces something that you can put in your CV. That surely looks like something that happens all the time, just waiting for students freshly graduated from CS school to find out about!

Jesus fvcking Christ.


From a dev standpoint, I sincerely doubt that these "mAnAgErS" had any kind of experiences in development or even serious talks with any software dev, and if they did, that's even worse, and I would absolutely go as far as to suck some ugly bastards's dicks just to make sure that I don't have to work with people with this amount of cluenessness.

Now to be clear I'm not saying everyone needs to be a core maintainer on ReactJS or something. But if you graduate and don't have the ability to make any contribution, then you may not have the ability to work a full time job.

Seriously? If they did not have "contributing" GitHub profiles they look like incapable of coordinating to you? FUCK YOU. GO TO HELL.

[1] I was asked to read Chromium code as well but that whole thing was a different story.
[2] Sure, call me a [insert-your-favourite-slur-of-choice-here] all you want. Exactly the reason I have been wanting to quit software development after all these years: shameless self-entitlement, hipster name cargo cult evangelism strike forces, all kinds of common asshole mentalities. Programming (as I know it) is a painful thankless job, and there's always some people just have to ruin it further more for everyone involved.

Hiring is almost always a retrospective thing: you can never accurately summarize a person & his/her/their skill in time as short as a quick read of something that's already a painful oversimplification of him/her/them. You can always try your best but no rule based on CV can give you a perfectly good candidate filter - you are bound to filter out the "right people" and letting the "wrong people" in sooner or later.

To determine whether a candidate did do his/her/their own thinking or not when doing the "TuRtOrIaL pRoJeCt"s is, in fact, not as hard as some people might think: you can pick out a design problem that requires a certain amount of problem solving skills, and ask them why they chose to do things the way they've chosen. But that requires actually giving a chance for the candidate to be interviewed with a real person (instead of some soulless rule machines like "HaViNg OpEn SoUrCe CoNtRiBuTiOnS") and the interviewer to have decent tech fluency, which for some MaNaGeRs might just be too high of a hurdle.