Feel free to email me at 'hotweird' at hotmail.

Before I go any further, I want to make it clear that I don't want to talk down Scottt or the Chandler team. Scott makes a number of great points that reflect my own experiences. Virtually every large software project I've seen has had problems akin to those Scott describes. Especially every large project I've worked on. I'm certainly as guilty of these difficulties as any programmer. But the examples that Scott describes are good grist for discussion about software development.

When people talk about talented programmers they are usually refering to their ability to write correct code, whch solves problems quickly and elegantly. I suspect that that is what Scott was implying by describing the Chandler team as ace programmers. Raw coding skills vary widely across individuals. When it comes down to it some programmers are just more talented than others at writing code. Large team projects - projects with more than 3 programers with schedules of more than a few months - require a whole set of skills beyond raw coding. On large teams, excellent coding skills are a prerequisite. Alone, they qualify you as a beginner, not an ace.

From Beginner to Good

For me, the mark of a good team programmer is someone who does not suggest rewriting everything from scratch. Scott makes the very valid point that programmers like to program - and that they don't like to understand code written by others. Truer words were never spoken. Time and time again I've seen smart novice programmers suggest rewriting code produced by other programmers. I've noticed an inverse relationship betwen the esteem I hold for a programmer and the number of times I've heard them suggest a rewrite of a large software project.

Good team programers are capable and willing to work with a codebase that is too large for a single person to rewrite within the project's schedule. They recognize that the existing codebase has shortcomings and they have the maturity and discipline to know that attempting to 'fix' everyone of those shortcomings will almost certainly kill the project. Instead they identify those areas which must be improved on to deliver the project, and they have the skills to make significant changes to a large and ugly (because every large piece of software is ugly - but that's another story) codebase without causing the whole thing to destabilize.

And From Good To Great

If the mark of a good team programmer is the ability to work (usually grudgingly) with the code of others, then the mark of a great team programer is the ability to produce code that other programmers on the team will gladly use. Programmers are the most fickle sort, and if you can produce code that other, less skilled, coders will use without suggesting a rewrite - then you've elevated yourself to the top of the programing heap. Great programmers produce code that is so good that it will prevent the cross programer problems that plague most large software projects.

Peter

Some of their results are here:

http://research.microsoft.com/research/pubs/view.aspx?type=Technical%20Report&id=994

http://research.microsoft.com/hip/papers/Ko2007BugFixing.pdf

http://research.microsoft.com/hip/

I'm looking forward to more great work from these folks,

Peter

Charlie Calvert video taped our discussion on some of the new C# 3.0 features. Find it here: http://wm.microsoft.com/ms/msdn/visualcsharp/peter_hallam_2006_11/PeterHallam01.wmv.

Cheers,

Peter

What do professional programmers really do with their time anyway?

Design Code

Write New Code

Understand Existing Code

Modify Existing Code

Verify Existing Code Still Works

New Code:                         2%

Modifying Existing Code:     20%

Understanding Code:         78%

New Code:                         5%

Modifying Existing Code:     25%

Understanding Code:         70%

First off, I want to appologize for not having any activity on my blog for a while. I just got back from a wonderful 3 week vacation in Spain. Now that I'm back, rested and limber, here's a twisted peice of C# code which is gauranteed to turn your brain inside out.

Why does the compiler (correctly) give an error message on the override in the following code?

abstract class A<T>
{
    public abstract T getT();

    class B : A<B>
    {
        public override B getT()
        {
            throw new System.Exception("The method or operation is not implemented.");
        }
    }
}

I got this code from a coworker, and I must confess that the first time I saw it I was convinced that the behaviour was a compiler bug. It turns out that the compiler correctly diagnoses the problem, though even after seeing the error message it took me a while to figure out what's going on. I'll post a discussion in a couple of days.

Any Takers?

Peter
C# Guy

Why are constant expressions required in case labels? I see a switch statement conceptually the same as a series of chained ifs/else ifs.

