The first skill a new programmer must learn is not what most people expect. It is not learning a programming language. It has nothing to do with algorithms or data structures. The first thing a new programmer must learn is how to identify a small piece of a problem. Solving the Big Problems Most problems… Read More »
Between my earlier career in electronics and my current career in software, I have found a number of questions that have been helpful in troubleshooting problems reported by others. None of these questions are original to me. My wife described troubleshooting a hardware problem over the phone and mentions some of her troubleshooting questions. I… Read More »
In the last post (Coding Style: Terse vs Verbose), I laid out some of the arguments for and against a verbose coding style and a terse coding style. Although, I didn’t delve deeply into what I meant by these styles, I hoped the details were less important than the general feel. However, by the end… Read More »
One coding style issues that causes many arguments is the distinction between the Terse/Elegant/Succinct style and the Verbose/Legible/Debuggable style. As usual, each side explains that their style is the only rational choice and that the other approach is obviously wrong. First, let’s look at the two styles to see what they say. In order to… Read More »
One problem with comparing different programming languages is finding a valid comparison. It’s pretty hard to really compare two different languages. On the other hand, it’s pretty easy to compare example code from the two languages. Unfortunately, comparing code examples is likely to run into Sturgeon’s Revelation, or Sturgeon’s Law: 90% of everything is crap.… Read More »
My wife is a really good writer and she once gave me a great piece of advice for some documentation I was working on: Know Your Audience. This has helped me to write better documentation. Over the years, I have come to realize that the same advice applies when writing code. Who is the Audience… Read More »
In my last post (Thoughts on Code Comments), I described two opposing camps that argue about code comments. Like much of the craft of programming, the commenting of code is too complicated for a simple set of rules. In this post, I will describe a set of guidelines that I’ve adopted over the years. These… Read More »
In the comments on a recent Google+ post, a discussion erupted about comments in source code. As usual, there were two groups that argued relatively vehemently. The More Comments camp was best represented by the suggestion that a good program should have as many lines of comments as lines of code. The Clear Code Needs… Read More »
I’ve recently been reminded of something I used to tell entry level programmers repeatedly: Review the basics. And really I mean all of the basics: data structures basic algorithms basics of algorithm analysis language syntax core CS concepts testing strategies In many programming positions, you can get away with coasting on these things for a… Read More »
The practice of developing software depends on a large body of arcane knowledge and skills. Almost all of this knowledge is based on logical principles and built up to the point that we can do amazing work. Because programming has it’s roots in applied mathematics, there is an impression that programming is also a logical,… Read More »