Wie definiert ihr "Code Monkey"?

[Gast]

Aus einer Diskussion über "Code Monkeys" stellte sich mir die Frage:

Wie definiert ihr "Code Monkey"?

[dust]

So: http://en.wikipedia.org/wiki/Code_monkey ?

[peterchen]

Code Monkey: Wird mit Pizza und Spezifikation gefüttert, gibt Quellcode aus.
Programmierer: Ein aufgepeppter Code Monkey mit Fortschrittsbalken und partieller* Inputvalidierung
Entwickler: Wie Code Monkey, da kann man aber die Spec weglassen.

Spec ja, Pizza nein

[Bashar]

Traurige Gestalten, die Entwurfsdokumente von oben entgegennehmen und in Code umsetzen. Gibts m.E. in halbwegs modernen Entwicklungsprozessen nicht mehr.

[peterchen]

Gibts m.E. in halbwegs modernen Entwicklungsprozessen nicht mehr.

Meinst Du?
Wenn ich mir die "Landschaft" so angucke sieht es eher nach einer "Industrialisierung" der Entwicklung aus - mit vielen traurigen Gestalten, die Specs in Code umsetzen, aber auch nicht viel mehr können - weil es eben nicht genug ausreichend gute Programmierer und Entwickler gibt.

[Bashar]

peterchen schrieb:

Gibts m.E. in halbwegs modernen Entwicklungsprozessen nicht mehr.

Meinst Du?
Wenn ich mir die "Landschaft" so angucke sieht es eher nach einer "Industrialisierung" der Entwicklung aus - mit vielen traurigen Gestalten, die Specs in Code umsetzen, aber auch nicht viel mehr können - weil es eben nicht genug ausreichend gute Programmierer und Entwickler gibt.

Erzähl mal. Ich kann mir das wirklich nicht vorstellen, dass jemand bei den heutigen High-Level-Sprachen tatsächlich so detaillierte Specs schreibt, dass ein Codesklave die ohne weiteres in Code umsetzen kann. Der Abstraktionsunterschied zwischen Spec und Code ist doch um einiges kleiner als vielleicht in den 60er Jahren, als der eine einen Programmablaufplan gemalt und der andere das mühsam in Assembler- oder Fortran-Code umgeschrieben und in Lochkarte gestanzt hat.
Dazu kommen noch Reibungsverluste durch unvollständige oder falsch verstandene Specs. Will man das wirklich noch haben, im Zeitalter von IDEs?

Und dann gibts ja noch die ganzen agilen Prozesse, bei denen so eine Trennung von vornherein ausgeschlossen ist. Auch wenn ich nicht weiß, wie weit verbreitet das ist...

[muemmel]

Hi,

was willste machen, wenste nicht die passenden Leute hast. Backen geht schlecht, also muß man nehmen was man hat. Ist wie mit Nachkriegskochrezepten. Man nehme so man hat. Ausbilden kommt ja nicht in Frage, kostet ja Geld, und die Leute mit zukunftsträchtigen Gehältern locken würde ja auch Geld kosten. Gibt leider immer noch zu viele Chefs, die nur darauf gucken, was die Leute pro Stunde kosten und nicht was sie schaffen. Kann mich da noch an meinen alten Job erinnern, da haben wir mit einer kleinen Firma zusammengearbeitet, deren Chef generell nur Leute nahm, bei denen das Arbeitsamt mindestens 50% des Lohns bezahlt hat. Im Endeffekt wars trotzdem teurer, weil die 5 mal so lange gebraucht haben und das Teil dann zum Schluß noch verknallt haben. Aber Geiz war eben Geil. Leider werden durch solche Kurzblickrechner viele ehrliche unschuldige Arbeitnehmer um ihren Job gebracht.

Darum wird ja auch immer noch für viele Sachen Basic genommen, weil da am schnellsten mal ein Programmierer angelernt ist.
Wenn Du C++ oder Ada programmieren willst ist da nichts mit fix mal 3 Leute mit ner Fettbemme aus dem Urwald locken.

Gruß Mümmel

[peterchen]

Und dann gibts ja noch die ganzen agilen Prozesse...

Dachte mir schon, daß du das mit "modernen Entwicklungsprozessen" meinst

Dafür brauchst du fähige Leute - das ist klar. Ich frage mich aber, für welche Projekte Agile & Co. tatsächlich geeignet ist - nicht aus Entwicklungssicht sondern aus Sicht des Geschäftsmodells. Das ist aber definitiv material für einen anderen Thread.

Erzähl mal.

Wenn ich mir den größten Teil der Fragen auf Messageboards ansehe - Codeproject, CodeGuru, EE und auch hier - ist, positiv formuliert, die Merhzahl noch lange nicht beim "Entwickler" angekommen. Bei cpp.de sehe ich oft zumindest noch Potential, aber sonst - eher ein Heer von Leuten, die man möglichst per Dauermeeting vom Quellcode fernhalten sollte.

Ohne Hochschulausbildung schlechtzumachen liefert selbst die beste Ausbildung keinen ausreichenden Pool an guten Entwicklern. (Wahrscheinlich ist das gar nicht möglich - an Teach Yourself Programming in 10 Years stimmt m.E. zumindest der Titel)

