Jetzt würde mein Prof. kommen und sagen "Also lieber kalyxo, lieber Ronnie, ihr hättet bei mir besser mal aufgepasst! Zwischen Kontrolle und Controlling (Controller) gibt es einen Riesenunterschied!" *g*

Kontrolle ist etwas starres, wo ein einmaliger Punkt abgefragt wird, aber kein Handlungsspielraum für Nachbesserungen bleibt. Starenkasten am Wegesrand. Hier muss der Erwischte nur bezahlen.
Controlling. Eine Kontrolle zu einem Zeitpunkt, wobei das Resultat einen Handlungsspielraum für Nachbesserungen lässt. Die netten Tafel, die anzeigen "Sie fahren xx km/h". Hier wird man nicht gleich bestraft, sondern kann sein Verhalten korrigieren.

Kontrolle ist bei einem freiwilligen Lernen eher hinderlich, da hier zuviel Druck aufgebaut wird. Controlling ist da eindeutig besser, da es bei Fehlern Hinweise auf Änderungen gibt.

Die KUMON-Methode hat hier den Nachteil, dass man nur dann weiterkommt, wenn man ein Aufgabenblatt in einer gewissen Zeit absolut fehlerfrei abgibt. Das führt unweigerlich zu Stress und irgendwann zu Blockadehaltung. Die Schüler bekommen teilweise echte Angstzustände wenn es zur nächsten Prüfung geht.

Ein Controlling würde ich hier für besser erachten: Man wird auf seine Fehler aufmerksam gemacht, muss aber die Aufgaben nicht so lange wiederholen, bis es absolut fehlerfrei ist. In nachfolgenden Aufgaben werden garantiert wieder Teile der vorherigen Aufgaben auftauchen. Allein damit festigt man schon gewisse Dinge!

[quote=renee,11.07.2005, 14:12]@sri: beim letzten Punkt kommt es immer darauf an, wie die Multiple-Choice-Fragen (MCF) aufgebaut sind... Sie dürfen ganz klar nicht das einzige Mittel im Test sein. Aber ein paar solcher Aufgaben sind zum "Auflockern" nicht schlecht. Hier kommt es ein wenig auf gutes Gespür an, ob man zu einem Thema eine gute MCF machen kann oder nicht.
Es ist klar, dass der Unterschied zwischen "richtigen" Programmierern und "guten" Rätsellösern bei MCF nicht so groß sind, aber an ein paar Stellen eingestreut kann man gewisse Bereiche abfragen, die mit einer "offenen" Frage nicht ganz so leicht abzuhandeln wäre!

Ganz ohne Vorgaben würde ich dem Programmierer aber kein Problem lösen lassen. Wie oft kommt es bei Dir vor, dass Dein Chef einfach nur sagt "Schreib mal ein Programm!". Es ist ja wohl eher der Fall, dass Du Vorgaben darüber bekommst, was am Anfang steht und was am Ende rauskommen soll! So etwas nach dem Motto "Wir haben hier ne Webseite und am Ende soll eine Liste rauskommen, in der alle Linktexte und URLs stehen. Mit Tab getrennt damit wir das in das Programm XY einlesen können".
Also ganz ohne Vorgaben geht es nicht. Dann ist es auch nicht wirklich kontrollierbar!  Die Vorgaben dürfen aber auch nicht zu eng sein, weil sonst der "Erfindergeist" nicht in Schwung kommt.
Ich liebe es bei meiner jetzigen Projektleiterin, dass sie mir immer nur sagt was wir haben und was am Ende rauskommen soll, aber der Weg ist mir absolut freigestellt.[/quote]
Desto weniger Vorgaben du dem Programmierer gibst, desto mehr erfaehrst du ueber ihn und seine Arbeitsweise.

Multiple Choice Fragen sind einfach voellig Praxis fremd, haben mit der Arbeit an sich ueberhaupt nichts zutun, doch genau das moechte ich ja wissen, wie gut macht der Programmierer seinen job. ;)

