I can only speak for myself here, but why would step 1 be "become a user"? I ask because I don't fully grok why I would want to contribute to a project I don't use (either in my personal time, or work time)?
It’s worthwhile to be explicit there. For example, a person can be a heavy user of Pandas library but rarely use underlying numpy library directly. There could be motivation to contribute to numpy with expectation that Pandas will benefit too.
Based on the article, this user should start learning to use numpy directly, and I can agree with that.
why I would want to contribute to a project I don't use
Sometimes I might have an academic or research interest in a field I'm not actually working in or I read about a topic that sounds interesting. Then contributing to a project working with that topic or field might seem like a good way to learn and get more into that topic.
> I start with a feature or use case, and start from the outside in to trace the codepath that the feature follows. During this process, I take notes about the files, lines, and functions I’m going through, but I do not yet attempt to understand how anything works. This is the “trace down” phase.
In my opinion this is what makes it easy to discover how programs written in Go, Rust and C work, while it typically is not easy to discover how programs written in Java or C# [1] work typically - abstracted wireup via IOC containers often makes it difficult to to determine which code is likely to run.
One thing you can do is go to the code you care about and modify it to dump a stack trace, so you can see how it ended up being wired up instead of how you might have assumed it would be.
8 comments
[ 2.9 ms ] story [ 27.3 ms ] threadBased on the article, this user should start learning to use numpy directly, and I can agree with that.
Sometimes I might have an academic or research interest in a field I'm not actually working in or I read about a topic that sounds interesting. Then contributing to a project working with that topic or field might seem like a good way to learn and get more into that topic.
> I start with a feature or use case, and start from the outside in to trace the codepath that the feature follows. During this process, I take notes about the files, lines, and functions I’m going through, but I do not yet attempt to understand how anything works. This is the “trace down” phase.
In my opinion this is what makes it easy to discover how programs written in Go, Rust and C work, while it typically is not easy to discover how programs written in Java or C# [1] work typically - abstracted wireup via IOC containers often makes it difficult to to determine which code is likely to run.
[1]: Yes, yes, not all Java etc etc...