Selbst wenn ein "richtig guter" Entwickler 10x so produktiv sein kann wie einer aus dem "guter Durchschnitt"-Pool: wieviele Firmen werden sich auf Gedeih und Verderb dem einen oder den zweien ausliefern, die sie bekommen können? Industrialisierung heißt: den einzelnen Arbeiter möglichst autauschbar zu machen. Einhundert durchschnittliche Programmierer sind einfacher zu ersetzen als zehn Spitzenentwickler.

Ich denke, Softwareentwicklung wird in der nahen Zukunft erwachsen werden - ähnlich wie die Warenproduktion mit dem Fließband "erwachsen" geworden ist. Das einzige dann im großen Maßstab tragfähige Personalmodell, das ich mir vorstellen kann, lebt von einer Kohorte von Code Monkeys und Halbprogrammierern, die durch Standardwerkzeuge kaum noch in der Lage sind, großen Schaden anzurichten. Auf der anderen Seite werden Designer stehen, die vom hacken und debuggen keine Ahnung haben.

Für den "Entwickler" wie oben definiert wird es noch genügend Nischen geben - wenige, gut bezahlte Stellen für die richtig guten. Das soll auch nicht heißen, daß dann alle Software aus der Fabrik kommt - aber höchstwahrscheinlich die Merhzahl.

Ich hoffe ja, ich irre mich Was meint ihr?

[thordk]

code monkeys sind die nervbolzen, die auf ihrer frickelscheisse bestehen, weil sie angeblich so schön einfach ist, aufgrund dessen jeden tag 500 triviale bugs fixen und sich trotzdem dagegen sträuben, gegen anständige frameworks zu arbeiten, weil sie ihnen viel zu aufwendig sind.

[Bashar]

peterchen schrieb:

Und dann gibts ja noch die ganzen agilen Prozesse...

Dachte mir schon, daß du das mit "modernen Entwicklungsprozessen" meinst

Nicht direkt. Ich kann da aber eigentlich auch nur rumfaseln, weil ich von tatsächlich existierenden nicht-agilen Prozessen nicht viel Ahnung habe. Ich kenn aber den in unserer Firma, der ist halbwegs modern (Betonung auf dem ersten Wort), und hat absolut keinen Raum für Code Monkeys.

Wenn ich mir den größten Teil der Fragen auf Messageboards ansehe - Codeproject, CodeGuru, EE und auch hier - ist, positiv formuliert, die Merhzahl noch lange nicht beim "Entwickler" angekommen. Bei cpp.de sehe ich oft zumindest noch Potential, aber sonst - eher ein Heer von Leuten, die man möglichst per Dauermeeting vom Quellcode fernhalten sollte.

Aber sind das auch Leute, die tatsächlich in Projekte eingebunden sind? Und wenn man sie von Quellcode fernhalten sollte, will man sie ja nicht als Codesklaven haben

Ohne Hochschulausbildung schlechtzumachen liefert selbst die beste Ausbildung keinen ausreichenden Pool an guten Entwicklern. (Wahrscheinlich ist das gar nicht möglich - an Teach Yourself Programming in 10 Years stimmt m.E. zumindest der Titel)

Versteh ich dich richtig, du willst darauf hinaus, dass es nicht genug gute Leute gibt, die Entwickler sein können, deshalb müssen die besseren die Specs schreiben und die schlechteren sie umsetzen? Ich denke das funktioniert nicht, weil eine Spec vollständig und widerspruchsfrei zu schreiben nochmal sehr viel schwerer als normale Softwareentwicklung ist. Wenn man die Spec einmal hat, kann man sie auch gleich selbst umsetzen. Die Werkzeuge sind heute da.

Selbst wenn ein "richtig guter" Entwickler 10x so produktiv sein kann wie einer aus dem "guter Durchschnitt"-Pool: wieviele Firmen werden sich auf Gedeih und Verderb dem einen oder den zweien ausliefern, die sie bekommen können? Industrialisierung heißt: den einzelnen Arbeiter möglichst autauschbar zu machen. Einhundert durchschnittliche Programmierer sind einfacher zu ersetzen als zehn Spitzenentwickler.

Das klingt plausibel (leider ;)), aber bedeutet es, dass die 100 durchschnittlichen Programmierer nur zum Codesklaven taugen? Beruf verfehlt, IMHO.

Ich denke, Softwareentwicklung wird in der nahen Zukunft erwachsen werden - ähnlich wie die Warenproduktion mit dem Fließband "erwachsen" geworden ist. Das einzige dann im großen Maßstab tragfähige Personalmodell, das ich mir vorstellen kann, lebt von einer Kohorte von Code Monkeys und Halbprogrammierern, die durch Standardwerkzeuge kaum noch in der Lage sind, großen Schaden anzurichten. Auf der anderen Seite werden Designer stehen, die vom hacken und debuggen keine Ahnung haben.

Bis Softwareentwicklung "erwachsen" wird, wird es meiner Meinung nach noch eine Weile dauern. Funktionale Programmierung wird gerade mainstreamfähig, parallele Programmierung wird momentan immer wichtiger. Stabil ist da überhaupt nichts. Guck dir die DIN-Normen zur Softwareentwicklung an, da kriegt man Lachkrämpfe. Ich glaub Fachinformatiker müssen sowas lernen.

Übrigens ist effektives Debuggen eine Kunst für sich, die einer wissenschaftlichen Arbeitsweise nicht unähnlich ist.