I’m not certain this is really a bad habit/method. Especially if you know where the error is happening (Exception Stack), but not the when (Which values cause it to mess up). You can use the print statements in an attempt to discover some of the values that are coming in before the crash/error happened and use them to insert an if (variable == THIS ONE I FOUND THAT HAPPENS JUST BEFORE THE CRASH) and then put your little debug point there.
And by then, you’ll normally have a better idea of just what’s going wrong in the first place just by reading variables and stuff that you might be able to solve it without going through the debugger. Otherwise, you sit there and have to sit there and go through the execution calls one by one and probably sit through enough that your finger hits next by habit and it crashes without you getting enough data. >.>
Another problem I have. Changing ideas mid project. In fact, I almost failed to finish a class project (One where I decided to go way over board and write a full LibGDX program for a relatively simple game that was meant to be done using Java Swing and the like) because after turning in a basic design idea document I thought “You know what, now that I’ve gotten this mostly coded, I’ve found that it doesn’t make for a fun game. But if I change this and this other thing…” Which is why I almost never finish a game.