Concurrency is going to be part of most developers’ lives in the future. C++ and languages like it are poorly suited for concurrency as it is today. Semaphores are common and well-known, but using them correctly is difficult. If you want to prepare for concurrency, you could start the transition by becoming familiar with immutability, persistent data structures and active objects.
I have written an article on the subject. It’s hosted at Gamasutra (free login required) here.

Simon Baker has a nice entry defending pair programming. If you are among the many who find agile methodologies appealing, except for this one quite controversial quirk, you should read it.
I agree with most of his conclusions. Pair programming is not for everyone, but rather than being a matter of introversion versus extroversion, it depends on people being willing to let go of their ego and their need to hide mistakes until they have been fixed. Exposing the way you work is something that some simply refuse. Perhaps they were brought up with lots of praise..

Programmers prefer monospace fonts, right? I know I did. I didn’t really consider using anything but - even though I had noticed that Bjarne found a proportional-width font was better for his book. Bjarne has had lots of great ideas, I thought, but also a number of peculiar ones and I figured this was one of those.
A few months ago I tried switching to Verdana in Visual Studio. And I must say that I am pleased so far. I haven’t yet missed monospacing and come to think of it, I don’t really have any good reasons for wanting it. Formatting, you say? Well indenting works just the same whether your font is monospace or not. The only formatting problem that could arise is with alignment of things like fancy comment “frames” which I don’t really use anyway (if you make lots of those, notice that you are probably putting too much code into one file - which makes you want to add distinguishable “headlines” that are easy to spot when scrolling through the file. You should probably split your code into more files or get a folding editor.)
Verdana is much more narrow that most monospace fonts, which means that the need for horizontal scrolling is less. This comes in handy especially in the build output where error messages can often grow long. And, I find that it is generally more pleasing to the eye.

A number of the programs that I have running on my pc have a problem with stand by. When I open the lid of my laptop, I often get a greeting expcetion in a message box.
By keeping memory alive and asking all device drivers to resume state, your operating system is trying to create an abstraction that allows your app to work regardless. While this works for most apps, the abstraction is not complete and there are a number of quirks you should prepare your code for:

• Networks may change. The IP of this machine may not be the same as when the program was started.
• In fact, the entire hardware configuration may have changed. Most obvious example is the docking station that adds memory or pci slots.
• Time is non-linear. From your app’s point of view, stand by is the equivalent of time travelling. Four hours may have passed since the last tick because of stand by.

Everybody agrees on hating hardcoding. In fact, to many it is probably among the worst of programming sins.
But is hardcoding really all bad? I don’t think so. It has some good properties:

Development Time
It is fast. Just writing code takes less time than thinking out abstractions and then writing the code.

Performance
Hardcoded means fast. At least, it can. Essentially, it’s inlining functionality that would otherwise have to be executed through a number of abstractions. Calling a function takes clock cycles.

Simplicity
Fewer abstractions to understand and memorize can make your system simpler to work with.

Readability
Hardcoding makes your code easy to read. If you’re like most programmers, you will turn away with a snort of disgust when you spot some code that is definitely hardcoded. Nevertheless, chances are that you can easily tell what the code does. This is something that can be much harder with properly refactored code.

Debugging concurrent code is hard. The current debugging paradigms are not very well suited for multiple threads or processes manipulating the same data.
But of course, we shouldn’t be debugging in the first place - we should be writing tests, which we all know reduce the need for debugging tremendously. But the same goes for testing. Testing concurrent code is also hard, and the usual unit tests tend to lose some of their worth since they, too, might fail only one in a thousand times if there is a problem.

Our game code at Flux Studios features lots of threads and when playing multiplayer, it also runs on lots of computers. Keeping state in synch across these boundaries is not trivial. Which is why we developed a small tool that helps us a little in the process.

StateAid is a utility that allows you to inspect states in your code in a non-linear fashion. It does so by parsing a log file which is then visualized, allowing you to inspect the state at a certain point in time. It is currently in a very early stage so it doesn’t do very much but at times it can really come in handy.

