Testing code as you go along is not experimentation. It saves time by allowing you to verify your assumptions are correct in a controlled way.
You can sit there and plan all you want until you think you understand it, but you never actually know until you run the code. Being a good programmer is all about simplifying complexity. Testing your code as you go along to verify your assumptions is one more way to do this.
It doesn't matter how you call it. If you know the code works then there is no benefit of running it. If you need to execute it it is only because you don't know if it works correctly.
Sometimes this is fine. I do this when I execute external services because I may not be sure how they work exactly and I want to correct mistakes before I do too much design resulting from my flawed knowledge.
But when it comes to your code you should be able to tell if it works correctly. If you can't there is couple of ways to deal with the problem that I adopted over the years:
-- techniques that make it easier to ensure code works correctly are frequently also improving it in other ways. For example, making code simpler is important not just for reliability.
-- specifying your internal module boundaries and APIs is critical for anything non trivial. Abstracting parts of the problem is enabling you to solve each part of the problem separately. You can't keep 10k lines of code in your mind and tell if it works correctly, but maybe you can split it into multiple modules and make sure each works correctly, separately.
-- when I have written a module that I am just not sure works correctly, I refactor it so that it is easier to tell if it does what it should be doing.
-- make it a habit to write code that is what I call "obviously correct". One way to do it is to make sure it can never get into wrong state.
> If you know the code works then there is no benefit of running it. If you need to execute it it is only because you don't know if it works correctly
People make mistakes. You have to run the code. Do you submit PR's without running code? If not, then we're agreeing. Making code simple enough to reason about without executing is a great goal, but you cannot replace running code.
> You can't keep 10k lines of code in your mind and tell if it works correctly, but maybe you can split it into multiple modules and make sure each works correctly, separately.
But ultimately they need to work together, and that's the most important part. Again, you need to run the code here.
> when I have written a module that I am just not sure works correctly, I refactor it so that it is easier to tell if it does what it should be doing.
This is a good goal, though again, I hope you run the code. You don't know what you don't know.
You can sit there and plan all you want until you think you understand it, but you never actually know until you run the code. Being a good programmer is all about simplifying complexity. Testing your code as you go along to verify your assumptions is one more way to do this.