Month: September 2006

I found a problem with Vault which is that, when a merge conflict arises, I can’t edit the code generated by the resultant conflict. My only choice is to accept or reject parts of the code.
Forum post

This simple case illustrates the problem:.

Lets say I have a released function as follows:
void func1(int numbre);

I fixed the spelling in a branch:
void func1(int number);

I add a parameter to that function in the released version:
void func1(int numbre, bool b);

Obviously no tool can figure this out automatically so a merge conflict arises. The proper solution for the branched version is to have both the “bool b” parameter and the correctly spelled variable.
void func1(int number, bool b);

However, the only option I’m given is to use the released version.
void func1(int numbre, bool b);

I have no way to edit text in the merge resolve tool. Even something as limited as saying “CONFLICT HERE” and saving out the file would help. But there’s no support for that. My only option is to save the incorrect file, fix the conflicts myself, and then merge later, which takes 10X longer than simply changing a variable name. This is doable but pretty unacceptable considering that Perforce does let you edit code and that conflict resolution is a fundamental feature of a source control application. I could use it by myself, but for a large company?

At work an artist wanted to improve the framerate by disabling lights. So he made the light color black. His logic was that if he couldn’t see the light, the light didn’t exist. He then bothered us (the graphics programmers) complaining that the framerate was still too low.

This is similar to the story of the woman who used the smallest font in all her Word documents in order to minimize the filesize.

There’s an easy solution to bot spam that as far as I know nobody has implemented yet.

1. All spam contains hyperlinks
2. All spam is sent repeatedly in a short timeframe from the same computer.
3. There is rarely a legitimate case where a single computer will send greater than some threshold (say 20) emails in a short timeframe which contains hyperlinks.

Therefore, just have email servers check outgoing emails. If emails per second is greater than X, and greater than Y emails have been sent by that system already in the last M minutes, and all those emails contain hyperlinks, that computer is potentially sending spam. It would be more accurate to add the condition “Identical or similar hyperlinks” but that would be easily circumvented.

Legitimate marketers will have their own email servers so can still send legitimate spam (such as mailling lists). Bot computers behind AOL accounts would be throttled.

The way to implement this is through a table which tracks the last N email senders. Every time an email with a hyperlink is sent, lookup that sender in the table. If that sender is not in the table, add it. Add to that sender’s spam score the number of recipients. If this would cause the score to exceed some threshold T, reject the send entirely and flag this sender in some kind of log as a potential spammer. This score will diminish by 1 point every M seconds. If the score reaches 0, remove this sender from the table.

With the correct settings, this won’t bother 99% of the users, spam bots would be throttled, and perhaps most importantly they would be flagged as suspect systems. An admin can then check if that user is indeed spamming and ban as appropriate.

When I was in college I would occasionally overhear a classmate refer to a vector when talking about a homework project. For years I was mildly puzzled by this. My programming classes didn’t have anything to do with linear algebra. It made no sense, but as I only heard it rarely I didn’t follow up.

Later on I found out that stl calls a dynamic length array a vector. What the heck? Other than trying to sound pretentious, I can’t think of any grounds for or reason to relate the two. A vector is a “quantity completely specified by a magnitude and a direction.” A dynamic array is an set which can grow in size.

The best term to use is a List (which is what I use in RakNet).

I’ve worked as a telecommuter for 7 years and as an on-site employee for 3. I’ve spoken to those who are both strongly for telecommuting and strongly against it. The conclusions I’ve come to are:

Telecommuting programmers work more and are more productive in the hours they spend
Because there’s no physical going to work, one is always at work. As a telecommuter I tended to work 10-12 hour days as opposed to the strict 8 hour schedule at my on-site work. Furthermore, I tended to work at times when I was feeling most productive, with fewer interruptions, noise, and on better equipment. Last month a lead programmer at the Collective spent one day working at home and remarked to me “I’m surprised how much I got done at home.” This is no surprise to anyone that has telecommuted.

Telecommuting programmers have better communication
A common argument against telecommuting is that communication is worse. The quality of written vs. verbal communication depends on the communication skills of the indvidual. While some producers and artists need improvement on this, programmers tend to excel at textually describing information, using accurate terminology with complete descriptions and all necessary and relevant information In practice, be it instant messenger or email, programmers are more likely to accurately describe what they mean in text than verbally. Furthermore, it is much faster to read and write than to speak, without the repetition and noise you get with verbal descriptions. Should verbal communication be necessary, there is an invention called the phone that does a pretty good job. It’s never been necessary for me in 7 years.

Regardless, I really don’t see any difference between speaking to someone on the phone and speaking to them standing there. Need diagrams? Want to show a bug? I’ve never had a case where a bug could not be accurately described to me without being there in-person.

Another benefit of electronic communication is that one can quickly send short messages “Where is the code that renders the GUI?” on instant messenger and get a fast response “See GUI.h”. This results in vastly improved productivity for the person asking the question without disrupting the attention or workflow of the person answering the question. With verbal communication you invariably disrupt the person you are asking and it takes them 15 minutes to get back into the zone.

Part of the reason why one person (me) was able to implement loading and saving of multiplayer games, with 4 game modes, in Deadly Dozen 2 was because of the efficiency of electronic communication. Anytime I had a question I could ask and get a fast answer. There is a massive time savings between being able to ask a question and continue working as opposed to having to guess and check foreign code, and redoing work because a previous assumption was incorrect.

Everyone I’ve spoken to that has tried telecommuting has had positive feedback regarding communication. One producer indicated to me that he wouldn’t allow it because of the poor communication. When I asked him if he actually tried it before his answer was “No but…”

Telecommuting programmers are cheaper

No office, no power usage, no free lunches, the programmer provides his own equipment. Programmers at home tend to continue working while eating while programmers at the office tend to go out to lunch with coworkers. Furthermore, telecommuting positions are in higher demand and there is a shortage of available positions. Due to supply and demand, this means telecommuting employees will often work for less and there is a greater pool to choose from. I’ve turned down work at Blizzard because they have no incentive to offer me to work there other than more money. But if they were to let me telecommute my quality of life would be so much higher that would supplant any monetary incentives they could offer.

But I don’t know who is working!

One argument against telecommuting is you can’t control people. You don’t know what they are working on or if they are working at all. However, just because you force a programmer to be at his desk doesn’t mean he is working. As long as the employer practices due diligence, keeping track of what people are working on whether they be at the office or not, you can easily detect the bad apples.

In my opinion a company that lets its programmers telecommute would enjoy increased productivity, lowered costs, and better communication.