If you know Python, you are familiar with its superior string literal syntax. Basically, you can write complex strings inside your code with little effort.
Most languages don’t have features quite like this. While C# has the verbatim (@) literals which make things a little easier, they still can’t be multiline and they can’t contain quotation marks. Basically, you cannot just paste in some string and expect it to be correct. If you need string data, it is usually easier to load it in from a file. However, there is a third option, as Lars Thorup describes in this article. The idea is to write comments and then parse the actual code file afterwards. Sounds strange? Well, it can be quite useful, especially for unit testing.

On a related note, the website for Mutual Satellites, the project that I worked on while I was with BestBrains, is up. This project is very exciting and I am looking very much forward to seeing it released.

Edit: As Thomas Eyde pointed out to me, verbatim literals can in fact be multiline.

The text Diagnosing SVN by Tom Lord describes a series of problems with the development of Subversion. There are a number of interesting insights on programming in general in that article. (Rebuttal here).
For the record, I am a big fan of Subversion. We use it at Flux Studios with generally very few problems. I also run a “server” at home, i.e. an external hard drive with a subversion setup, for all my personal work. Even though I am the only one accessing these files, I find the ability to back track changes and the general safe feeling of my work being committed is really worth it.
Compared to the only other version control systems that I have real experience with, CVS and Visual SourceSafe, it is really outstanding.

Oliver Steele has written an interesting article, The IDE Divide, describing two camps in the developer world: language mavens and tool mavens.
If you frequent this blog you should be well aware that I am pretty excited about Code Browser, a simple text editor with some cool folding capabilities. And as I find programming languages to be one of the most interesting subjects in the field of computer science, I think that I would intuitively put myself in the language camp. I would like to claim that language design will provide programmers with the required tools to improve their efficiency in the years to come. I am starting to doubt that this is the case, though.
I wonder if this divide is related to static versus dynamic typing. It seems to me that for an IDE to be any good, your language has to be somewhat towards the static end of the scale. The more binding that takes place at run-time, the less can be inferred by the IDE when editing. Bruce Eckel argues that a Python IDE is not quite as necessary as Java IDEs are. In Python, he claims, productivity is inherent in the language whereas in Java, you get the boost from the IDE.
Now I know that dynamic typing people hate the insulting “scripting language” argument but I am going to take it up anyway: what about large systems? I am not claiming that you cannot make or maintain large systems with dynamically typed languages. In fact, I think they might work very well for such systems. But with large systems, I find that the IDE really comes to the rescue. Intellisense provides me with the documentation that I need 90% of the time, right at my fingertips. The live parsing and syntax error highlighting is something that I could easily do without. But knowing which methods a class has, which parameters a function takes and what their types and names are is invaluable. I am reminded of the GMail slogan: Search, don’t sort. I think this resembles the main difference between the language camp and the IDE camp. Language people like to sort, IDE people like to search. When a system grows, the complexity will grow with it. Introducing layers and abstractions help - they’re indispensable, but they can’t remove complexity completely. Even if you have perfectly refactored code forming a tree of abstractions, you will have to trace through it vertically as well as horizontally. There will be many functions, files and lines of code. And in this case, I think that the IDE and the search “paradigm” work better.
As I said, I would really hate to claim that language research is unimportant, and I would love to be convinced that I am wrong here. Maybe I should do some work on Chandler or some other large, dynamically typed project, just to see what it is like..

More than once have I seen tracing frameworks with "levels" in them, like this:

The idea is that you state the importance or severity of your trace statement along with the message. This way, you can set a threshold when you watch the output. If you only want to see the very severe messages, you will set this threshold to high. In theory a very good idea, but in practice it doesn't seem to work. At least, I haven't seen anybody actually use it. I guess the reason is that when you're looking for a bug in your debug messages, you don't know what you're looking for and the hint might as well be in a seemingly unimportant message that pops up somewhere suspicious. So just to make sure, you set the threshold to "everything", and keep it there.
The concept of "levels", it seems, simply works very poorly with a task like debugging because errors can hide in the most innocently looking piece of code.

By the way, if you program for Windows, you should know about DebugView from SysInternals, a really helpful tool for monitoring trace statements.