Friday, June 1, 2007

Compensation

So you would figure that software managers would figure out a sane way to handle compensation for programmers by now. But, of course, they haven’t. Most of them are your average Econ 101 bean counting weenies. I can hear them now, “We can only afford to give three to five percent raises each year, because if we paid everybody what they deserved, then we would be spending too much. And what is it that these programmers do anyways?” That’s why an old co worker of mine told me one day over lunch that the difference between not busting your ass and busting your ass is the difference between a three percent raise and a four percent raise. I think that it should be obvious, even to the village idiot, that a system which creates such a sentiment is destined to fail.

So let’s take your classic example. You have a junior to mid level developer who has been with you a year, and he excels. He learns your business quickly. He fits in with the team. He, even at his junior level, brings a new way of thinking into the mix and keeps the senior guys from making bad decisions. It comes down to review time, and you give him an average review and your standard, crappy, average raise.

But here in lies the problem. He’s worth a lot more now on the open market then he was a year ago. You’ve trained him and brought him along, and he kicks ass. He not only has a good amount of experience in your industry now, but he has a good amount of experience at your company. There is nothing that can replace that.

So this poor guy, who has the head hunters pestering him like crack addicts waiting for their next fix, now has to play hardball. He has to threaten to leave in order to get what he clearly deserves, and no matter what happens, it’s all down hill from there.

Let’s say that you are lucky, and he takes his crappy raise and stays. He will resent you for the rest of his life. He will be a lot less productive. In fact, he’s probably spending most of his days day dreaming about architecting the “fuck you button”. They say that, at some point or another, every man thinks about killing his wife. I don’t know if that’s true, but I can tell you that every programmer who has ever had a regular job has thought about the fuck you button. Thank God that 99.9% of good coders are extremely ethical, because if they weren’t, then we would all be in trouble, but I digress.

A more likely scenario is that this bright young coder will finally break down and take a call from one of the bottom feeders, I mean head hunters, and he will land a job, somewhere else, making what he asked for, and taking all the things that you’ve taught him over to someone else.

Then, of course, you have to replace him, and that takes a few months, and you’ve lost all that good will, in all senses of the word. The good will of your past and current employees who look upon you to treat them right, and the economic good will of a kick ass developer, whose worth far exceeds what you could ever pay him.

And guess what. In order to replace him, you are going to have to pay the new guy as much money as he was asking for in the first place. Plus that nice 15% fee to the head hunter. And now, because you were trying to be cheap, you have to spend even more than what you should have spent in the first place. And God knows, you’ll probably screw it up with this guy too, and thus the circle of life continues.

The whinny little managers now have their hands up like pre-schoolers. “But Charles,” they say. “What if we really can’t afford to pay him that much?” Well, if you really can’t afford to pay him that much, and I mean REALLY can’t do it then that’s where some leadership skills comes in. You explain to him what’s going on. You tell him how valuable he is and how you know that he is worth more. You promise to pay him what he’s worth at a later date, like when you land a new client, and you stick to it. Nine times out of ten, you get a happy coder who stays and works even harder for you than if you would have gave him the good raise.

Don’t you wish that they would have taught you that when you got your MBA?

Monday, February 12, 2007

The Case for C#

In an attempt to weigh in one of the greatest programmer death battles since Big Endian V. Little Endian, I am going to make my case for C# over VB.Net. We all know that, for the most part, you can do everything in VB.Net that you can in C# and vice versa. There are some things in VB.Net, like optional parameters and parameterized properties that I particularly like, but they don’t outweigh some of VB.Net’s drawbacks.

The human eye is trained to love things that are symmetric. Supposedly, the more symmetric a person of the opposite sex is, the more attractive we tend to find them. I think that for me, this holds true with programming languages. If you are someone with taste, then, surprisingly, you might love those curly brackets that people just love to hate. Why? Because it’s symmetric.

This is a nice way of saying that all those If .. End If and For..Next blocks just look pretty bad because of lack of symmetry. Those funky curly brackets make things look clean, readable, and symmetric. It’s a thing of beauty. I challenge anyone to show me an MSDN code example where the VB code looks better than C#. Anyone? Anyone? Bueller? Bueller?

