Scientific debugging your project

During a project meeting, you should report what you have done and the results that you achieve since the last meeting. Don't just show the boring numbers such as accuracy. You must interpret and analyze the results:

• It's great when you have positive results and your idea works. But, even in this case, you should temporarily set the excitment aside, doubt it, and try to find another way to validate your results. How can you convince me that there was no silly mistakes, e.g., not having independent train and test data? For example, can you validate your quantitative results with qualitiative results?

• If you get negative results, i.e., you implemented an idea but it performed worse than the method you hoped to beat. In this case, can you analyze why? Before you implemented an idea, you must have a strong reason for why it would outperform the competing method, and that reason should be based on some assumption. Can you see now why your assumption was wrong?

In my experience, you will get negative results 80% of the time. Don't be ashamed to report that “I made no progress this week”, as long as it was not due to the lack of effort to do the work and analyze why it fails.