True, I'm thinking of the average 14 year old who is well, average. Do you really think the average kid spends their time writing code?
Anyways, the part I'm considering insane is the parents, should have clarified. Career opportunities for a 14 year old, sheesh.
If the kid wants to learn programming, there are much better avenues then going to sit in an office. For example, they can make a game mod / Roblox game, etc.
That's kind of insane. The most I'd think a 14 year old would be interested in is learning some browser related tricks (inspecting requests, elements, etc). On the technical side of things, unix utilities like ping / nano would be a good bet.
For day to day related work, just show how you decide what to work on? Maybe go through an instance of investigating a task?
So... if I have a handicap, I should look at it as an opportunity or challenge? I should just rise-up to the challenge? Yeah, well, if I don't have any options, then I'll make do.
I really only see lack of empathy in your response. Stuttering is a handicap, plain and simple. Yes, some of us can live with it. It is debilitating and humiliating and if you do not suffer from it, I can't imagine how you can begin prescribing advice. You can have the universe, I just want to order some coffee (thank god for self-serve POS).
How can it be wasted time if you're able to build context and a mental model of the repo? The whole point is to "rapidly improve at any programming language" right? Sure, you're not going to contribute net new code but you'll be primed and ready to contribute in the future while achieving your original goal. Whether or not this works, I don't know. But dismissing it as worthless is kind of a stretch and offensive. But thanks for your opinion.
I feel like the approach the author laid out near the end is passive and would lead to one assuming they have retained some knowledge. At the most, it would help someone avoid a similar bug/mistake.
A better approach would be to checkout the repo at a commit before the fix and try to replicate the solution in a short amount of time. You would then build context around what the contributor had to figure out and in the worst case you'll have a "gold standard" solution to fallback on (assuming the PR was successful).
You are proving exactly why we need a standardized way to judge whether a candidate is hirable. All the candidates I see have almost zero history of contributing to OSS or maintaining side projects. Their work history usually consists of some run of the mill experience.
I have to rely on that and absolutely do not expect them to have a green GitHub. I would hate for that to become the norm.
That is why we need to ascertain coding signal. And that is why we need some contrived problem to provide to ascertain within a reasonable amount of time whether a candidate is a yes/no.
You are a unique data point and hundreds and thousands of other developers just don't have that kind of clout (I didn't look through your resume thing).
Also, from a hiring perspective, it's not scalable going through a candidates repos and verifying their worthiness. However, it is fun to talk about them during interviews.
It is a kind of like a CMS/ERP for agtech. I am using it for basic farm management purposes like inventorying equipment, chemicals, etc. It is built on Drupal which I personally do not like. Overall, the open source nature of the project allows anyone to contribute new modules.
I was building my own app before I found it and am glad it's one less project I have to 20%