I’ve spent a fair portion of my career teaching and mentoring other programmers. Some of this training involves covering basic programming and design concepts that they may not have learned previously. When covering a fundamental concept, I often defer to books written by people much smarter than I am rather than explain the concept myself.… Read More »
In LinuxDevCenter.com: Tales of Optimization and Troubleshooting [Jun. 03, 2004], Howard Feldman presents three examples of troubleshooting and fixing bottlenecks. One thing I really like about this article is the methodical way the author goes about solving these problems. Having tried to teach troubleshooting to entry-level programmers, I know that it is very hard to… Read More »
I saw the article Refactoring reminiscent of high school algebra on Artima yesterday and it made me remember a new connection of my own. In the article, David Goodger is working on a refactoring problem that is turning out to be worse than expected. After a little reflection, he manages to solve the problem. But… Read More »
I’ve already written some of my ideas about paradigms, but the most important point still remains. I maintain that the real benefit of a paradigm is not the way of thinking that it defines, but the contrast between this way of thinking and others. Almost every programmer I’ve ever met that only knows one paradigm… Read More »
And just to prove that some ideas appear in many places all at once, Andy Lester explores naming again in O’Reilly Network: The world’s two worst variable names [Mar. 07, 2004]. Apparently, Lester is reviewing the second edition of Code Complete, one of my favorite books on programming, and says there is an entire chapter… Read More »
Software Craftsmanship Pete McBreen Addison-Wesley, 2002 This book is clearly written by someone who gets programming. I’m not sure how well the current business climate would accept his idea of Software Craftsmen, but I’m certain programmers (good and bad) will see an idea they like. The main premise of the book is that programming is… Read More »
Here are a few basic rules of troubleshooting and debugging. Divide and conquer (always) 50/50 tests are best Verify can’t happen cases with a test Steady progress is better than random guessing If you guess and fail, go back to #1. Don’t try to keep guessing. I’ve been trying to formulate a good set of… Read More »