[quote=pfuschi,11.07.2005, 12:41]Servus,
wenn man die Aufgaben entsprechend stellt, müsste es ja möglich sein Lösungsvorschlag mit bereits existierenden Tests zu überprüfen.
So hätte man den Rahmen in der Aufgabe gesteckt und der lernende kann diese Aufgaben "frei" lösen.

Allerdings habe ich kaum Ahnung von Tests weiss also nicht wie diese genau funktionieren.

greetz & fetten Segen
manu[/quote]
Genau sowas meinte ich auch.
Einfach (?) eine Aufgabe stellen und dann das Ergebnis kontrollieren.
Man muss sich ja nicht nur an der Ausgabe orientieren sondern, wie sri auch schon meinte, z.B. auch an der Programmierart.
Diese (Programmierart) kann man dann in Qualität, Geschwindigkeit oder sinnfreiheit :) gruppieren und bewerten.

@sri: deswegen habe ich geschrieben, dass die Vorgaben nicht zu eng sein dürfen... Es geht ja nicht *nur* darum, etwas über die Arbeitsweise des Programmierers zu erfahren, sondern *auch* über das erlernte Wissen. Das Thema hat mit Tutorien zu tun, nicht mit Einstellungstest. Deswegen bin ich der Meinung, dass man durchaus auch MFC einsetzen kann - natürlich relativ wenig und nur in ausgesuchten Themen.

@pktm: Die Programmierart kann man aber nur äußerst aufwändig - wenn überhaupt - automatisch bewerten. Qualität ist immer subjektiv. Für Dich ist Qualität beim Programmieren vielleicht etwas ganz anderes wie für mich! Geschwindigkeit ist nicht immer entscheidend!

[quote=sri,11.07.2005, 13:51]Das ist absoluter humbug, bei derartigen Fragen habe ich schon damals in der Schule schnell das interesse verloren und den Test vergeigt.

Ich (und viele andere Autodidakten) wuerde hier durchfallen...also kann mit dem Test was nicht stimmen.

Ausserdem wird hier getestet was der Pruefling auswendig gelernt hat, nicht aber das wesentliche, seine Arbeitsweise.

Ich verstehe zwar das jemand der kein Programmierer ist Kennzahlen ueber seine Leute haben moechte, diese ueber derartige Tests zu erstellen ist aber schlichtweg schwachsinn.
Ich empfehle immernoch den Alpha geek! :)

Ausserdem sind meist die CPAN Module eines Perl Programmierers (bzw. Beitraege zu CPAN Modulen Dritter) ein guter Anhaltspunkt.
Das sagt viel uber die Faehigkeit im Team zu arbeiten, sich an Standards zu halten, und vor allem Qualitaet aus![/quote]
Die Idee mit CPAN finde ich gut. Allerdings veröffentlichen nicht alle Programmierer ihre Module. Deshalb taugt das nur eingeschränkt. Ich habe mir bei CPAN zum Beispiel schon alle von Renée geposteten Module angesehen. Davon wurde noch keines bewertet.

Wie soll ich jetzt wissen, ob er ein guter oder schlechter Programmierer ist. Und wäre nicht gerade ein solches Urteil unfair?

Mir ist klar, dass Multiple-Choice nichts für Autodidakten ist (siehe mein Blogeintrag). Aber für die brauche ich diese Tests auch nicht. Oder zumindest ist das nicht der Hauptfokus.

[quote=sri,11.07.2005, 14:02]Ganz genau, jeder lernt anders, und genau deshalb ist die einzige Moeglichkeit einen Programmierer zu testen ihm Probleme zu geben die er loesen soll.
Ohne weitere Vorgaben...

Es ist zwar nicht leicht auszuwerten, wird aber schnell die Spreu vom Weizen trennen. ;)

