How do I Know When I Will be Ready to Work on a Shared Project & When Will I be Ready for Hire?

Question

The thought of working on a shared project with others sounds like a fun idea, and I would love to do that for the practice, but at the same time I also feel a little scared. How do I know if I have sufficient knowledge and skills for the project? And when will I be ready for hire?

Answer 1

The best way is to try and go to interviews. If you don't lie you will get a fair assessment of where you stand!

Answer 2

I am just a hobbyist so I've never had a job, but I have worked on small open-source projects. The most important part seems to be that you feel like you understand the project (or at least the part you're working on and how it is used by the rest of the project) and can fix/update/upgrade something.

It's also good to be able to explain why you've made the changes. If it's just something small that should be obvious, such as fixing a bug by using === instead of == in JavaScript on one line, that could be included in the commit message, but if it's important and someone may get confused in the future and change it back you can leave a code comment explaining the bug and why what you changed fixes it to help prevent this from happening.

Code that is more complex can have comments to help explain it, with a somewhat-optional-but-nice-to-have summary in the commit message, but it's not required. There are plenty of projects out there with little-to-no comments which once you've read through some/most of the code, are understandable (at least mostly, if not completely). Many chunks of code that implement mathematical algorithms, for example, do not include comments as they expect you'll be able to figure out how the code is using the algorithm (which we should be able to do for projects we work on).

For projects which provide an API the code comment for documentation, which should have a description of the property/method/etc, can be used to summarize what it does and then if there are any exceedingly complex parts within it non-documentation comments (that will not be included in the API docs) can be used to help explain it to other developers (and yourself, once you forget it).

I'm not saying this is what I do -- I suck at commenting code, or writing documentation comments. This is just what I've seen in good projects. Lol.

Answer 3

Thank you for your answer, ifl. I appreciate it!