1. Use a literate programming approach, such as with R-markdown or Jupyter/ipython.
2. Version control everything. That annotation you got from Ensembl? Yeah, you better write down which release, because the next one might produce different results.
3. Remember backups? Yeah, make sure you have those.
4. Clean up after yourself. Don't be the guy/gal that occupies an excessive amount of space on the "very-expensive-overly-priced-poorly-performing-storage-array" (TM).

BTW, I would skip your number 2. You need to save primary unprocessed files (e.g., compressed fastq files or BAM/CRAM files after using bamHash or similar) and anything that takes an absurd amount of time to reproduce. You also need to save anotations and anything else that will likely be different if you download it again. However, don't save the results of every step, that's just going to blow up your storage costs and make it impossible to find anything. This happens to be identical to the common practice on the wet-lab side, where freezer/-80 space is always shared and HIGHLY limited.

In addition to Devon's answers above:

1. Sanity check. If you filter a dataset, check that this actually happened! Especially with projects that are linked with scripting, it is easy for unnoticed errors and omissions to occur.
2. Don't reinvent the wheel. Chances are whatever you want to do has been done before. Biostars, stackoverflow, and seqanswers are all great places to search first.
3. Take a step back and look at the big picture. What hypotheses are we trying to (dis)prove? What conclusions can we draw from the data, and what potential impact could they have?
4. In line with #3, it's really important to keep on the scientific and technical literature. Bleeding edge approaches are great, and having a feel for where to apply them is great as well.

Things not to do:

1. Make Quality Control plots but never really look at them.

2. Make Quality Control plots and look at them for too long.

1. Plan and manage the projects as modules: for example data clean up/QC, database management, analytics, predictive modeling, machine learning, statistical inference, data visualization and biological/clinical inference. This would help in the long-run for plug-and-play and easily build, test and deploy analytic pipelines.
2. Assess the task: think before one spend countless hours on coding that slick function. Someone may have already made an open bio-* package for the bioinformatics task.
3. Backup: Document, version control and backup everything (including the Linux/Unix command line using history). Bioinformatics is an applied practice and often contribute to scientific inference and clinical impact - here reproducibility is incredibly important. Tracking data provenance could help with reproducibility.
4. Collaborate: co-create, and code-review
5. Design thinking: Spend time to solve the task creatively, you have the choice to convert the bioinformatics task to a simple script or a package that many others could use.
6. Engineer, don't just code. Understanding the technical details and know how to scale the systems from one data set to a 100 or 1000 data sets is key
7. Future-proof the infrastructure - codes can crack, pipelines could break, good to have a mechanism to maintain and support the bioinformatics infrastructure
8. Give back to the community - share code, analytics or blog. This would give more visibility and help to take the tool/paper to a large user base.
9. Happy bioinformatics: Enjoy.

Do as much of your work in the public eye as possible. Github and the like have changed the way that I think and work.

mine:

Talk less, code more!

1. when you are coding, add comments so that when you go back to it 3 months from now you remember/understand what/why you did it
2. I use Google Slides to summarize my analysis, add thoughts and plots so that it's well organized and I can access them quickly, comment, go back to bed :)
3. when using R, save the workspace so that you don't have to re-run the whole code when you need to go back
4. when possible use more than one approach to analyze the data, if the result is consistent, great, if not, workout why
5. can I mention again backups on server(s)?

If using data from other sources, keep track of where it came from. This can be as easy as a shell script with a bunch of wget or curl lines, but such a small thing can make a big difference in a few months when you forget where you got those files.

Here are some of my tips:
1, sharing: make your code to be libraries, share them in github
2, visualization: always visualize your data
3, noise: keep in mind, data is always with noise, do filtering and cleaning before using them
4, git: use git to trace all your codes, manuscripts and slides
5, toolchain: maintain the tools you usually use to be a toolchain
6, testing: always test your pipelines/algorithms/tools with benchmark data

Keep a command line history log for every program you installed/compiled, including version numbers of its dependencies. This will be really helpful not only for reproducibility, but also in case of moving up to new servers.

Make your projects reproducible.

Slightly unusual but tar ball and archive all your work directories after you are done with a large project to save money on storage. Tape archives, especially the ones maintained by large genome centers are quite cheap and can be retrieved in a day or two. On the other hand you get billed heavily for data storage on file systems.

Like Ryan said ^ ^ ... If using data from other sources, keep track of where it came from. I would suggest using something like Repositive

On Repositive you can favourite datasets you are either interested in or have downloaded data from. Each dataset includes a description and any comments from other users, but also references and links direct to the source. I also hear they plan to allow users to create their own collections soon to make it even better.

I should also point out that Repositive is free and at present you can use it to browse over 35 human genomic data sources / browse over 1,087,000 datasets.