Those who have not previously worked with the Github workflow will find these tips useful:

The most basic methods:

1. Fork the github.com/user1/projectAbc repository, and you get your github.com/you/projectAbc

2. Clone the forked repository on your computer:

git clone https://github.com/you/projectAbc.git

3. Create a reference to the “parent” repository, for example as an “upstream”

git remote add upstream https://github.com/user1/projectAbc.git

then merge changes from the “parent” to yourself git pull upstream master

4. Create a new branch: git checkout -b feature

5. You’ll work and make commits, if you need to track changes in the “parent”, merge the changes from it and pour into your branch in this way:

git checkout master
git pull upstream master
git checkout feature
git merge master

6. When the work is done, push the changes in your github-repository in your branch: git push origin feature

7. Now go to the github, in your repository and click on the top button “Pull request”

8. On the left, select which branch the changes will be added to the parent repository, to the right — what changes will be taken from your repository. Following the example: on the right is the user1/projectAbc/master, on the left is the you/projectAbc/feature.
IMPORTANT: Agree with the owner of the “parent” repository, in which branch you will be adding changes (he can write this in README).

9. Fill in the name and description (the name will then fall into the description of the commissions and become public, take this into account).

10. Click Send Pull Request

Voila, you sent it. The owner will review your changes and, perhaps, take them and pour into him.

Do not forget to then make git pull upstream master to see the changes in yourself.

I hope this mini-guide will help you make the world a little better.

Learn basics

I often see guys who watch some video lessons and start to do something right away. Of these, many don’t listen to what they see because of ignorance of the language (I live in Tashkent) or lack of patience. And they learn very quickly, and they get to do the work well until they have to do something complicated. That guy in difficult tasks can not solve problem, he/she doesn’t get any ideas how to solve the problem and begins to look for ready solutions and use them. In the end everything will be in shit.

The problem is that beginners learn always ready-made things. I’ve been this often, sometimes still, it’s okay. It ceases to be after when you start to learn the basics of the language or technology. Write the code on paper and debug them.

The importance of reading code

It is essential.

And I can say the motor of self-improvement is code reading.

The best documentation is code. Many times when I did not understand the documentation I always read the code. In the code I always found things that are not written in the documentation. When I read the code of library for example, I understand how this library works and it will be easier for me to think like library when I use it. I make fewer mistakes. I begin to understand and where to use the programming patterns.

Reading the code directly in proportion to writing good code.

Even if you don’t intend anybody else to read your code, there’s still a very good chance that somebody will have to stare at your code and figure out what it does (that person is probably going to be you).

Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write. — Robert C. Martin

Always research

I copy-pasted it from here.

“You can get a lot of mileage by doing research and casting a wide net. In particular, I personally find the following Google queries to be pretty useful at giving me an overview of the best practices and general “feel” of a language:

• “X best practices”
• “X style guide”
• “X idioms”
• “X common mistakes”
• “X philosophy”
• “X ecosystem overview” (or “X popular 3rd party libraries”)
• “X tips and tricks”
• “X history”
• “X advanced features”
• “X linter”
• “X style checking tools”

(Replace “X” with the name of the language. If the language name is common word like “Go” or “Swift”, try replacing “X” with something like “Go language”.)

This will obviously return a wide range of results, not all of which will be useful, but it’s a good way of getting the “lay of the land”. Some of the results will be directly useful (for example, you might uncover a popular and comprehensive style guide or a useful linter), and others will be more useful for getting context behind the design and intended use of a language (for example, googling about the language’s core philosophy).

Other things I personally find helpful is to browse through the top-voted questions about a particular language on StackOverflow or SoftwareEngineering.SE (previously Programmers.SE). The knowledge won’t be immediately useful (or sometimes comprehensible), but it does give you a feel for what sorts of issues programmers using that language tend to worry about, what advanced features people want to learn to use, and what keywords might be helpful when refining your queries.

Something else you can do is to keep an eye on news aggregates for the language of your choice. For example, I like browsing through http://reddit.com/r/python for Python-related news — every now and then, you run across an article that teaches you something new or reveals a point of contention within the community that’s worth keeping an eye on.

Keep in mind that after reading through all of these resources, you’ll likely find it hard apply them all at first — in some cases, you might not even understand the articles you dig up. This is fine: the idea is to be aware of them in the first place so you have a direction to grow towards.

It’ll probably be a good idea to start small — start by finding a style guide and writing your code to be compliant with it, for example. Or maybe try figuring out the recommended best practices for organizing a larger project and using your language’s package manager” — michael0x2a

Finally, love what you do

The main thing: you should love what you do because being a good programmer goes a long way.