Taste is important. I mean who wants to look at something ugly all day. VB.Net is just as powerful as C#, but it is pretty damned ugly, even on a good day. This sort of makes it hard to learn, even though BASIC was probably one of most people’s first languages, if they started as a teen like I did.

This is why I never learned Perl. Perl is butt ugly. If Perl was a baby, even its Mama would even think that it was ugly. To this day, I really don’t know much about Perl, and I am almost proud of that. Who the hell chooses to use Perl now? If you are one of these people, then I think that it’s too late for you. You drank the Kool-Aid and pray to Larry every day. You will need some re-education to come back into the real world where languages don’t look like puke. But in all fairness, Perl has one thing going for it. It’s where we get Regular Expressions from, which look pretty funky as well, but hot damn are they powerful. They are like the Mac Truck of string manipulation, while you’re sitting there driving your little pinto with your one off string functions, but I digress.

Paul Graham always says that when you choose a language, you are not choosing a language as much as a community. This is so true. That’s why proponents of VB say that there are more developers who know VB than C#. This may be true, but what they really should be asking is how many good developers would choose VB over C#? My experience, anecdotal at best, tells me that with a few exceptions, that answer is zero. Why is that?

Well, if I’m looking for a Developer on one of my projects, I want one that has a certain amount of working knowledge of both Object Oriented Programming and Systems Programming. Why Systems Programming? Well, we live in a world where the law of leaky abstractions is in full effect. If people don’t know what abstractions that they are using, then the day that those abstractions fail, they will be caught with their pants down with only a hammer to use as a belt. That isn’t a pretty site.

So ask yourself a few questions. What languages do most people do Systems Programming in? Well, you guessed it, our lovable friend, the scripting language of the Von Neumann machine, C, and later C++. What languages have most people used for OOP in the past? Mainly C++ and Java. What language would people who are very familiar with C, C++, and Java choose? Ten points goes to the guy who said C#.

Now, I’m not a language bigot like most in the C# camp. I actually use VB at my job, because, well, everyone has to pay the mortgage. And there are a lot of VB guys out there that are hardcore. But we must remember why VB gets its reputation as a wimpy language. It’s because VB set the barriers to create desktop software way lower then they were with C++. I never did desktop programming in C++, but from what I understand, it was about as pleasurable as root canal.

So VB was sort of the best and worst thing that happened to programming. We now had this rich new abstraction for creating desktop applications that almost anyone could learn which had syntax that we loved when we were kids. Cause, after all, we were all young once.

But then something happened. The barriers were set so low that people who had no business being coders started to code little VB apps here and there, and they actually started to gain credibility, even though we all know that these guys were not ready for prime time.

If we kept good coders using VB, then they could have harnessed that new found power where they could in intelligent ways. We would have a tool that wasn’t a silver bullet, but raised productivity tremendously. But instead, we hired cheap programmers, because most companies don’t know a damned thing about the whole concept of a price to quality ratio. And thus, VB took us by storm.

Now there is one circumstance in which I would choose VB.Net over C#, and that’s when you have a lot of tried and tested legacy code in VB6 that you wanted to port over to .Net. This is dangerous too, because those conversion tools, like most things, almost never work the way that you want them too, even if you did code your app cleanly and in the right way. But let’s be honest. We all know you didn’t. But an even more dangerous situation is the one where people will start to code in VB.Net like they did in VB6 and VBScript. The language got even more ugly because it had to do new things and still have a semblance of backwards compatibility.

It’s like how all the C programmers who used C++ as a glorified C compiler. You could do some Jedi mini tricks on the compiler, and it would happily comply. That’s what made C++ so hot, and also what made it pretty damned ugly too. Java was prettier but had so much hype attached to it that it scared me. It also arbitrarily took away some of the cool features of C++ like preprocessor directives, Templates, and operator overloading. When I found C#, it first looked like Microsoft Java, so it turned me off. But once I really got into, it was like having a Paul on the Road to Damascus moment. Walk the path, and it will change your life forever.

So get over those squiggly lines, get yourself a C# book, and go to town. It may be painful now, but trust me, you will love yourself more in the morning.