On Programmers and Raises

If your boss came up to you and asked you what you were worth, what would you say?

As a group, it’s not hard to quantify programmers’ worth. After all, we create the product that should:

  1. Make other people’s lives easier
  2. Make money for the business
  3. Reduce costs for the business

But getting down to the worth of each individual programmer, that’s a lot harder.  Does the programmer that writes more code get more money? Is it the programmer that has less defects in their code? What about the person that holds the team together?  What about the most productive person (Highest LOC + less defects)?

It’s impossible to compare programmers unless you compare everything that matters, and it all boils down to simple questions:

Are you better off with this person than without? : If they weren’t here, would you be where you are today? If not, where would you be? Would you be better off or worse off?

We ought to ask ourselves that question daily. So, how about it: Is the business better of with you here? If so, why?  That’s what you’re worth.


When Not to use Finalizers in .NET

The best thing Microsoft ever did for C# was to create it with a syntax similar to C and C++.

The worst thing Microsoft ever did for C# was to create it with a syntax similar to C and C++.

C and C++ are unmanaged languages, so an apple in C could be an orange in C#, or it could be an orangutan.

The following code was written circa-2003, by a programmer who was probably a C++ programmer turned .NET, and didn’t give a second thought to including a finalizer in his code. A telling indication was that he even labeled it as a ‘destructor’.

Warning: Here There Be Dragons.


public class AndObjectFilter()

    private ArrayList objectFilters = new ArrayList(); 
    #region Destructor 


There are (at least) three things wrong with this code:

  1. Use of a finalizer.
  2. Use of a finalizer to clear an ArrayList.
  3. Using an ArrayList.


Use of a Finalizer

Finalizers in C# are used to allow the developer to force the garbage collector to run certain code before garbage collecting an object.  There’s a wealth of material written on Finalizers, and I won’t repeat it all here:

  1. Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework by Jeffrey Richter
  2. Stack Overflow: Finalize and Dispose Pattern in C#
  3. Two things to avoid for better Memory usage

To summarize what all of these points say:

Don’t use Finalizers if:

  1. Your class consists solely of managed code (or)
  2. You plan on implementing the IDisposable Pattern on that class

Should be pretty easy to remember, unless you’re a C++ programmer that doesn’t read up on new-fangled technology.

Use of a Finalizer to clear an ArrayList

Disregarding for the moment that you should never, ever use a finalizer like the code shown above does, there’s a second point:

Why in the name of all that is holy is the programmer using the Clear() method, in the finalizer, no less?

  1. They have no idea what the Finalize method actually does (See Use of a Finalizer above)
  2. They really have no idea what ‘managed code’ means
  3. They have no idea what Clear() does

The ArrayList.Clear() method simply clears out the contents of the array. The capacity of the ArrayList is still set, probably not what the programmer wanted to do.

Using an ArrayList

The code is presently in .NET 2.0 and has been for years, although it is a Micro optimization, even using a List<object> performs better than an ArrayList:


Inserting into ArrayList took: 8.27ms
Inserting into List took: 0.002ms
Enumerating ArrayList took: 2.284ms
Enumerating List took: 0.413ms

That’s over a 4000% difference in Insertion, and List is 5.5 times faster for enumeration!

Just because something quacks like a duck doesn’t make it a duck. Sometimes it’s actually a really expensive C# operation that’s better left out of your code.

My Score On the Joel Test

I use the Joel test to determine a job’s worthiness, and have been for some time now.  However, I’ve never actually applied it to an organization that I’m working for, as if somehow I’m exempt from my own requirements.

Time to end that.

Here’s how my current organization fares on the Joel Test:

  1. Do you use source control? Yes
  2. Can you make a build in one step? No. Database changes are still run manually.
  3. Do you make daily builds? No.
  4. Do you have a bug database? Yes.
  5. Do you fix bugs before writing new code? No.
  6. Do you have an up-to-date schedule? Yes.
  7. Do you have a spec? Yes.
  8. Do programmers have quiet working conditions? No.
  9. Do you use the best tools money can buy? No.
  10. Do you have testers? Yes.
  11. Do new candidates write code during their interview?Yes.
  12. Do you do hallway usability testing? No.

That’s a pretty dismal 6/12.  Probably better than a lot of places, but not as good as I’d like.

Since I also have the “George Test” I use, I may as well list my score here:

  1. How’s the Internet Access? Excellent.
  2. How much overtime do you expect? None.
  3. What’s the dress code? Business casual. We do jeans fridays; as if it’s some sort of perk.
  4. Do you conduct Code Reviews? Brown bag lunches? Hey, that’s two questions, but Yes and Yes.
  5. How many meetings do you have? One: A daily standup.
  6. Do you pay for me to attend professional conferences? Don’t know. Haven’t tried it. Will do so next year, though.


When’s the last time you rated your organization according to the Joel test? Isn’t it about time you started?

Increasing your Interview Cred

As a team lead, I’m heavily involved in the interview process, a process that I’ve written about on several occasions. During interviews I end up asking all the candidates the same question: What online resources do you use to learn about programming?  I’ve heard the words ‘MSDN’ out of more C# developers than I care to admit.  It’s gotten to the point that I’ve had to change the question, Besides MSDN, what online resources do you use to learn about programming?

In theory, a programmer that only checks MSDN is at least as likely to be as good as a programmer that checks other resources as well; so the results shouldn’t really matter. But in practice? That’s a whole ‘nother story.

Programmers that only check MSDN or ExpertsExchange don’t normally fare as well in my interviews. Maybe it’s because the information in MSDN isn’t backed by Real World Problems, maybe not. Whatever the reason, there’s a noticable and measurable difference between the programmers that cite Stack Overflow, and those that don’t. 

The difference is so stark that I can even graph it for you:

I have a few theories as to why this is:

  1. Browsing Stack Overflow for any length of time means you will learn something knew that actually happens in a Real World scenario.
  2. You’ll learn something from someone who works on the language or someone who’s written books on the subject.
  3. The answers you read are vetted by the community as a whole, and you can immediately what not to do.

On MSDN, or on Google, you don’t get that. You just get what you asked for, it’s up to you to determine whether or not it’s a good idea. Because of that, you have endless questions on how you’d parse HTML with a Regex.

Bottom line: If you’re an interviewer, ask that question and see the answer for yourself. If you’re a programmer, then it behooves you to be active on Stack Overflow.

Don’t Fight Your Platform

One of my favorite interview questions is from Steve Yegge. Ask the candidate to explain how they would change the format of phone numbers in thousands of files.

It’s a question that screams, “Use Perl” or “Use Unix”, but you’d be surprised just how few people get it right.

The C#/Java’s developer answer is to write a program that reads in a program line by line, and parses out each string using built in string manipulation.  The smarter C#/Java developers even say to do that, but use a Regular Expression instead of built in string manipulation.

That’s all well and good, but it misses the point of the exercise: Don’t fight your platform, Use the right tool for the right job.



Corporate Speak: Tasker

Tasker (plural: taskers) (n): Refers to the task given by one induvidual to another individual to complete, Normally in a corporate structure where the task-giver is above the taskee in the company org-chart.

NB: Although Webster defines ‘tasker’ as ‘one who imposes tasks’, it has seemingly been molded into this meaning. If we take the corporate meaning at face value and Webster’s meaning at face value, then we have a very confusing conversation indeed!