Programmieren in Gruppe gemeinsam lernen

[Tumbleweed]

An dem was klomann83 gesagt hat ist schon viel Wahres dran. Es gibt unheimlich viele minderwertige Quellen (auch anscheinend professionelle, wie Bücher von Professoren). Daher muss man bei der Auswahl wirklich kritisch sein, was ein Anfänger (und selbst einige Fortgeschrittene) natürlich nicht kann. Wie oft liest man hier die Galileo Openbooks als Empfehlung für Anfänger. Schlechte Empfehlung, wenn du mich fragst. Ich könnte aber auch kaum eine bessere geben, weil ich anders gelernt habe.
Grundlagen sollte man sich "live" von Leuten beibringen lassen. Ist natürlich schwierig dafür jemanden zu finden. Wenn man es ernst meint, wäre ein Seminar vielleicht eine Option. Die Kosten dafür sollte man sich dann schon ans Bein binden. Auch hier kannst du natürlich an Stümper und/oder Didaktik-Krüppel geraten...

Gibt auch Leute, die prima von 0 aus Büchern lernen können. Konnte ich zum Beispiel anfangs nicht, aber nach ein paar Jahren Umgang mit Softwareentwicklung kann ich inzwischen auch schon ganz gut nach dem von ice-breaker beschriebenen Weg lernen.

 

[ice-breaker]

aber nach ein paar Jahren Umgang mit Softwareentwicklung kann ich inzwischen auch schon ganz gut nach dem von ice-breaker beschriebenen Weg lernen.

wobei ich da noch ergänzen muss, man nimmt eben wie du auch so schön sagst extrem viele falsche Infos auf. In dieser anfänglichen Lernphase muss man also mental offen sein, auch 2 Wochen später das gelernte zu revidieren, aber vor allem auf Basis von eigener Erfahrung bewerten wie kompetent der Autor ist und da hapert es, wie du es so schön sagst, bei einem Anfänger wirklich dran, da er es nicht besser wissen kann.

 

[Funart]

(Ich beantwortet den Anfangs Post nicht die ganze wissenschaftliche zerlegung vom Rest.)

Hab unter anderem letztes Jahr eine Theoretische Arbeit darüber geschrieben zu einer case study mit der Frage wie sich Pair Programming für Programmieranfänger beim erlernen einer Programmiersprache auswirkt. Kenne auch viele Leute die Probleme beim erlenen von Programmiersprachen haben unabhängig von Dingen wie Performance und Architekturellen Dingen. (Davon ist man zu dem Zeitpunkt sowieso sehr weit entfernt).

Im Allgemeinen bin ich davon überzeugt dass es Programmieranfänger sehr stark hilft wenn sie zusammenarbeiten. Der Grund dafür ist dass diese oft an kleinigkeiten hängen bleiben und ein versuchen ein Problem mittels eine Bruteforce attacke zu lösen und dabei immer mehr Frustration aufbauen. Es ist allerdings wichtig sich nicht von einem bereits guten Programmierer fertige Lösungen geben zu lassen. Es muss eher dahingehend ausgerichtet sein dafür zu sorgen, dass der Anfänger nicht bei einfachen Fehlern stundenlang verharrt weil er den Wald vor lauter Bäumen nicht mehr sieht.
Ich bin auch davon überzeugt, dass es sinnvoll ist einen Anfänger einen naiven Sortieralgorithmus programmieren zu lassen. Das hat nichts damit zu tun guter Programmierstil zu sein, sondern eher damit es jede Programmiert Logikzeile denjenigen weiter bringt. Wenn jetzt ein erfahrerner Programmier kommt mit Programmier doch den oder den Sortieralgorithmus oder dies oder das, ist niemanden geholfen. Damit ist der Anfänger in der Regel einfach nur noch mehr überfordert und hat dann einfach irgendwann keine Lust mehr.

 

[Daaron]

Das Rad jedes Mal neu zu erfinden bringts aber auch nicht.

 

[maxwell-cs]

Ich gehe mal davon aus, dass du dich auf die Sortieralgorithmen beziehst:

