Fog Creek Software
Discussion Board

C++ Programmers Doing VB: Implications

In "Working on CityDesk, Part Three", Joel recommends that we should hire "top-notch C++ programmers who dream in pointers, and let them code in VB." He promised that they will "become super-efficient coding machines." He proposes that such a team would drop down into C++ only to write DLLs or OCXs for time critical bits of the code.

Well, I agree. You'll get the productivity of VB and code that is structured as well as VB allows. I've been in a team running with this kind of approach for four years. But there is trouble in this paradise.

The problem is that you can do _much_ more in VB than you might imagine. And you can even get the time critical stuff to go pretty well in VB if you write it carefully. The percentage of code that needed doing in C++ in our system was _way_ less than the 5% Joel reckons for CityDesk.

Why is this a problem? Because after a couple of years your C++ programmers realise they aren't writing C++ any more. They are writing VB all the time. Their hard-won C++ coding skills are getting very rusty, and they're starting to wonder if they have enough current experience to land another C++ job. Round here a C++ programmer can get at least 20% better pay than a VB programmer. But you won't get a C++ job if the last time you fired up the C++ compiler was two years ago. So your C++ programmers start leaving to go and work for companies with too much spare money who do _everything_ in C++.

To be honest, I think that to remain competitive in the C++ jobs marketplace, a programmer has to be spending at least 25% of their time doing C++. This means that to keep these people, you're going to have to do 25% of your code in C++, whether you need to or not. Or you're going to have to live with rapid programmer turnover.

Saturday, December 15, 2001

C++ programmers use STL string, cope with multi-threading, use libraries, port their source to other platforms.

Christopher Wells
Saturday, December 15, 2001

I'm not sure I buy your premise.  If you're paying the going rate for C++ programmers, they can't get more money by leaving, so why should they?  The advantage of Joel's method is you can afford to pay fewer people more money because they're more productive, so you should be able to pay higher than the going rate.  If you aren't doing so, then you're cheating them, they'll quickly figure that out, and they'll leave, anyway.

Also, once you get rough parity with market rates, pay is usually no longer a factor in retention.  Other less-tangible things start to become important, like whether or not the person cares about the product, or the company.  If they care, they're going to stay to work on it.  If they don't, you won't  want them to stay.

James Montebello
Tuesday, December 18, 2001

A lot of C++ programmers tend to be somewhat elitist about their skills. It's the "you've got to be really smart to use C++ and any monkey can use VB" attitude, and to knock that guy off his pedestal and stop letting him feel superior is always going to hurt!

And really, what's more challenging that trying to track down memory leaks and obscure, impossible-to-repeat crashes? You just don't get that kind of fun in VB...

John C
Wednesday, December 19, 2001

Surely the quote should read:
"top-notch C++ programmers who dream in pointers, and let them code in Java."

Java Jim
Wednesday, December 19, 2001

James, my assumption is that I'm paying these people the going rate for C++ programmers or better. And I agree that pay is only one of a number of complex factors. What I'm saying is that one of the other factors is something we could call "value of current skillset", and that these people will be unhappy because they see this being eroded. They key thing is that even if people don't want to move job, they like to keep that option open. And being real, who's to say that in 6 months time your company won't be either a) bust, b) making half it's programmers redundant, c) bought out by some impersonal megacorporation that you hate working for, or d) taking on a new development manager who you hate working for.

It's a bit like being a hotshot VAX VMS programmer and being in a job that pays top dollar. Despite the good pay, you probably want to move out of VAX VMS programming because increasingly it's dead end.
But anyone doing it probably wants to move into something else because they see that in the not saying they will leave to get better pay

Friday, December 21, 2001

Ignore that last paragraph, I meant to delete it (which is why it makes no sense).

Friday, December 21, 2001

Hm.  First off, I'd argue that worrying about C++ skills deteriorating in 6-12 months is a bit silly.  If you're doing serious programming in any language, no valuable skills are rotting away.  Just because you might have to think a bit harder to remember C++ syntax doesn't mean you can't remember how to code in it, and it's something that any competent person could re-learn in a few days (say, just before an interview where it's known C++ skills will be needed).

Frankly, I find any shop that insists on a very specific set of skills is shortchanging themselves.  If you can program in any OO language, you can program in any other OO language.  At the "appropriate" level, even Perl can be considered an OO language.  However, if you have a diverse set of skills in your group, then you have several viewpoints on any given problem, and you're much more likely to come up with a well-thought out solution. 

I'll admit that far too many managers don't think this way.  Unless I'm desparate for work, however, I generally try not to work for such people.  I'll also admit that I've met people who couldn't even think in a block-structured way, let alone an OO way (a few COBOL programmers spring to mind), and that CAN be a problem.  But just because someone hasn't worked in C++ for a couple of years after doing so for several years isn't (or shouldn't be) a disqualifier.

James Montebello
Friday, December 21, 2001

Very convenient programs on

Friday, June 13, 2003

*  Recent Topics

*  Fog Creek Home