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.

startguiden.dk is a site for startups featuring lots of valuable resources for entrepeneurs. Martin and I were interviewed for “portrait of the week”, about Flux Studios. It’s in Danish.

Alright, I’m about to give up.
My girlfriend gave me a Sony NW-E505 Walkman and I was quite happy. It seems durable and robust, it charges in no time and best of all- it actually looks great. The style is quite different from iPods but I would say it definitely competes in the upper end of the design scale. In fact, I am quite happy with this piece of hardware if it wasn’t for one thing: the software. By software I mean both the firmware and the enclosed control software. SonicStage seems like a half-completed attempt at an iTunes competitor. Honestly I can’t say much about it because it made such bad first impressions on me that I uninstalled it after fifteen minutes or so. There is a small tool called MP3 File Manager as well which appeals to me much more because it is so simplistic. Only this tool is a little too simplistic - you can only create a folder by copying a folder with contents onto the walkman, and you cannot rename folders. Also, there is some problem with the firmware (I expect) that means that I have only been able to listen to about a third of the audiobooks and podcasts that I have put onto it. Whether it has to do with the encoding or maybe the length of the “track”, I don’t know. But even if working, listening to podcasts is way too complicated because I have to download and copy them manually.
So I am seriously considering buying an iPod Nano even though it annoys me because actually, the hardware part of the walkman is perfect for me. Do any of you have better experiences with this thing than I do? Is there some third party software that is compatible maybe?

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.

This article on negotiation topped on reddit this morning. The article claims, as it is often heard, that you should avoid making the first offer, along with some other tips.
This is a wrong negotiation tactic.
The reasons given are that you may find yourself stating a lower figure than what you actually wanted, and that the other part may in fact be willing to offer you more than you expected.
As this article explains, you are better off by making the first offer. Obviously, if this means that you “find yourself stating low numbers”, you have some confidence issues that you should deal with first. But if you know what you are worth and you feel comfortable with the given price, you will be the one defining the range within which the negotiation takes place. Of course, you will be discarding the possibility that the other part was prepared to pay much more than you expected, but this will be less likely to happen if you actually know what you are worth.
Of course, starting out high (and you do want to start out high – there is no working yourself upwards) can be scary and you might fear that the other part will refuse to deal with you out of offense. I think that this is actually very unlikely to happen. Either the other part is an experienced negotiator and will accept the fact that negotiations have to start somewhere, or he is not which will mean that he is probably just as insecure as you are.

At one point, I was to set up a continuous integration server at BestBrains. The servers we had ran Linux which was fine for file sharing, subversion and web stuff, but we mostly developed Windows products and the CI server had to run Cruise Control.NET. Although that might actually have been possible with a Mono setup, we decided that it was not worth the trouble and that we would invest in a new server. I suggested that we used a laptop and we laughed about it a little because laptops don’t really feel like server machines. But after thinking it through a little more, we actually ended up doing so. Laptops, we found, have a number of advantages:

• They have low power consumption. This is a good thing for a machine that is always on.
• They’re small. You can close it and put it into a drawer.
• They have built-in UPS’s. Not only does this make them immune to quite long power outages, you can unplug your server and bring it to your desk without shutting it down, if you need to maintain it.
• They don’t make a sound. If you don’t have a dedicated room for servers, this makes all the difference in the world. We did, but we ended up having the CI server in the office, simply because it didn’t bother us at all.

Obviously, I wouldn’t advice you to run a heavy load server on a laptop, but for lighter stuff, it’s really great.

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..

As you can see, I gave the site a minor face lift. The design is more or less intact but the WordPress engine offers a better comments interface and there are nice plugins allowing me to embed syntax highlighted source code very easily.
The old site is still up and it will remain up for some time.