Der Sinn von solchen algorithmischen Programmieraufgaben soll eben genau das üben: Logik und Algorithmik. Das Ziel ist ja nicht, nachher eine 1231231. Implementierung von Mergesort zu haben (die ja eh niemand benutzen wird), sondern der Weg dahin.

 

[ice-breaker]

Und wer von denen, der einen Sortieralgorithmus "erfindet" wird auf eine Idee wie Mergesort oder Quicksort kommen? Vermutlich wird da eher ein Gnomesort oder Bubblesort rauskommen. Und um zu erkennen, dass diese beiden Algorithmen verbessert werden können und die vorigen wirklich besser sind, müssen sie die Laufzeitkomplexität bestimmen können.
Und wer kann das, der das nicht irgendwo gelernt hat und das dann gleichzeitig auch mit vielen lange bekannten Algorithmen hatte?

Klar ist es sinnvoll das mal selbst implementiert zu haben. Aber zu argumentieren, dass dieser sich dann auf einen Mergesort/Quicksort verbessern soll ist einfach unrealistisch.

 

[maxwell-cs]

Aus Pseudocode oder auch einer guten schriftlichen Erklärung eine laufende Mergesort-Implementierung basteln ist doch nicht wirklich kompliziert, finde ich zumindest.

Eine Programmieraufgabe wäre ja auch "Implementiere MergeSort" und nicht "Erfinde einen Sortieralgorithmus und implementiere ihn".

 

[Daaron]

Ich hab schon viel Laien-Code gesehen, der halt irgendwie gemacht hat, was er soll. Davon war aber nie etwas auch nur auf dem Niveau von Bubblesort.... Am Ende schustert der Laie ein Naive Sort zusammen und freut sich, weil es funktioniert.

 

[Simple Man]

Es geht hier nicht wie gut jemand lernt, sondern wie er lernt bzw. eine der 3 vorgegebenen Methoden nutzen würde.

 

[Keepers]

Ehrlich gesagt haben alle diese Themen deutliches "Tutorial-Niveau". Ist das extra so gedacht oder Zufall?
Da würde es mich nicht wundern, wenn die meisten nur aus Tutorials "abschreiben" und dabei das eine oder andere lernen. Die Grundlagen fehlen dabei aber komplett.
Und das wir einem denn klar, wenn man sieht, dass es Bücher gibt, die nur korrektes Multithreading behandeln (Java Concurrency in Practise) weil eben deutlich mehr dahintersteckt und die ersten Erfolge einen fälschlicherweise glauben lassen, dass man es kann. Es aber viel viel viel viel komplexer ist (Java Memory Visiblity Model).

Die Frage ist ja auch auf welches Niveau das Lernen hinaussoll. Jemand der sich ein so komplexes Thema wie Multithreading durch Tutorials beibringen will, kann man nicht ernst nehmen. Der Zugriff auf Datenbanken hingegen schon, das sind nur eine Hand voll Zeilen Code.

Ack.
Und dazu möchte ich noch ergänzen, dass die Programmiersprache und das Framework am Ende nur die Umsetzungsmittel sind. Nicht umsonst geschieht die Festlegung auf diese Werkzeuge erst zu sehr späten Zeiten in einem Projekt. Jeder, der hier etwas anderes behauptet, hat von Software Engineering nicht den Hauch einer Ahnung, hat Requirement Engineering, Analyse und Design einfach nicht verstanden.

So oder so ist das ständige "hinterherrennen" nach neuen Technologien, Frameworks und Sprachen heutzutage, in meinen Augen, absoluter Blödsinn. Die Neuerfindung des Rads, und oftmals kein besseres!, geschieht hier täglich.

