Skewed Bell Curve

With the advent of "visual" programming languages/tools and the whole RAD (RapidApplicationDevelopment) mindset and component based programming, it seems that the new wave of programmers entering the industry proclaim to be better programmers than they really are. Sure, they can whip up a browser with a text editor, HTML links, toolbars, status lines, drawing editors, and spreadsheets all built in... but can they really make a system run?

In most things, there is a bell curve of talent, where the majority of people fall around the 50% mark (average). The curve tapers off on the highly talented and moron ends, to about 2%. It seems that, due to the ease at which anyone can call themselves a "programmer", this bell curve is now skewed to the left [ you mean skewed right. The skew is named after the tail not the hump ] - the majority of programmers now fall below the mark for an "average programmer". [of course, the gaussian (bell curve) distribution is only a suitable approximation to an underlying binomial over a certain domain. Perhaps what is being observed here is that a Poisson distribution is a better fit.]

I see this all of the time when I interview people who put "4 years C++" on their resume, but think a "template function" is the empty code fragment the "Wizard" generates. Or say that their favorite feature of object oriented programming is OLE. And these people are the ones that we compete with for jobs.

Has anyone else experienced this skewed curve?

Yup. Drives me nuts.

But, to be fair, sometimes the "My God. You've been programming in that environment/language and you don't know this" reaction is a bit unreasonable.

Case in point. I'm a unix (NEXTSTEP) programmer. And I've written some handy little apps (useful for me) in Delphi (a Windows programming environment). People have seen them and assumed things like "Well, it runs in NT. I can ask him about the Win32API and message cracking and whether the bowels of OLE are showing signs of diverticulitis." And they're inevitably disappointed when they ask and I cheerfully admit ignorance.

The wizard done that. I saved my brain for the logic and coding of the parts that the wizards don't do.

Thinking in a language and platform independent way is good.

In a related issue: The people who drive me even more nuts are the ex-sysadmins who think "I've been writing shell scripts for the past 5 years. I know how to program." -- WilliamGrosso

I have to agree with the original entry here. I've interviewed a large number of people who claim to be C++ programmers, who have little or no idea of what the language is all about. Even people who, at least on their resume, claim to have 4 to 5 years experience.

To be honest, I am not looking for GUI people, but people who have real experience with the nuts and bolts of back end programming.

In this arena I don't believe that the platform experience is as important as a real understanding of the language. -- CarsonWilcox

This information is enlightening in a frustrating sort of way. I've claimed on my resume that I know C++, and I have read Bjarne Stroustrup's book, and I know how to write programs that use the StandardTemplateLibrary -- but I don't know how to use any of the wizards in the popular compilers; I don't know what the wizards and frameworks are doing behind the scenes; and it's next to impossible for me to find a C++ job. Apparently, these are the kinds of people companies want... not people whose knowledge is like mine. -- EdwardKiser

Well, there's a big old diverse job market out there. Different companies want different things. I'm a little surprised that you can't find a "real" C++ job.

We've been recruiting recently (feel like relocating Edward? Drop me a CV) and have struggled to find good people, that is, people who know the STL better than their IDE GUI. We ask candidates to rank themselves 1..10 on, their C++ competence, C++ being what we're looking for right now. Good candidates complain, correctly, that this very hard. Poor candidates answer confidently. Very few, even those giving themselves high self-assessments, have been able to correctly identify the potential problem in some example code given to them. None, even the ones that spotted the problem have been able to give the correct resolution of the defect.

This is a text-book problem. The text in this case being Meyers' Effective C++ , Item 14 Make sure base classes have virtual destructors. When I worked in a C++ shop, only a few years ago, we were damn well expected to read that book, and a few others, and do what it said, and understand why. How can anyone who's done any serious C++ development not have been bitten by (their failure to address) this problem? None of the candidates we've had who've claimed high competence in UML has been able to produce much more than a syntactically incorrect class diagram when asked to model a simple situation. And so on. It's very frustrating. -- KeithBraithwaite

C and C++ both operate very close to the hardware and operating system, so I would expect to see differences between Visual C++ programmers, UNIX C++ programmers, and embedded system C++ programmers. Instead of expecting people to walk into your shop and know every detail they will need for the job, take what they have to offer and train them in the rest. If they don't know STL, teach them (basic STL is pretty easy to learn to use once you get used to typing in the monstrous type declarations). Also, don't be surprised if you also learn something from the OLE or UML "weenies." --WayneMack

Wayne: If they're sure they know C++ but don't know when to use a virtual destructor, they're probably unteachable. Even if you allow for lousy teaching, they should still have noticed their own programs were bugged. -- JonCoupe

On the other hand, its entirely possible they never even in production code tried to delete from a base class pointer. I once had this project where you had to be very sure not to do that, but then again the problem never came up because the delete was on the correct pointer all the time due to avoidance of the dangerous construct (that is, putting such a derived class in a base class container that was allowed to own the object).

TeachYourselfProgrammingInTenYears