Bei Multiple Choice werden klar die schlechteren Programmierer bevorzugt!!![/quote]
Ich will an dieser Stelle noch einmal betonen, dass es nicht an neuen Lernmaterialien für Perl mangelt. Es mangelt an der Messbarkeit der Lernerfolge. Multiple Choice mag nicht das Optimum sein. Aber es ist leicht zu entwickeln und leicht anzuwenden. Deshalb sollte man damit meines Erachtens einfach mal anfangen.

[quote=Taulmarill,11.07.2005, 14:04]es kann nicht sein, dass man ein zertifikat als programmierer aufgrund eines multiple-choice testes bekommt. solche tests können einfach qualitäten wie kreativität nur eingeschränkt messen. und m.E. ist kreativität eine der wichtigsten eigenschaften, die einen mässigen von einem wirklich guten programmierer unterscheidet.[/quote]
Zu den Depressionen von Japanern kann ich wenig sagen. :-) Allerdings glaube ich nicht, das die Perl-Programmierer, die wohlgemerkt freiwillig an solchen Tests teilnehmen würden, dadurch depressiv würden. :)

Zum Zitierten Teil: Ich wiederhole mich: Multiple-Choice (oder eingabe von Zahlen etc.) ist nicht das beste und kann sicher keine Kreativität messen.

Aber wie sollen die ergänzenden Tests für Kreativität aussehen.

[quote=kalyxo,11.07.2005, 16:53]Die Idee mit CPAN finde ich gut. Allerdings veröffentlichen nicht alle Programmierer ihre Module. Deshalb taugt das nur eingeschränkt. Ich habe mir bei CPAN zum Beispiel schon alle von Renée geposteten Module angesehen. Davon wurde noch keines bewertet.

Wie soll ich jetzt wissen, ob er ein guter oder schlechter Programmierer ist. Und wäre nicht gerade ein solches Urteil unfair?

Mir ist klar, dass Multiple-Choice nichts für Autodidakten ist (siehe mein Blogeintrag). Aber für die brauche ich diese Tests auch nicht. Oder zumindest ist das nicht der Hauptfokus.[/quote]
Ab einem gewissen Stadium haben so ziemlich alle Perl Programmierer Module im CPAN. (Oder wenigstens zu welchen beigetragen)

Du hast doch 20 Perl Programmierer, die sollten das doch fuer dich bewerten koennen.

In deinen anderen Beitraegen hast du die Zielgruppe nicht eingegrenzt, deshalb ging ich immer von der Allgemeinheit aus.
Also willst du Autodidakten vorher aussortieren?

Mal von MCF ausgehend: Das ganze als nette Webapplikation. Eine Datenbank, die Fragen und Antworten verwaltet und die Prüfungen der User, so dass man einen Fortschritt anhand der jeweiligen Prüfungsergebnisse feststellen bzw. auswerten kann. Die Fragen sind dann kategorisiert und bei Schwierigkeiten in bestimmten Bereichen wird auf das entsprechende Tutorial-Material vewiesen?!

[quote=kalyxo,11.07.2005, 16:55][quote=sri,11.07.2005, 14:02]Ganz genau, jeder lernt anders, und genau deshalb ist die einzige Moeglichkeit einen Programmierer zu testen ihm Probleme zu geben die er loesen soll.
Ohne weitere Vorgaben...

Es ist zwar nicht leicht auszuwerten, wird aber schnell die Spreu vom Weizen trennen. ;)

Bei Multiple Choice werden klar die schlechteren Programmierer bevorzugt!!![/quote]
Ich will an dieser Stelle noch einmal betonen, dass es nicht an neuen Lernmaterialien für Perl mangelt. Es mangelt an der Messbarkeit der Lernerfolge. Multiple Choice mag nicht das Optimum sein. Aber es ist leicht zu entwickeln und leicht anzuwenden. Deshalb sollte man damit meines Erachtens einfach mal anfangen.[/quote]
Fuer dich als Nicht-Programmierer sind Lernerfolge schwer nachzuvollziehen.
Aber hast du schon dran gedacht deine Programmierer sich gegenseitig bewerten zu lassen? :)