It's often a good idea to have multiple things to do in parallel on a project, so that if one avenue is blocked for a short period of time (e.g. waiting for code to run, waiting for a supervisor to return a draft paper with comments) you can put effort into another avenue.

The things you're already doing sound good. You are basically using your time well - spending some of your time enhancing your base knowledge and skills pays off in the long run. You just feel uncomfortable because you don't see immediate tangible payoff for your current project. There are things you can do while your code is running that have a tangible payoff i.e. they directly contribute to things that you will have to do for your project at some point in the near future:

• working on the slides for the next presentation you will have to give (the parts that don't rely on the results of the code that's currently running)
• adding to an ongoing draft of a report, paper, or poster that describes your work (the parts that don't rely on the results of the code that's currently running)
• searching for and reading literature that is directly relevant to your project
• data analysis: when your code finishes running, start the next "run" and analyze the data from the first run while that's going

You can spend most of your time on the thing that is most immediately important (e.g. fixing and running your code) but work on the others in parallel when that is blocked.

For bits of work you can do that generally advances your knowledge and abilities, but not necessarily specifically for your project, see What productive academic work can you do with minimal attention in a small (<30 minutes) block of time?

It's often a good idea to have multiple things to do in parallel on a project, so that if one avenue is blocked for a short period of time (e.g. waiting for code to run, waiting for a supervisor to return a draft paper with comments) you can put effort into another avenue.

The things you're already doing sound good. You are basically using your time well - spending some of your time enhancing your base knowledge and skills pays off in the long run. You just feel uncomfortable because you don't see immediate tangible payoff for your current project. There are things you can do while your code is running that have a tangible payoff i.e. they directly contribute to things that you will have to do for your project at some point in the near future:

• working on the slides for the next presentation you will have to give (the parts that don't rely on the results of the code that's currently running)
• adding to an ongoing draft of a report, paper, or poster that describes your work (the parts that don't rely on the results of the code that's currently running)
• searching for and reading literature that is directly relevant to your project
• data analysis: when your code finishes running, start the next "run" and analyze the data from the first run while that's going

You can spend most of your time on the thing that is most immediately important (e.g. fixing and running your code) but work on the others in parallel when that is blocked.

For bits of work you can do that generally advances your knowledge and abilities, but not necessarily specifically for your project, see What productive academic work can you do with minimal attention in a small (<30 minutes) block of time?

It's often a good idea to have multiple things to do in parallel on a project, so that if one avenue is blocked for a short period of time (e.g. waiting for code to run, waiting for a supervisor to return a draft paper with comments) you can put effort into another avenue.

The things you're already doing sound good. You are basically using your time well - spending some of your time enhancing your base knowledge and skills pays off in the long run. You just feel uncomfortable because you don't see immediate tangible payoff for your current project. There are things you can do while your code is running that have a tangible payoff:

• working on the slides for the next presentation you will have to give (the parts that don't rely on the results of the code that's currently running)
• adding to an ongoing draft of a report or paper that describes your work (the parts that don't rely on the results of the code that's currently running)
• searching for and reading literature that is directly relevant to your project
• data analysis: when your code finishes running, start the next "run" and analyze the data from the first run while that's going

You can spend most of your time on the thing that is most immediately important (e.g. fixing and running your code) but work on the others in parallel when that is blocked.

For bits of work you can do that generally advances your knowledge and abilities, but not necessarily specifically for your project, see What productive academic work can you do with minimal attention in a small (<30 minutes) block of time?

It's often a good idea to have multiple things to do in parallel on a project, so that if one avenue is blocked for a short period of time (e.g. waiting for code to run, waiting for a supervisor to return a draft paper with comments) you can put effort into another avenue.

The things you're already doing sound good. You are basically using your time well - spending some of your time enhancing your base knowledge and skills pays off in the long run. You just feel uncomfortable because you don't see immediate tangible payoff for your current project. There are things you can do while your code is running that have a tangible payoff i.e. they directly contribute to things that you will have to do for your project at some point in the near future:

• working on the slides for the next presentation you will have to give (the parts that don't rely on the results of the code that's currently running)
• adding to an ongoing draft of a report, paper, or poster that describes your work (the parts that don't rely on the results of the code that's currently running)
• searching for and reading literature that is directly relevant to your project
• data analysis: when your code finishes running, start the next "run" and analyze the data from the first run while that's going

You can spend most of your time on the thing that is most immediately important (e.g. fixing and running your code) but work on the others in parallel when that is blocked.

For bits of work you can do that generally advances your knowledge and abilities, but not necessarily specifically for your project, see What productive academic work can you do with minimal attention in a small (<30 minutes) block of time?