Can you be a good programmer?

Just found this, as a perpetual novice, I thought it might be useful to post it here

formatting link

martin

Reply to
martin griffith
Loading thread data ...

Interesting concept.

Although the questions may appear simplisitc, they have the same tricks we used to use to determine aptitude for the mathematics necessary to do fundamental engineering. Note I said aptitude - although that's a good guide, it's not infallible :)

Don't think it's really new, to be honest, although it may be a new concept to publish it as a standardised method for aptitude testing.

As long as some PHB doesn't see it and consider it a silver bullet, it seems a useful tool.

Cheers

PeteS

Reply to
PeteS

Claim: "This test predicts ability to program with very high accuracy..." Abstract says: "The initial study suggests that success in the first stage of an introductory programming course is predictable..."

Which is it, a fact or a suggestion? Inquiring minds want to know.

BBB

Regards, Ken

Reply to
Ken Asbury

Hello Martin,

Oh well, one can try to formalize everything, maybe even throw in another psychological test or whetever.

I haven't programmed much in my life but have worked closely with programmers, and have designed a whole lot of electronics including designs around uCs. I don't find the worlds of programming and circuit design to be much different. It all boils down to planning: Those who are organized and able to do a clean top down planning process generally produce great results. Those who immediately start to hack away or flick on the solder iron before turning on the brains usually produce mediocre, poor or sometimes outright dangerous solutions.

Blew my mind but this is a true story: Checked the C program of a hotshot firmware guy (who habored the opinion that reading data sheets is something the HW guys ought to do). Somehow the micro locked up on occasion and everyone thought it had to be EMI or some other HW glitch. He was not enthused at all that a lowly HW guy pored over "his" code. Tapped him on the shoulder:

"Hey, you are adding these five values and then load the PWM with it. The timer ain't got no 17 bits."

"Aw,... s..t!"

--
Regards, Joerg

http://www.analogconsultants.com
Reply to
Joerg

The test measures whether you know how assignment statements work in a C-like language; nothing more.

That is arbitrary knowledge. Why penalize people who don't know that "=" means something different on the test than in all the mathematics classes they've ever attended?

Reply to
mc

I always find test like this to be insanely dull and pointless. I like to deliberately get the worst possible score just to give the testers something talk about.

Reply to
Rob Horton

Here's one other thought.

The test basically measures whether you know how variables work in a typical procedural programming language. If you don't, you'll get a low score regardless of how intelligent you are.

I like to take people who have been trained in such a language, and teach them a bit of Lisp. In Lisp, the value of a variable can be the name of another variable, whose value can still be retrieved.

Suppose A = 2, B = the expression A, and C = the expression B. Then:

value of C is B value of value of C is A value of value of value of C is 2

I suspect anybody who can keep up with this would do badly on the originally proposed test, and vice versa.

Reply to
mc

Yeah thats 100% true, just another way to give something to talk about;-)

ali

Reply to
Ali

I don't think you read the whole thing. What they showed is that, in the initial administration of the test, individuals either picked a mental model of what was happening in the programming language -- whether correct or not -- and applied it consistently from question to question throughout the test or they did not. Those who applied a model consistently in the initial test were the group shown most likely to be successful in the programming course. They didn't say whether those people picked correct answers (or models) in the initial test or not.

(The other groups were those who (a) chose different models for different problems, and (b) those who refused to attempt to answer the questions.)

GH

Reply to
gil_hamilton

Ah! Indeed I didn't. Thanks for the clarification.

I've certainly noticed, as a teacher, that it's much easier to correct a mistaken mental model than to deal with someone who has no mental model and who thinks mathematical questions are answered by guesswork. "I don't get it" is what they say, but often, it's because they don't realize there is anything to be gotten. To them, the way the rest of us work is utter mystery, like clairvoyance or telepathy.

Reply to
mc

Had I not known programming, I would have assumed a = b; was a true or false statement. As in does a = b ? Am I a bad programmer :(

a = 10; b = 20;

a = b;

gil snipped-for-privacy@hotmail.com wrote:

Reply to
vorange

In Pascal, a=b is a true or false statement (as are a=10 and b=10). Assignment is written like a:=10

So it is testing whether you are a C programmer or a Pascal programmer.

And the test also asks what other values a and b have. Or at least that is implied, to me, by the phrase 'Any other values for a and b:' which is unclear as to what is being requested. (All different values for each of a or b, or all different combinations of values that a and b simultaneously have.)

This is testing whether you know what compiler and optimization levels the code is executed under. A modern compiler will optimize this to a=10; or perhaps even optimize away the whole thing, if a isn't used.

So it's a test of whether you are willing to put up with morons. According to the paper:

So 30 students passed the test, and show an aptitude for self-employment.

--
David M. Palmer  dmpalmer@email.com (formerly @clark.net, @ematic.com)
Reply to
David M. Palmer

Stuff like this would qualify you as an excellent politician. Especially if you can convince voters that you can make a always equal b no matter how dire the budget is and without raising their taxes :-)))

--
Regards, Joerg

http://www.analogconsultants.com
Reply to
Joerg

I'm reminded of a 'proof' I'd always pull out when I got a question wrong studying A-level mathematics. Given a and b, multiply both by 0:

a * 0 = 0 b * 0 = 0

Two quantities that equal the same equal each other so:

a * 0 = b * 0

Simply by dividing by 0:

a = b

It's not entirely silly - it shows up a limitation of maths and as such it's a worthwhile demonstration if I suspect someone is trusting mathematics a little _too_ much.

--
Andrew Smallshaw
andrews@sdf.lonestar.org
Reply to
Andrew Smallshaw

There is a fancier version where you start with a=b and after a while divide something else by (a-b) and end up proving that 1=2.

Reply to
mc

This is good.

Equations transformation rule explicitely says "multiply by non-zero number".

Division by zero is explicitely forbidden operation

It does not show anything except that you forgot the algebra classes already :(

Reply to
Arcady

He hasn't forgotten anything. He's trying to show that you can get people to believe a completely illogical "proof."

Reply to
mc

Yes, and also not to have absolute faith in something because it has been 'proven'. I recall a book from University dealing with formal proofs by induction. It gave a computer program to find the largest value in a list along the lines of:

let a = 0 for each list[i] if list[i] > a let a = list[i] return a

It then gave a formal inductive proof that this program worked. It has been mathematically proven, so it must be true, right? Well, I checked the original specification given in the textbook and no. There is no mention that the list is composed of positive values, so an entirely negative list is acceptable input. IOW, the bug was duplicated in both the code and 'proof' because both relied on the same implicit assumption.

--
Andrew Smallshaw
andrews@sdf.lonestar.org
Reply to
Andrew Smallshaw

I have some statistics for some IEC61508 projects (it was in an IEE journal last year) that said the majority of the "bugs" came from the specifications not the implementation. I think 47 % to 14%

I also believe that Intel on one of their chips fell foul of the same problem above. The whole lot was done on formal methods but there was a flaw in the initial specifications. The chip worked to the specifications but "put negative numbers in" and it did not work.

Does the proof match the spec and is the spec accurate and bomb proof?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply to
Chris Hills

And the most important point: Is the problem being solved the one you or the customer wants solved?

Reply to
Everett M. Greene

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.