John Robbins has some good advice on debugging with .NET. Pick up one of his books or see what is otherwise available. I haven't checked this particular presentation, but channel 9 has this presentation.[^] My professor (who became a Touring award winner...) had a very specific principle for proving code: Define INVARIANTS in your code. That means you have known expectations of variables (and state) at specific points. Test for those. .NET provides Debug.Assert which allows you to test for those invariants and doesn't require you to remove them for production (just use build configuration). Add to that by considering test first (test driven development), or at least keep testing in mind when you code. Many other great insights posted here - I can vouch for pretty much all of them after almost 40 years in the business. When it comes to extended sessions - that boils down to how much you can mentally keep track of and how TIRED you are. Some times, nothing beats being "in the zone" for an extended period, but only when you are actually making noticeable progress or following multiple leads. But when you start to spin your wheels, you are probably better off taking a break. I like to do Sudoku puzzles, and the ones I have trouble with at night before bed are usually quickly solved the next morning. Same thing with programming challenges. * Learn and practice using patterns. * Describe problems out loud or in writing. That forces you to think them through. * Learn by teaching others. That challenges you to know. * Don't rely on what you know - things change. I have had to unlearn more things that I have had to learn. Look it up. * Get comfortable with a good search engine (I like DuckDuckGo.com). Realize that not all answers on line are good answers. * Have fun coding, and don't forget to have a life away from a keyboard and screen.

Don't try one if your CMOS battery may be flaking out.

ND was a great place to work!

I read about a ground fault circuit trap tripped an old computer way back - but only after hours. The guy who tried to find it could watch it run for hours, and every time he came back after taking the elevator to get a cup of coffee, the computer would be down... My favorite fix came around February 2000 - a customer using an imaging system (third party software we provided running on SQL Server 6.5) was suddenly experiencing major performance issues and consistently timing out against the database. We couldn't change the app or the query it issued. The database seemed to be working fine, except for the one query, which had been working great until it suddenly started timing out. No amount of basic database repair or index tweaking seemed to help. We finally decided that the selectivity of one of the main indexes for the application caused the wrong plan to be chosen. Solution: Insert 40 thousand dummy records with the only purpose to change the selectivity of the index. Worked like a charm. I should mention that a subsequent service pack update to SQL Server allowed us to remove the dummy records.

After having failed at revovering a failed RAID 5 array (single disk failure initially) a few years ago, I would not recommend RAID 5 for anything other than corporate use (with an IT/support department). If one of the drives fail, you must replace it with an IDENTICAL drive (identical addressing and size). We had what was supposed tio be an identical hot spare, but it turned out to have a bad sector (hidden by formatting), which made the drive just a tad smaller. As a result, we couldn't rebuild the array. Since we were using high-end drives, we were able to order a replacement with the same model and revision (expensive). For a home system with less expensive OTS HD, replacement of a failed drive may not be straight forward. Unless your controller specifically allows variation between drives, this may be your deciding factor.