Things I Wish I'd Known Earlier

I agree with Andrew 100% regarding multiple monitors. Besides allowing one to focus on the task at hand, a few seconds saved for an activity carried out 100s or 1000s of times can quickly add up to significant savings.

Way back when, I used to add a mono card to my DOS and Windows 3 systems and had a simple C API that allowed me to display 24 debug lines and status counters. It often highlighted timing issues because it was a real time memory operation.

For the last 15 years I have used 3 screens connected to 3 or more CPUs via daisy chained KVMs. Each CPU/screen has its own mouse and the single keyboard can be connected to a particular CPU/screen via a keyboard command. A typical debug session will show the source code (screen 1), the results (screen 2) and the debug log (screen 3). While coding, the extra screens are used to display reference or code samples. The isolation of the tasks on each CPU makes for a more stable development environment.

To round out the toolset I adapted a java based clipboard utility to allow me to copy from one screen and paste onto the other screens.

I know these extra screens have improved my efficiency, code quality and job satisfaction.

This is a little ironic - I first wrote for SW Development Magazine on a Design Decisions diary in 1996 (http://www.drdobbs.com/solo... and did a brief 10-year retrospective (http://www.drdobbs.com/tool....

Yes I am still a major fan of the technique and particularly using plain text or a simple markup so the documents diff nicely when kept alongside the source in the version control system.

Learn core software design concepts; how and why they are used -- this knowledge is applicable to every language (syntax) so you will learn it once and then be able to build software from well-defined principles no matter what the language. I didn't use the word patterns, because I didn't want all your preconceived ideas to kick in or your eyes to glaze over. :) When your foundation is strong then you can build anything on top of it. You'll be faster in the long run.

One thing I have more insight into lately is program verification. It arises out of structured programming (in the original sense, not the later snake-oil sense). With one way in and one way out (no jumps, gotos, returns), code can be annotated with checkpoints in the form of preconditions and postconditions.

In Hoare Logic this is expressed {P}S{Q}, which says if precondition P holds, after the code block S is executed, postcondition Q holds.

TDD actually uses this by artificially setting P to test S and check it with Q.

But we can do better with Design by Contract, which tests for valid P in a running system. And in a language like Eiffel, this is built into the language and gives a very precise form of documentation.

Although I have known about this for a long time, I have found some extra insights and understanding by reading Dahl, Dijkstra, and Hoare "Structured Programming" and David Harel's "Algorithmics". Some things I wish I'd known a long time ago!

Something I've found very useful is to reference the bug number I'm working on in commits messages, and use a post-commit hook to update that bug with the revision #, commit message, and changed files.

Those are all fantastic suggestions. I'd love to hear more of yours, as well as those from readers. As for my own to add here: always use a source code management system, even for small or personal projects. Keeping even short notes with each check-in creates a valuable log of changes over time, and being able to easily perform code diffs across checkins helps to isolate where a bug or change in behavior originated. And since modern IDEs offer plugins for most popular SCMs, it plays into your advice to know your tools well. Thanks!