Sancha, Jquery, Actionscript, Scala, Go und so weiter... wann will man denn das alles "können" und wofür? Damit beschäftigt man sich, wenn es relevant wird. Darüber lesen, Vor- und Nachteile durch vernünftige Artikel (und keinen ct' Eintrag "Go - das neue C") herausrarbeiten, um sie im Entscheidungsprozess zu berücksichtigen, gehört dazu. Aber doch auch nicht für jeden Furz.. Sich einzuarbeiten in ein neues Werkzeug gelingt denjenigen, die die Konzepte und Hintergründe verstehen, innerhalb kurzer Zeit. Und dann stellt sich die Frage, ob man nicht doch lieber bei dem bleibt, was die Entwicklungsabteilung beherrscht. Und egal wofür man sich dann entscheidet - wer die Augen verschließt, keine Code Reviews einplant, oder gar meint nur weil mans seit 10 Jahren so macht ist es gut so..

Ob man als Programmierer was taugt, hat meiner Meinung nach herzlich wenig damit zu tun, ob man die Sache studiert hat oder nicht.

Da gebe ich dir recht - macht auch preislich etwas aus. Aber ein guter Programmier ist noch lange kein Software Ingenieur, und nicht jeder Software Ingenieur kann die Umsetzung so schnell wie einer seiner Entwickler. Ist auch nicht die Aufgabe des anderen. Wer aber hier immer glaubt, in großen Projekten (und damit sind mal Entwicklungszeiten von 2-3 Jahren, 10 Jahre Wartungsvertrag, Skalierbarkeit, Modularisierung und mehr als nur 10 Jobs) sind die Programmierer diejenigen, die dafür Sorgen, dass das Ziel erreicht hat.. sorry Jungs kommt in der Realität an. Ich glaube aber.. ich schweife zu weit aus ;-)

 

[Daaron]

Nö, soweit schweifst du gar nicht.
Selbst bei kleinen Projekten, z.B. einer kleinen auf einen Kunden angepassten Extension für ein CMS, die ein Entwickler allein stemmt, kommt erst einmal n paar Tage lang nur Brainstorming und ein Plan, was wann wie passiert. Danach wird angefangen der ganze Kram soweit runter zu tippen.

Und wenigstens haben jQuery und Actionscript jeweils eine echte Daseinsberechtigung. Ohne AS keine Flash-Apps und ohne Frameworks wie jQuery oder Mootools würde man an einem kleinen Slider 2 Tage rumschreiben statt 2 Minuten. Das kann man von den ganzen "wir machen jetzt alles anders als bisher" - Programmiersprachen, die alteingesessene Sprachen nur ersetzen wollen ohne was wirklich neues zu können, nicht gerade behaupten.

 

[Keepers]

Und wenigstens haben jQuery und Actionscript jeweils eine echte Daseinsberechtigung. Ohne AS keine Flash-Apps und ohne Frameworks wie jQuery oder Mootools würde man an einem kleinen Slider 2 Tage rumschreiben statt 2 Minuten. Das kann man von den ganzen "wir machen jetzt alles anders als bisher" - Programmiersprachen, die alteingesessene Sprachen nur ersetzen wollen ohne was wirklich neues zu können, nicht gerade behaupten.

Sicherlich - aber deshalb im Vorfeld sich damit beschäftigen, ohne tatsächliche Relevanz?

Sich die Birne zuknallen mit Dingen, die man nicht brauch, hat noch bei keinem geholfen. Ich denke, den meisten wird es zeitlich auch nicht besser gehen wenn sie voll im Berufsleben stehen.

 

[Ruheliebhaber]

Sancha, Jquery, Actionscript, Scala, Go und so weiter... wann will man denn das alles "können" und wofür?

Das erlebe ich auch, daß sinnlos Technologien bzw. Sprachen in Projekte gebracht werden. Hier ein bißchen Razor, dort noch mal eine XSL-Transformation, dann gibt es noch ein bißchen MEF, etc., pp.; Bin eher Microsoft-lastig geprägt.

Richtig schlimm wird es dann, wenn man den Kram nicht mehr richtig debuggen kann. Wenn man das Projekt von einem anderen Entwickler übernimmt und nicht weiß, wie die Module gekoppelt sind, dann kann man diese ganze neue, bunte Codewelt in die Tonne treten.

Viel wichtiger ist es meiner Meinung nach, das Entwicklerteam auf einen annähernd gleichen Techlevel zu bringen, damit man als Unternehmen schlagkräftig ist. Das soll nicht heißen, daß es keinen Platz für individuelle Interessen und Stärken gibt. Wenn ich aber nur Experten im Team habe und disjunkte Aufgaben verteile, fahre ich als Projektleiter ein großes Risiko, wenn mal jemand ausfällt.

