21–30 of 40 posts
Don't use a debugger - think when something doesn't work. The feedback you get by thinking about your own code teaches you much faster than anything you get with compile/run/debug cycle. "I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. " http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.h...
Coding is debugging just like writing is revising.
With that in mind, perhaps also think about the way you are structuring your development. Do you have a mental (or physical) sketch of the code before you write it? There's something to be said for having a bit of paper to scribble on before and during the coding process. Map out little examples (e.g. "test cases") and think about how you will deal with all of them.
Finally, writing stubs (i.e. functions or modules that are basically empty) when you first start can be great. If you know you're going to need some pieces of functionality in order to solve your problem, then write stubs for those and then solve the problem (i.e. write the main program flow). Hopefully then when you come to write the supporting functions that do most of the heavy lifting, you will have clarified your intuitions around how they are supposed to work.
So my advice would be to be a little more rigorous in your approach _before_ you get to the point of having screenfuls of code in front of you.
...the number of sloppy mistakes I make is still way too high... Compared to what? You may not have a problem. Sometimes "code, mistake, fix, code, mistake, fix, code, mistake, fix,..." is faster than "code it perfectly once". For me it usually is. I'd rather crank stuff out quickly and fix it than drive myself nuts thinking it through. Stupid syntax and typing errors will go away with repetition. Otherwise I wouldn'…
Why would syntax highlighting, etc. be "training wheels"? I understand that training wheels restrain what you can do with your bike, but what's the downside to coding in an IDE?
This may be a little old fashioned of me, but any time I try to solve a problem that isn't immediately obvious, I write it down on paper first (or whiteboard it).
If you can't hold the solution in your head and visualize it, then you should try to break the problem down into smaller chunks so that you can at least fully visualize all of the moving parts.
Around my office, I have a set of maxims that I always emphasize in order to keep our quality high - #2 on the list is to always measure twice before cutting (or writing, in this case); rule #1 is to pick the low hanging fruit first. There's no point in starting to code a solution until you know with a level of certainty what it is you're trying to achieve. Lots of people with debugger syndrome don't know where they're going until they happen upon a solution by coincidence instead of by intention.
Using a statically typed language might also help, as the compiler can catch a lot of really stupid errors.
use a language a programming style that lets you catch errors early. it's amazing how much time i've wasted testing for errors after small changes in ruby programs. errors that a decent language & compiler wouldn't have allowed or detected much earlier. some languages just weren't designed with this in mind. i no longer program in ruby.
related: once upon a time, i had the idea that i should be able to write a program and have it compiler & work at the first & final attempt. code was in c. of course that failed miserably. especially with the lack of c coding experience. the lesson: don't try to be silly/"smart", use the tools to your advantage. (if your tools don't have advantages, don't use them).
tests tests tests I use a little tool that runs unit tests on compilation, when Im doing something new that unit tests works well with, I write a bunch of tests and just code until I have 100% tests passing.
If you make a lot of mistakes, have sanity tests cover your ass.
1) ASSERT. Catch the mistakes while they're still dumb.
2) Take advantage of your type checker to catch mistakes.