Dear DDJ,
I hope you don't need reassurance that readers value the very rare vein of software journalism represented by Mark Russinovich, Bryce Cogswell, and Andrew Schulman's "Inside SoftRAM 95" (DDJ, September 1996). You can count on my cheque anytime a peeved CEO thinks he can hire better lawyers than programmers.
Mike Kinghan
Headington Quarry, Oxford
IMK@ttools.demon.co
Dear DDJ,
I've been a reader of DDJ for quite some time, and Al Stevens' column has always been one of my favorite and first-perused features. I was laughing so hard after reading his July 1996 column that I simply had to write.
First let me say that I do not consider myself a C++ bigot. My three favorite languages at present are Python, AWK, and C++--in that order. That said, it was with great joy that I read your debunking of some of the Java hype that I simply cannot escape. Consider the following quote:
"Java is different from other computing languages because programs written in the Java language run on any computer."
-- Tom Brokaw, NBC Nightly News
As soon as I heard this, I knew Java was going to be the next big buzzword. When a major information-revision organization like NBC finally reports something, it's definitely on the approved list of "darling" topics. I hear nary a positive peep it seems when it comes to a more tried-and-true language like C++.
At any rate, I just wanted to write and say that I have enjoyed Al's columns, and I will surely keep buying DDJ as long as he is writing for it. Good luck with the new Quincy project--I know it to be sorely needed based on some of the
e-mail I have received asking questions about my software products.
John B. Williston
70541.1335@compuserve.com
Dear DDJ,
In his August 1996 "C Programming" column, Al Stevens advocates what I like to refer to as the "pop-quiz" style of interviewing. This is becoming increasingly popular, and perhaps such public advocacy of it is one reason why. But I feel it is misguided--far from protecting a manager from a bad hire, it will almost certainly lead him into making more of them.
Let me illustrate this. Al likes to pose questions to ascertain whether someone "understands" C++:
Of this little pack of posers, the only one of real utility is the last, which asks a basic question about the philosophies of programming that are embedded in the language. The rest are simply asking about details...and when one is dealing with the vast amount of minutia that is part and parcel of programming today; asking someone about details is asking for trouble. Rather than distinguishing between people who understand the language and those who do not, as Al clearly implies is the intent, all this accomplishes is to detect whether someone is accustomed to using the same subject of the language in the same manner as Al. Useful for putting together a team of programmers that all program just like Al, but not a good way to build up a diverse and powerful team that can address one's own weak points.
The first question asks about linking C++ programs and C functions--something that is only done in hybrid environments. In nearly all of the environments I've dealt with, this bit of knowledge was never used. Stepping outside of one's primary programming tool is seldom a good idea, and the only reason I had to use it was to build wrappers around Xlib so no one else needed to deal with it on the project I was working on. I could answer it, but if I was successful, no one else on that project would've ever had to deal with it!
The second question is interesting because it took me several moments before I realized he was talking about the "::" operator--I have never heard it called the "scope resolution operator"--and I wondered how I would handle such a question under the pressure of a job interview--particularly a job interview with a pop-quiz expert. Probably much the same way I've reacted to pop quizzes before--by deciding then and there I didn't want to work with the man.
Modern programming is already an enormous exercise in brute force memory, from the tiny C library K&R dealt with we have grown to the routine use of colossal tool kits, Xlib, Motif, diverse system types, IPC--multiple standards and APIs by the score in a program of any size. Thousands, even tens of thousands of identifiers, constants, functions, and so on. No one can hold all of that in their head! What you need to hold is not the information, but the index. If faced with the problem to call a C function from a C++ function it doesn't matter that I can recall to use extern "C" off the top of my head so long as I know the keywords that will lead me to the explanation and examples in the reference books. Trying to do this stuff off the top of your head is a good way to install bugs--especially in environments where type checking is so easily defeated.
Al goes on:
If you want to find out whether someone is a "retread" or an experienced C++ programmer, the tool is handed to you at virtually every job interview--the resume. And here are the questions you should be asking:
If you can't get a sense of how well a person knows the language from the responses to those questions then you are not knowledgeable enough to be trusted with hiring programmers.
If you want to hire people with the exact same skill set as yours, if you want people who don't care to be bothered to confirm the operation of a function they don't use every day, if you want fast talkers, then the pop-quiz method is a real winner. But if you want to know about someone who can write a large application in the language and get the job done on time, check out the bruises gaining that knowledge has left on his psyche.
The worst programmer I have ever met professionally, a man I have fired once, and whose hiring at a subsequent job led to my resignation, whose influence has totally destroyed at least two projects and seriously damaged and threatened a third, could have answered every single one of Al's questions, on his feet and blindfolded. He loved to learn every little detail of the language, always liked to be using the very latest features--even when they weren't needed to solve the problem. The reality of the matter is that no one can build a programming team without "retreads" with little familiarity with C++. You need to make sure you use enough of the language to get the best benefit from its capabilities without leaving the retreads behind in the dust. Because believe you me, they will get their hands into it, and they will do it irreparable harm without planning. Even if your pop quiz keeps them out of the original team, sooner or later they will be added for support or revision or posting, and what they do will propagate back into the code. Plan for it, and it will be far less painful. Every line of code that "expert" wrote was junked after he was fired, and replaced with something much less sexy--but it worked--and it was supportable by someone who was less than an expert in C++ trivia.
C++ has every programming feature ever invented. You don't need a tenth of them to write The Great American Application. So don't ask me about trivia. Ask me whether I can write your application.
Larry Smith
Digital Equipment Corp.
lcs@zk3.dec.com
Dear DDJ,
I recently did a keyword search of your searchable article index on the Dr. Dobb's web site (http://www.ddj.com) and got not only a group of relevant articles, but also the corrections/amplifications/bitches from the "Letters" columns of later issues. This is a great tool--thanks!
Terry Shankland
terrys@neta.com