This is an interesting question. It seems reasonable that you should be able to switch on an expression of any type, and have case labels which can take any value – even values which are not compile time constants. A simple example would look something like this:

class Program {

    static void Main() {

        object myFirstObject = ...;

        object mySecondObject = ...;

        object obj = ...;

        switch (obj) {

        case myFirstObject:  ...; break;

        case mySecondObject: ...; break;

        default:             ...; break;

        }

    }

}

which would be equivalent to this code:

class Program {

    static void Main() {

        object myFirstObject = ...;

        object mySecondObject = ...;

        object obj = ...;

        if  (obj == myFirstObject) {

           ...

        } else if (obj == mySecondObject) {

           ...

        } else {

           ...

        }

    }

}

At first glance this seems like a great idea – the switch is slightly more compact and readable than the chained ifs, both desirable characteristics of a programing language. If the construct could easily be limited to this simple example it might be a reasonable language extension to consider. Unfortunately, things are not as simple as they appear at first glance…

Firstly, what happens when myFirstObject is equal to mySecondObject? Well that depends on which case label came first in your switch. The order of the case labels becomes significant in determining which block of code gets executed. Because the case label expressions are not constant the compiler cannot verify that the values of the case labels are distinct, so this is a possibility which must be catered to. This runs counter to most programmers’ intuition about the switch statement in a couple of ways. Most programmers would be surprised to learn that changing the order of their case blocks changed the meaning of their program. To turn it around, it would be surprising if the expression being switched on was equal to an expression in a case label, but control didn’t go to that label.

Secondly, allowing non-constant expressions as case labels lets in some significantly less desirable code as well. For example, this code would also be legal:

        switch (obj) {

        case myFirstObject:  ...; break;

        case mySecondObject: ...; break;

        case EraseMyHardDrive(): ...; break;

        default:             ...; break;

        }

In C#, any non-constant expression can yield side effects. There is currently no notion of a non-constant expression which does not have side effects in C#. Seeing code like this will leave the reader scratching their head wondering when their hard drive will get erased.

And lastly, programmers coming from a C/C++ background will expect that the execution of a switch statement will be fast and that it will take about the same time to reach any particular case label. When the case labels are constant integral values (or strings), the compiler can do some great optimizations to make the execution speed of the construct match the coder’s expectation. With non-constant case labels, getting to the 100^th case label would take significantly more time than getting to the 10^th case label. Again, this would be surprising to the programmer.

Peter

C# Guy

Why is it that you cannot use enum constants in a switch statement's cases without first casting them to type int?

Often you will want to use Enum constants as case labels in switch statements. Sometimes, the compiler will complain and require a cast to int on each case label. This will look something like this:

    enum Color { Red, Green, Blue };

    int i = ...;

    switch (i)

    {

    // cast required! Aarg!

    case (int)Color.Red:    break;

    case (int)Color.Green:  break;

    case (int)Color.Blue:   break;

    }

The confusion stems from a subtle difference between C++ and C#. In C++, values of enum type are implicitly convertible to int. In C#, conversions between an enum type and its underlying type are explicit and require a cast. To maintain consistency, the requirement for the cast carries over into the use of enums in switch statements.

However, you can use expressions of enum type as case labels without a cast, but only in a type safe way. The rule is that the type of the expression being switched on, the ‘governing type’ of the switch statement in C# language spec terminology, must match the type of the expressions in the case labels.

For example:

    enum Color { Red, Green, Blue };

    Color c = ...;

    switch (c) // Governing type is ‘Color’ not ‘int’ so ...

    {

    // ... no cast required

    case Color.Red:    break;

    case Color.Green:  break;

    case Color.Blue:   break;

    }

One of the design goals for enums in C# was to treat them as first class types that were truly distinct from their underlying type. This is one of the subtle ways that this decision manifests itself in the language.

Peter

C# Guy