Google knol - perfect for programmers

Many sites are reporting about Google knol as a competitor to Wikipedia - I see it as something completely different: An easy way to write down some knowledge that you may have gained, in order to share it with others. My first knol is a copy of one of my blog posts: Win32 thread names in Delphi. This is a kind of information that doesn't belong into Wikipedia, but can be helpful to others.

I can only recommend all programmers to have a look at the knol principle, because it's an easy way to offload information in a way that makes you able to find it again easily, in case that you don't have anywhere else to put it. And maybe somebody will provide extra information that makes you learn more about the topic that you're working on.

Language barriers when outsourcing programming

In case you're working with outsourcing, you may have experienced communication problems. English is my 3rd language, and when I communicate with people from other parts of the world, who have English as their 2nd or 3rd language, the message is not always understood as intended.

In order to communicate well, you need to know the most frequent causes of problems. This post describes some of these - when communicating in English with people that have Russian or a related language as their primary language.

Russian is a different mental model, so it requires some effort to communicate properly in English, and if the sum of language effort and programming effort has a maximum, it means that very complex programming issues may lead to more misunderstandings in language.

A very frequent problem is the lack of "a" and "the" in Russian. Example: "Make the program create a file for output. Export graphics into the file." Disregarding "the" means that you may end up having two files instead of one. A solution could be to replace "the" with "that" when you are referring to a specific file.

The next problem is about tenses. Russian basically has past, present and future, and completed and uncompleted verbs. It does not have the same tenses as English, and some English constructs are not made using tenses in Russian. Tenses are important when describing work processes. Example: "Yesterday at the meeting, I had given you instructions..." (the instructions were given before the meeting) If your programmer uses automated translation tools to translate this to Russian, the result is "Yesterday at the meeting I gave you instructions..." - which is totally incorrect and causes confusion.

Basic construction of sentences is also a problem. It can be very difficult to understand complex English sentences like "Moving the button up could cause some problems with the layout that was requested at the meeting.". It takes quite some analytical work to decompose this sentence into it's basic building blocks if your primary mental language model is not close to English.

Vocabulary is obviously a problem - if you don't know a word, you need to look it up. But even if you know a dictionary's translation of a word, you can get into trouble. Example: "Gossip was the main business of the evening". The word "Business" can be translated in many ways to russian, and in this sentence, it makes a big difference if you translate to "делом" (what to do) or "бизнес" (bisness=commerce).

Correct English. If you don't write correct English, it can be very hard to understand it, and it can be impossible for automatic translation tools to help out the reader. For instance, "The discusion was about maintanance." (2 spelling mistakes!) auto-translates to something like "xyz was about hobbies", whereas "The discussion was about maintenance" is autotranslated correctly, using my favorite translation tool.

Special thanks to Rikke, Anatoly and Alexander for their contributions to this post.

Win32 thread names in the Delphi IDE

The Delphi help only mentions how to do this using C++, and Google doesn't provide the solution in Pascal easily, so I thought that I'd better publish the solution here. In order to see names for your threads in the Delphi IDE while debugging your Win32 application, call SetCurrentThreadName() in your TThread.Execute method:

procedure SetCurrentThreadName(const Name: string);
type
  TThreadNameInfo =
    record
      RecType: LongWord;
      Name: PChar;
      ThreadID: LongWord;
      Flags: LongWord;
    end;
var
  info:TThreadNameInfo;
begin
  // This code is extremely strange, but it's the documented way of doing it!
  info.RecType:=$1000;
  info.Name:=PChar(Name);
  info.ThreadID:=$FFFFFFFF;
  info.Flags:=0;
  try
    RaiseException($406D1388, 0, 
      SizeOf(info) div SizeOf(LongWord), PDWord(@info));
  except
  end;
end;

Let's hope it gets easier to find on Google now.

Code style of old age programmers

It seems that I have the same age as Jeff Atwood, but somehow not, when I read his latest post. Somehow I feel "been there, done that", because I would almost have agreed with him 10 years ago, while still being a freelance programmer, helping out in various programming teams. However, today I'd definitely say that maintainability is much more important than most programmers want to acknowledge.

Most programmers spend most of their time maintaining code, not writing new code. They may spend time on maintaining their own code - but it's still about maintenance. And actually, they spend much more time per SLOC when doing maintenance, than when writing new code. In other words, in order to be really productive, it's the maintenance part that needs to be optimized, unless you're doing a quick and dirty application that nobody is going to use (yeah, right!). The perfect source code is when it works perfectly AND cannot be easier to maintain. This includes simplicity, of course, but it also includes comments, understandable variable names, well defined context and well defined invariants.

When to hide or disable menu items and buttons

I often disagree with Joel, also in his latest post about menu items. Hiding and disabling buttons and menu items is usually done in order to prevent, that the user triggers an event, and it's perfectly ok to do in some cases:

• Hide buttons that the user wouldn't search for. For instance, a non-administrative user doesn't need to see the Admin button.
  
  
• Disable buttons where it is obvious to the user why it isn't clickable. For instance, a well implemented undo functionality doesn't need to have it's menu item enabled before the user starts editing. That would actually confuse some users.
  
  
• In all other cases, make the button visible and enabled, but show a message that explains to the user, why this functionality is currently not available, and what the user can do to make it available.