Return to Answer

Here are some advices from my experience.

• Explore new ideas with the Mathematica frontend. Don't hesitate to use sections and subsections in the frontend to structure your work and experiment various possibilities.
• When you have instructions that work, package them into functions, still in the frontend.

It's practical to select all the useful instruction cells while holding Ctrl (in Windows), to copy them somewhere in the notebook so that they are following each other and to merge them. Then you just have to add a Module around the code, localize variables and add a function declaration with arguments.

• Then package them into packages. I do it like explained here. You can also do it from a notebook.
• Use Wolfram Workbench. It's really important from my point of view for big projects as having a debugger is very important. Also you can rename variables across multiple packages (files) which is very convenient.

(The only non obvious thing in using Workbench, is when you're at a breakpoint in debug mode and want to abort the evaluation, you need to abort the evaluation in the Mathematica frontend using Ctrl+. for example and continue the evaluation in Workbench.)

• Once you already have a project big enough, you can write some functions directly in Workbench.
• Write unit tests, before or right after writing a new code that works. Workbench handles unit tests.
• Use code versioning, for example Git with the plugin Egit in Eclipse (that you will use if you use Wolfram Workbench).
• Reuse, reuse, reuse. Never write twice the same thing.
• Use the function Echo or this more sophisticated utility to print values from deep inside your code.

Here are some advices from my experience.

• Explore new ideas with the Mathematica frontend. Don't hesitate to use sections and subsections in the frontend to structure your work and experiment various possibilities.

• When you have instructions that work, package them into functions, still in the frontend.

  It's practical to select all the useful instruction cells while holding Ctrl (in Windows), to copy them somewhere in the notebook so that they are following each other and to merge them. Then you just have to add a Module around the code, localize variables and add a function declaration with arguments.

• Then package them into packages. I do it like explained here. You can also do it from a notebook.

• Use Wolfram Workbench. It's really important from my point of view for big projects as having a debugger is very important. Also you can rename variables across multiple packages (files) which is very convenient.

  (The only non obvious thing in using Workbench, is when you're at a breakpoint in debug mode and want to abort the evaluation, you need to abort the evaluation in the Mathematica frontend using Ctrl+. for example and continue the evaluation in Workbench.)

• Once you already have a project big enough, you can write some functions directly in Workbench.

• Write unit tests, before or right after writing a new code that works. Workbench handles unit tests.

• Use code versioning, for example Git with the plugin Egit in Eclipse (that you will use if you use Wolfram Workbench).

• Reuse, reuse, reuse. Never write twice the same thing.

• Use the function Echo or this more sophisticated utility to print values from deep inside your code.

Here are some advices from my experience.

• Explore new ideas with the Mathematica frontend. Don't hesitate to use sections and subsections in the frontend to structure your work and experiment various possibilities.
• When you have instructions that work, package them into functions, still in the frontend.

It's practical to select all the useful instruction cells while holding Ctrl (in Windows), to copy them somewhere in the notebook so that they are following each other and to merge them. Then you just have to add a Module around the code, localize variables and add a function declaration with arguments.

• Then package them into packages. I do it like explained here. You can also do it from a notebook.
• Use Wolfram Workbench. It's really important from my point of view for big projects as having a debugger is very important. Also you can rename variables across multiple packages (files) which is very convenient.

(The only non obvious thing in using Workbench, is when you're at a breakpoint in debug mode and want to abort the evaluation, you need to abort the evaluation in the Mathematica frontend using Ctrl+. for example and continue the evaluation in Workbench.)

• Once you already have a project big enough, you can write some functions directly in Workbench.
• Write unit tests, before or right after writing a new code that works. Workbench handles unit tests.
• Use code versioning, for example Git with the plugin Egit in Eclipse (that you will use if you use Wolfram Workbench).
• Reuse, reuse, reuse. Never write twice the same thing.
• Use the function Echo or this more sophisticated utility to print values from deep inside your code.

Here are some advices from my experience.

• Explore new ideas with the Mathematica frontend. Don't hesitate to use sections and subsections in the frontend to structure your work and experiment various possibilities.
• When you have instructions that work, package them into functions, still in the frontend.

It's practical to select all the useful instruction cells while holding Ctrl (in Windows), to copy them somewhere in the notebook so that they are following each other and to merge them. Then you just have to add a Module around the code, localize variables and add a function declaration with arguments.

• Then package them into packages. I do it like explained here. You can also do it from a notebook.
• Use Wolfram Workbench. It's really important from my point of view for big projects as having a debugger is very important. Also you can rename variables across multiple packages (files) which is very convenient.

(The only non obvious thing in using Workbench, is when you're at a breakpoint in debug mode and want to abort the evaluation, you need to abort the evaluation in the Mathematica frontend using Ctrl+. for example and continue the evaluation in Workbench.)

• Once you already have a project big enough, you can write some functions directly in Workbench.
• Write unit tests, before or right after writing a new code that works. Workbench handles unit tests.
• Use code versioning, for example Git with the plugin Egit in Eclipse (that you will use if you use Wolfram Workbench).
• Reuse, reuse, reuse. Never write twice the same thing.
• Use the function Echo or this more sophisticated utility to print values from deep inside your code.

Here are some advices from my experience.

• Explore new ideas with the Mathematica frontend. Don't hesitate to use sections and subsections in the frontend to structure your work and experiment various possibilities.
• When you have instructions that work, package them into functions, still in the frontend.

It's practical to select all the useful instruction cells while holding Ctrl (in Windows), to copy them somewhere in the notebook so that they are following each other and to merge them. Then you just have to add a Module around the code, localize variables and add a function declaration with arguments.

• Then package them into packages. I do it like explained here. You can also do it from a notebook.
• Use Wolfram Workbench. It's really important from my point of view for big projects as having a debugger is very important. Also you can rename variables across multiple packages (files) which is very convenient.

(The only non obvious thing in using Workbench, is when you're at a breakpoint in debug mode and want to abort the evaluation, you need to abort the evaluation in the Mathematica frontend using Ctrl+. for example and continue the evaluation in Workbench.)

• Once you already have a project big enough, you can write some functions directly in Workbench.
• Write unit tests, before or right after writing a new code that works. Workbench handles unit tests.
• Use code versioning, for example Git with the plugin Egit in Eclipse (that you will use if you use Wolfram Workbench).
• Reuse, reuse, reuse. Never write twice the same thing.
• Use the function Echo or this more sophisticated utility to print values from deep inside your code.

Here are some advices from my experience.

• Explore new ideas with the Mathematica frontend. Don't hesitate to use sections and subsections in the frontend to structure your work and experiment various possibilities.
• When you have instructions that work, package them into functions, still in the frontend.

It's practical to select all the useful instruction cells while holding Ctrl (in Windows), to copy them somewhere in the notebook so that they are following each other and to merge them. Then you just have to add a Module around the code, localize variables and add a function declaration with arguments.

• Then package them into packages. I do it like explained here. You can also do it from a notebook.
• Use Wolfram Workbench. It's really important from my point of view for big projects as having a debugger is very important. Also you can rename variables across multiple packages (files) which is very convenient.

(The only non obvious thing in using Workbench, is when you're at a breakpoint in debug mode and want to abort the evaluation, you need to abort the evaluation in the Mathematica frontend using Ctrl+. for example and continue the evaluation in Workbench.)

• Once you already have a project big enough, you can write some functions directly in Workbench.
• Write unit tests, before or right after writing a new code that works. Workbench handles unit tests.
• Use code versioning, for example Git with the plugin Egit in Eclipse (that you will use if you use Wolfram Workbench).
• Reuse, reuse, reuse. Never write twice the same thing.
• Use the function Echo or this more sophisticated utility to print values from deep inside your code.