tmh@well.UUCP (Todd M. Hoff) (06/20/89)
Responses to responses about: > What do you need to know to be an expert C programmer? There must be some real answers to the question about what makes a C expert. We all at least have implicit criteria. In the Unix world I saw a list categorizing 9 levels of Unix expertise. What the different categories were escapes me now, but they went something like: 1. Neophyte. can log onto the system and logout 2. use ls -l and cd ...... 9. Wizard. Can use m4 in their sleep and knows all the options to ls. Something anologous for C should be possible. After all, when we want to hire a senior level programmer we don't merely mean a programmer with X (assumed large) years of programming. We mean somebody who really knows their stuff. I'm after what they "know" not just inane witicisms. > ... if you have to ask, you aren't I know this was said mostly in jest, but I think its very valuable to externalize programming "rites of passage." > Who cares? This is certainly a valuable question and is right up there with the infamous "why?" question. It should always be asked but too often "Who cares?" is used as an escape. Actually there's plenty of reasons to care: 1. When hiring someone how do you know they are qualified? By asking questions, right? Which questions? This relates to my question. 2. How do you as a programmer know you are getting better? Writing more code per millisecond? Fewer bugs? Or perhaps understanding the essence of the problem and writing the most elegant solution to that problem? What are the C building blocks that are elegant? Not just pointers, but higher levels of technique. 3. When doing code reveiws, how do you judge the competence of the code with no definition of what "good" code is? > ...Knowledge vs wisdom First, since C is recursively defined, no database no matter how large could hold all valid 'C' constructs and idioms. That's why we have compilers. Besides such a database would be merely a listing of facts. Whereas an expert system combines raw facts with inference rules. These rules are a form of canned wisdom. Not as ranging as human wisdom, but as several medical expert systems demonstrate, wisdom useful enough to save lives. I don't think a semantics game battling knowledge vs wisdom definitions is useful. The point of my question is clear. > What groups would be appropriate? This one of course. I'm asking about the essence of C programming. This seems at least as valid as pointer addition. Any more takers? Todd
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/20/89)
In article <12280@well.UUCP> tmh@well.UUCP (Todd M. Hoff) writes: > 1. When hiring someone how do you know they are qualified? > By asking questions, right? Which questions? This relates > to my question. At previous employers, we used to give a programming examination to applicants for programming positions. Part of the test were short- answer questions, e.g. "What is a sentinel?", and part consisted of a couple of practical exercises for which we were more concerned with how the applicant approached problem solving than with arrival at a solution. For example, one such problem may be how to clip a line segment (given as endpoint coords.) to a 2-D H/V rectangle. > 3. When doing code reveiws, how do you judge the competence > of the code with no definition of what "good" code is? I'm moderating a series of code reviews now, and we have definite criteria. I think it's a waste of time to wander aimlessly through code. >I'm asking about the essence of C programming. I don't think you should emphasize the "C" so much. C expertise is not commensurate with programming expertise. More importantly, programming is only one aspect of software engineering; there are other equally important skills needed besides those for writing programs.
evil@arcturus.UUCP (Wade Guthrie) (06/23/89)
In article <12280@well.UUCP>, tmh@well.UUCP (Todd M. Hoff) writes: >> What do you need to know to be an expert C programmer? > > There must be some real answers to the question about what makes a > C expert. We all at least have implicit criteria. In the Unix world > I saw a list categorizing 9 levels of Unix expertise. I never thought I would have a reason to repost this, but I saved it anyway. At any rate, here goes a list of categories for C programmers similar to those originally used for unix types: NAME DESCRIPTION AND FEATURES novice - puts "#include <stdio.h>" in his code, but is not sure why - has heard of pointers, but has never seen one user - uses the following macros: #define BEGIN { #define END ;} - has had a bad experience with pointers - knows the difference between ' and " knowledgeable - uses: user if(a==b) c = 1; else c = 0; - uses pointers, but only in place of arrays - loves writing code on VMS expert - uses: c = (a==b) ? 1 : 0; - uses pointers comfortably - are jazzed when they find a compiler bug because they found it - has figured out what && and || are for - refuses to write C code on VMS hacker - uses: c = a==b; - writes code which use pointers to functions - writes macros instead of simple functions - uses bitwise operators because they are like assembler - writes simple code with "cat >" and compiles it with "!cc". - uses argv and argc guru - avoids bitwise operators due to portability - are annoyed with compiler bugs - writes code portable enough to port from VMS but doesn't relish the thought - writes libraries that his fellow workmates use - can answer most C questions after a little thought wizard - writes compilers with "cat >" (and they work!) - reads device driver source with breakfast - can tell what question you are about to ask, and answer it - is on a first-name basis with Dennis, Bill, and Ken Wade Guthrie evil@arcturus.UUCP Rockwell International Anaheim, CA (Rockwell doesn't necessarily believe / stand by what I'm saying; how could they when *I* don't even know what I'm talking about???)