The tools of the trade are usually invented to solve a need. If you have the need you use the tool, if not, you most likely don't have to.

Specifically, scientific programs are not the end target, they are the means. You write the program to solve a problem you have now - you don't expect that program to be used by others (and having to be maintained) in ten years. That alone mean that you don't have to think into any of the tools that allow the current developer to record history for others like version control, or capture functionality in code like unit tests.

What would benefit you then?

• version control is nice because it allows you to very easily backup your work. As of 2018 github is a very popular place to do so (and you can always move it later if needed - git is very flexible). A cheap and simple substitute for backups are the automatic backup procedures in your operating system (Time Machine for Mac, rsync for Linux etc). Your code needs to be in multiple places!
• Unit tests are nice because if you write them first you are forced to think about how to check what the code actually does, which helps you design a more useful API for your code. This is helpful if you ever get into writing code to be reused later.
• Documentation. Learn to write proper documentation in the programming language you use (javadoc for Java for instance). Write for the future you. In this process you will find that good variable names makes documenting easier. Iterate. Give the same amount of care to your documentation as a poet does to poems.
• Use good tools. Find an IDE that helps you and learn it well. Refactoring like renaming variables to a better name is much easier this way.
• If you have peers consider using peer review. Having an outsider look at and understand your code, is the here-and-now version of the future you you write for. If your peer does not understand your code, you probably won't either later.

The tools of the trade are usually invented to solve a need. If you have the need you use the tool, if not, you most likely don't have to.

Specifically, scientific programs are not the end target, they are the means. You write the program to solve a problem you have now - you don't expect that program to be used by others (and having to be maintained) in ten years. That alone mean that you don't have to think into any of the tools that allow the current developer to record history for others like version control, or capture functionality in code like unit tests.

What would benefit you then?

• version control is nice because it allows you to very easily backup your work. As of 2018 github is a very popular place to do so (and you can always move it later if needed - git is very flexible). A cheap and simple substitute for backups are the automatic backup procedures in your operating system (Time Machine for Mac, rsync for Linux etc). Your code needs to be in multiple places!
• Unit tests are nice because if you write them first you are forced to think about how to check what the code actually does, which helps you design a more useful API for your code. This is helpful if you ever get into writing code to be reused later and helps you while changing an algorithm because you know it works on these cases.
• Documentation. Learn to write proper documentation in the programming language you use (javadoc for Java for instance). Write for the future you. In this process you will find that good variable names makes documenting easier. Iterate. Give the same amount of care to your documentation as a poet does to poems.
• Use good tools. Find an IDE that helps you and learn it well. Refactoring like renaming variables to a better name is much easier this way.
• If you have peers consider using peer review. Having an outsider look at and understand your code, is the here-and-now version of the future you you write for. If your peer does not understand your code, you probably won't either later.