Insofern vermisse ich das Bewußtsein in Unternehmen, daß sinnvolle, flächendeckende Weiterbildung der Mitarbeiter ein strategisches Ziel ist, welches den Unternehmenserfolg garantiert.

Aus Kundensicht zählt nur der Preis und weniger die Technologie dahinter. Dann lieber nur 6 Monate bezahlen für eine Entwicklung in einer ausgereiften Technologie auf einem mäßigen Techlevel als 12 Monate inklusive Lernkurve des Entwicklerteams auf dem aktuellsten Techlevel.

 

[Keepers]

Ganz oft gesehen:

"Das mache ich in Perl und rufe das dann von Java auf und dann parse ich alles hin und her"

Wenn man ein fertiges Perl Skript für ein Problem hat, und der Zeitverzug (high priority bug fix) es nicht zulässt zu portieren, kann man das als workaround stehen lassen. Ich habe aber schon oft gesehen, dass das Problem von Anfang an in Perl gelöst wurde, statt direkt in der festgelegten Sprache.

 

[Ruheliebhaber]

Dumm wenn dann der alte Entwickler, der Perl und Java konnte kündigt und der neue nur Java beherrscht. Das ist dann Spaß.

 

[Keepers]

Dumm wenn dann der alte Entwickler, der Perl und Java konnte kündigt und der neue nur Java beherrscht. Das ist dann Spaß.

Ach quatsch.. Perl macht doch immer irgendwas, egal was für eine art $_123?!" man hinschreibt

 

[Ruheliebhaber]

Ich schreibe gerade ein Modul für eine WPF-Anwendung, in welcher Funktionalität mittels MEF lose gekoppelt ist und versuche einen Parser eines anderen Entwicklers für eine selbstentwickelte Sprache zu verstehen.

So kann man sich auch beschäftigen.

Oder anders gesagt, die Motivation ist gerade im Keller.

 

[Fonce]

Ganz oft gesehen:

"Das mache ich in Perl und rufe das dann von Java auf und dann parse ich alles hin und her"

Wenn man ein fertiges Perl Skript für ein Problem hat, und der Zeitverzug (high priority bug fix) es nicht zulässt zu portieren, kann man das als workaround stehen lassen. Ich habe aber schon oft gesehen, dass das Problem von Anfang an in Perl gelöst wurde, statt direkt in der festgelegten Sprache.

Wenn man sowas machen will sollte man natürlich schon abwägen ob es einem eine Zeitersparnis bringt oder nicht(Fehlerfall mit eingerechnet).
Und Perl ist ja erstmal keine komplizierte Sprache. Ich würde eher sagen sie ist sehr weit davon entfernt.

Überflüssige Sprachen? Nö, würde ich so nicht sagen, den eigentlich hat jede Sprache Vor- und Nachteile welche sie für bestimmte Aufgabe gut oder schlecht macht.
Und nur weil es diese Sprache gibt, braucht man sie ja auch nicht alle können.(Dummerweise scheint das aber bei einigen Leuten nicht angekommen zu sein wenn man sich manche Stellenausschreibungen durchliest. Hab mal eine mit 20 Sprachen gesehen )

 

[Ruheliebhaber]

Vielleicht hatte diese Firma eine Softwarelandschaft, wo über die Jahre so viele Sprachen verwendet wurden und brauchte nun einen Experten, der dieses "Monster" beherrschen kann. So oder so, sollte man sich auf einige wenige Kerntechnologien einigen. Wildwuchs ist meistens kein Projektrisiko. Wenn man aber Produkte über Jahre pflegen muß, rächt es sich, wenn man in einer Software x Technologien gekoppelt hat.

 

[Daaron]

(Dummerweise scheint das aber bei einigen Leuten nicht angekommen zu sein wenn man sich manche Stellenausschreibungen durchliest. Hab mal eine mit 20 Sprachen gesehen )

Im Bereich Content Management Systeme is das genauso. Da steht dann gern mal, dass du meisterhaft sein sollst im Umgang mit WP, Drupal, TYPO3 und Joomla. Dazu sollst du noch locker flockig in der Lage sein, selbständig Addons für Magento und 2-3 andere Shops aus dem Ärmel zu schütteln.