Massive Produktivitätsunterschiede bei Programmierern /Ersteindrücke aus meinem Studium
-
Ich beginne gerade mein Informatikstudium. Letzte Woche fanden Vorkurse zum Thema Java-Programmierung statt. Es gab drei Kursarten, Java für Anfänger, Fortgeschrittene/Umsteiger und Profis. Von ~220 Informatik-Erstsemestlern hatten sich knapp 20 für den Java für Profis Kurs angemeldet.
Auch ich war in diesem Kurs. Nach dem wir am ersten Tag erstmal eine Stunde verquatscht hatten, über das was uns im Studium erwartet, gab es eine zweistündige, gute, Einführung in Solaris. Zum Schluss des Tages haben wir noch ein nettes mathematisches Rätsel (dass mit den zwei Mathematiker, der eine Kennt nur die Summe, der Andere nur das Produkt aus zwei Zahlen) mithilfe von Java gelöst.
Am zweiten Tag ging es dann mit der eigentlichen Aufgabe los. Wir sollten (nur) die KI für ein Damespiel (10*10 Felder) programmieren. Dazu hatten wir auch noch die nächsten beiden Tage Zeit, also insgesamt 3*4 = 12 Stunden. Diese Aufgabe konnten wir alleine oder in kleinen Gruppen lösen. Insgesamt gab es neun Teams bestehend aus ein bis vier Leuten.
Und nun komme ich zu dem Punkt der mich erstaunt, aber gleichzeitig auch erschreckt hat. Wie unterschiedlich und zum teil extrem schlecht sich diese Teams, bestehend aus nach eigener Ansicht „Java-Profis“, sich bei dieser nicht übermäßig schweren Aufgabe zum teil angestellt haben. Von den neuen Teams haben nach drei Tagen nur fünf eine lauffähige KI auf die Beine gestellt, und das obwohl der Dozent während der ganzen Zeit Hilfestellungen gegeben hat.
Von diesen fünf Teams hat die KI des größten Teams, bestehend aus vier Mädchen (fünf waren insgesamt im Kurs was ich persönlich für Informatik wirklich viel finde), nicht einmal die Trainings-Ki geschlagen. Das ist insofern erstaunlich, als das die Trainings-KI einfach nur zufällig Steine setzt.
Der vierte Preis ging an mich. Der dritte Preis ging an ein zweier Teams, Freund + Freundin, wobei der Junge die ganze Zeit programmiert und das Mädchen die ganze Zeit daneben gesessen und kein Piep gesagt hat. Abgegeben wurde der Code bereits nach der Hälfte der zur Verfügung stehenden Zeit, also anderthalb Tagen. Den Vogel im Schnell-Programmieren schoss aber der zweite Preis ab, ein „echtes“ Zweier-Team. Bereits nach 30 Minuten! hatten sie eine erste KI-Version fertig die in der Lage war die Trainings-Ki Problemlos zu schlagen. Eine Tatsache die die Mehrzahl der Teams nach 12 Stunden nicht erreicht hatten. Zwei weitere Stunden später gaben sie ihre finale Version ab.
Der erste Pries ging ganz klar einen Studenten der ein Doppelstudium Mathematik-Informatik beginnt. Der einzige der eine „Lernende-KI“ realisiert hatte. Freakig-witzig fand ich wie dieser Student, der noch nicht mal mit seinem Studium begonnen hat, eine halbe Stunde versucht hat dem Dozenten zu erklären was „Binär-Relationen“? sind und wozu er selbst erstellte „Pointer“????? verwendet.
Ws mich besonders interessierten würde: Ob es später im Berufleben auch noch solch enorme Produktivitätsunterschiede zwischen Programmierern gibt und ob es eine Tendenz gibt was meist aus solchen Geeks wie dem Doppelstudenten später wird? Beruflicher Überflieger, Professor oder doch er zielloser Langzeitstudent?
-
Stu1 schrieb:
Ob es später im Berufleben auch noch solch enorme Produktivitätsunterschiede zwischen Programmierern gibt
Ja, gibt es. Ein Faktor 10 ist durchaus anzutreffen. Wobei man auch hier differenzieren muß, einige Leute programmieren rasend schnell, aber fallen in der Produktivität bei Fehlersuchen oder bei der Wartung - also späteren Einpflege von Funktionen - dann stark ab.
Stu1 schrieb:
ob es eine Tendenz gibt was meist aus solchen Geeks wie dem Doppelstudenten später wird? Beruflicher Überflieger, Professor oder doch er zielloser Langzeitstudent?
Ich denke, daß die Geeks seltener in Firmen landen, da dort a) Überflieger nicht wirklich gut ins Team passen [japanisches Sprichwort: herausstehende Grashalme schneidet man ab] und b) oftmals auch nicht so sozial-verträglich sind. Nach einigen Jahren Rückblick habe ich fast das Gefühl, daß diese Leute von der Tendenz her eher als selbständiger Entwickler oder im Bereich technischem Consulting landen. Im fest angestellten Programmiererteam findet man diese Leute selten.
-
Marc++us schrieb:
[japanisches Sprichwort: herausstehende Grashalme schneidet man ab]
Das gefällt mir
Zu dem Posting:
1. Logisch gibt es riesige Unterschiede. Das ist so offensichtlich, dass ich deine Frage sogar etwas naiv finde.
-
@Marc++us: Ich kann Deinem Posting nur zustimmen... (überlege mir schon lange ob ich mich selbstständig machen soll
)PS: Es gibt nur wenige MVPs die *nicht* Selbstständig sind...
-
Jochen Kalmbach schrieb:
@Marc++us: Ich kann Deinem Posting nur zustimmen... (überlege mir schon lange ob ich mich selbstständig machen soll
)Wieso? Bist nicht sozialverträglich?
-
Mein ihr nicht, dass es oft besser wäre, wenn einer sich eine Lösung ausdenkt. Wenn das ein Team macht, dann gibts viel bla bla, weil jeder Irgendwas einbringen will, aber das ganze wird irgendwie nicht so genau durchdacht, wie wenn man sich auf eine Lösung konzentriert..
-
seh ich anders
in teams laeuft das ja immer so das jeder teilaufgaben bekommt - also der macht diese funktion der die andere usw
wenn dann zwei oder mehr an einer funktion schreiben - ist dann ein "hauptaktuer" der faengt etwas an, dann werden meinungen ausgetauscht ob diese oder eine andere methode nicht doch effizienter ist - am ende kommt dann eine funktion raus wo wirklich von allen seiten betrachtet wurde das alles optimal ist
"viele koeche verderben den brei" ist bei der softwareentwicklung einfach nicht - der eine kommt evtl auf eine idee die man selber nicht gekommen waere - und dann benutzt man das bessere
am ende kommt das gleiche raus, aber aus teams kommen effizientere sicherere und optimalerer code
aber ist selten das mehere an einer funktion schreiben - das wird aufgeteilt und feddich - schon ist es ein team project wo aber jeder sein bereich fuer sich hat
-
Theorie schrieb:
Mein ihr nicht, dass es oft besser wäre, wenn einer sich eine Lösung ausdenkt. Wenn das ein Team macht, dann gibts viel bla bla,
Das kann man nicht pauschalieren. Ab einer gewissen Komplexität nimmt die Wahrscheinlichkeit zu, daß eine Einzelperson gewisse Tücken des Problems übersieht. Auch wird die Wahrscheinlichkeit, daß der eingeschlagene Weg grundfalsch ist, minimiert, da er bereits zu Beginn mehrfach geprüft und diskutiert wird.
Es ist allerdings auch richtig, daß Teams Zeit kosten, wenn zu viel über Implementierungsdetails diskutiert wird. Das ist eine Gratwanderung, bis zu einem gewissen Punkt der Planung sehe ich Teams (und die damit verbundenen Diskussionen) als schlagkräftiger an, aber danach nimmt dies auch wieder ab. In der Fehlersuche sind allerdings Zweierteams auch deutlich stärker als Einzelpersonen.
Wobei ich hier von ganz normalen Otto-Normalprogrammierern ausgehe, Genies schlagen die Teams fast immmer, aber woher soll man die nehmen? Die gibt's ja nicht im Regal.
-
Ich hab das so ein Kollege: Wenn Du mit dem anfängst ein Problem zu diskutieren, dann kannst Du den Rest des Tages vergessen und bist aber abends auch nicht schlauer...
-
Jochen Kalmbach schrieb:
(überlege mir schon lange ob ich mich selbstständig machen soll
)mach' ne kostenpflichtige hotline auf, für leute mit winapi- und .NET -problemen.
-
What do you think makes some programmers 10 or 100 times more productive than others?
Steve Yegge:
I think if you pause to consider why not all atheletes are equally good, you’ll have your answer(s). Thomas Edison has a relevant quote about genius that might also provide you some clues.
Linus Torvalds:
I really have no idea. I think some people are just better able to concentrate on the things that matter, and I think a lot of it is just doing it. Most of the really good programmers I know started doing it fairly young.
David Heinemeier Hansson:
The ability to restate hard problems as easy ones.
Peter Norvig:
The ability to fit the whole problem into their heads at one time.
Dave Thomas:
They care about what they do.
Guido Van Rossum:
Genetic differet brain structure.
James Gosling:
They think about what they do. They don’t rush in and slap things together. They have a holistic picture of what is to be built.
Bjarne Stroustrup:
First a general lack of professionalism and adequate training. that sets the base level too low. Secondly, some people have a combination of „smarts” (ability to think clearly and get to the heart of things), experience, and knowledge of tools. Programming leaves more scope for that because it is a combination of theory and practice - neither of which is much use without domain knowledge.
Tim Bray:
The surprising variability of the human mind.
-
Es heisst auch offiziell, das es bei professionellen Programmierern Unterschiede bis Faktor 10 gibt und dem ist auch so.
Es kommt meiner Meinung nach auf zwei Dinge an:
1. Erfahrung
Wenn man nicht weiß wie, kann man auch keine Probleme lösen bzw nur mit fehleranfälligen und einfach schlechten Workarrounds.
Erfahrung durch Praxis und Theorie schafft da Abhilfe, brauchen tut man wohl Beides.2. Vorstellungsvermögen/Denkgeschwindigkeit/"Intelligenz"
Ich hab keine Ahnung wie andere Programmierer das machen(würde mich mal interessieren), aber wenn ich eine Methode schreibe denke ich da nicht über jede Zeile oder Schleife nach, genausowenig wie man beim Autofahren noch bewusst schaltet und lenkt wenn man n bissl länger fährt.Vielmehr habe ich halt mein Teilproblem, denke da drüber nach "was soll hier passieren" und im Kopf bildet sich der Quellcode quasi Selbst(natürlich Pseudocode, sonst ist man in ein paar Jahren ja arbeitslos
).
Wenn diese Passage wichtig ist, nochmal n paar Sekunden nachdenken ob es keine bessere Lösung gibt und dann setze ich den Quellcode nurnoch um, wo ich durchaus so 300 Anschläge/Minute mit kleinen Pausen nutzen kann und weiter gehts.
Bisher funktionierte das so erdachte Konzept von Tippfehlern abgesehen prinzipiell immer, auch wenn da leider mal später noch nicht bedachte Erweiterungen kommen und Tippfehler/mal ne Referenz statt einem Pointer und sowas vorkommen.Naja, sowas kann ein schlechter Programmierer sicher nicht, für ihn ist programmieren einfach Zeile für Zeile überlegen und reintippern und immer mal wieder verzweifeln.
Bessere Programmierer als ich machen das vielleicht dann noch anders oder können sich größere Programmabschnitte vorstellen, who knows.
-
Marc++us schrieb:
b) oftmals auch nicht so sozial-verträglich sind.
wobei die richtigen genies auch meist genug hirnkapazität haben, um auch sehr gut mit ihrem sozialen umfeld umzugehen.
-
Also nach meiner Erfahrung unterscheidet sich die Produktivität von Entwicklern in dem Wertebereich von [200,-200].
Ich kenne einige Entwickler, die wirklich ein Talent dazu hatten Entwicklungen in letzter Sekunde noch niederzubrennen!
Des Weiteren gilt:
- ein Entwickler ist nur so gut wie der Projektleiter/Teamführer es zuläßt.
- 100 LOC vernünftig getestet und dokumentiert sind besser als 100 KLOC ungetestet oder undokumentiert.
- ein Feature mit Kundenwert ist besser als 1000 ohne.
- ein Entwickler der ein bisschen für seine Kollegen mitdenkt und dafür weniger schafft, ist besser als ein Entwickler der sich nur sich nur um sich kümmert und dafür reinklotzt.
- ein Entwickler, der bereit ist für 20% Kapa etwas von seinen Kollegen zu lernen, ist bereits nach Wochen schneller als wenn er sich mit 100% nur um seinen Kramm kümmert.
- ein Entwickler mit guten IT Verständnis verabscheut stundenlange Meetings.
- ein Entwickler der wirklich produktiv ist, bringt sich immer und kontinuierlich in die Gesamtstrategie ein. Und ist deshalb nicht sozial-verträglich ...
-
- ein guter Entwickler hasst generell BWLer und hohles Wirtschaftsgelaber
-
anmerkung schrieb:
- ein guter Entwickler hasst generell BWLer und hohles Wirtschaftsgelaber
Hi, ich glaube, Du solltest mal häufiger in "Die Presse" gucken und da die "Karriere Lounge" lesen. Dann würdest Du auch typische Karrierefallen im IT-Umfeld kennen:
Die Presse - Karriere Lounge, 30. September 2006 schrieb:
Karrierefallen!
- Informatiker mit Scheuklappen. Wer mit Herz und Seele an seinen Programmiersprachen hängt und Verachtung für das Geschäft hegt, wird es schwer haben.
- ...
Ok, Du kannst natürlich auch mit stärkster BWLer-Verachtung ein toller Entwickler sein, aber es sollte Dir klar sein, dass das Deiner Karriere stark schaden wird. ...andererseits: Wenn "Code tippen" Dein Lebenstraum ist, dann ist es natürlich praktisch, wenn Du Dir weitere Karrieremöglichkeiten unmöglich machst!
-
Prof84 schrieb:
- ein Entwickler mit guten IT Verständnis verabscheut stundenlange Meetings.
ich liebe zwar meetings, aber keine stundenlangen.
übrigens fällt mir positiv auf, daß du in letzter zeit in diesem forum versuchst, auf buzzwording zu verzichten. ist es nicht ein schönes gefühl, ernst genommen zu werden?
Prof84 schrieb:
- ein Entwickler der wirklich produktiv ist, bringt sich immer und kontinuierlich in die Gesamtstrategie ein. Und ist deshalb nicht sozial-verträglich ...
naja, "in die Gesamtstrategie einbringen" war jetzt nicht nötig. könntest sagen, daß ein wirklich produktiver entwickler nicht von seinem rechner weggeht, denn da würde er programmierzeeit verlieren. sollten wir als produktiv nicht definieren, daß es das ist, was gut für den unternehmenszweck ist? da kann es durchaus sein, daß ein ahnunghaber seinen code weglegen sollte und für 20 schwächere mitdenken sollte. auch wird es immer so sein, daß der verzicht auf gelegentliche kurze gespräche das arbeitsklima verschlechtert, was die produktivität (der anderen) verschlechtert.
-
Prof84 schrieb:
Des Weiteren gilt:
- ein Entwickler ist nur so gut wie der Projektleiter/Teamführer es zuläßt.
- 100 LOC vernünftig getestet und dokumentiert sind besser als 100 KLOC ungetestet oder undokumentiert.
- ein Feature mit Kundenwert ist besser als 1000 ohne.
- ein Entwickler der ein bisschen für seine Kollegen mitdenkt und dafür weniger schafft, ist besser als ein Entwickler der sich nur sich nur um sich kümmert und dafür reinklotzt.
- ein Entwickler, der bereit ist für 20% Kapa etwas von seinen Kollegen zu lernen, ist bereits nach Wochen schneller als wenn er sich mit 100% nur um seinen Kramm kümmert.
- ein Entwickler mit guten IT Verständnis verabscheut stundenlange Meetings.
- ein Entwickler der wirklich produktiv ist, bringt sich immer und kontinuierlich in die Gesamtstrategie ein. Und ist deshalb nicht sozial-verträglich ...Dem stimme ich voll zu. Desweiteren muss ich volkard zustimmen: Du wirkst in letzter Zeit wesentlich sympatischer.
-
Marc++us schrieb:
Theorie schrieb:
Mein ihr nicht, dass es oft besser wäre, wenn einer sich eine Lösung ausdenkt. Wenn das ein Team macht, dann gibts viel bla bla,
Das kann man nicht pauschalieren. Ab einer gewissen Komplexität nimmt die Wahrscheinlichkeit zu, daß eine Einzelperson gewisse Tücken des Problems übersieht. Auch wird die Wahrscheinlichkeit, daß der eingeschlagene Weg grundfalsch ist, minimiert, da er bereits zu Beginn mehrfach geprüft und diskutiert wird.
Es ist allerdings auch richtig, daß Teams Zeit kosten, wenn zu viel über Implementierungsdetails diskutiert wird. Das ist eine Gratwanderung, bis zu einem gewissen Punkt der Planung sehe ich Teams (und die damit verbundenen Diskussionen) als schlagkräftiger an, aber danach nimmt dies auch wieder ab. In der Fehlersuche sind allerdings Zweierteams auch deutlich stärker als Einzelpersonen.
Wobei ich hier von ganz normalen Otto-Normalprogrammierern ausgehe, Genies schlagen die Teams fast immmer, aber woher soll man die nehmen? Die gibt's ja nicht im Regal.
Also, ich kenne ja nun beides:
Ich hab mal gut 1 Jahr in einem wirklichen Klasse-Team mit zwei echten Gurus gearbeitet.
Die beiden haben sich zwar öfters mal gezankt, aber sie haben uns andere grundsätzlich mitgenommen und alles erklärt.Jetzt programmiere ich ne größere Software alleine, d.h. ich hab zwar User zum Features erfragen, aber sonst bin ich mit der Entwicklung (abgesehen vom Forum hier) alleine gelassen.
Es ist zwar nett, immer Recht zu haben, weil keiner dagegen ist - aber mir fehlen die Diskussionen mit den Kollegen sehr.
"Einzelhaft" kann ich keinem empfehlen.
-
volkard schrieb:
übrigens fällt mir positiv auf, daß du in letzter zeit in diesem forum versuchst, auf buzzwording zu verzichten. ist es nicht ein schönes gefühl, ernst genommen zu werden?
Ich finde es albern, wenn man sich hier bezüglich seiner Sprache verstellen muss, um ernstgenommen zu werden. Es spricht sicherlich für Prof84, falls er versucht, sich bezüglich seiner Sprache an die hier üblichen Umgangsformen anzupassen. Es spricht aber ganz stark gegen das Forum hier, dass er das überhaupt machen muss, "um ernst genommen zu werden". Ich hatte zumindest nie ein Problem damit, dass Prof84 Fachbegriffe nutzt, die für ihn üblich sind.
Mich hat hier letzt auch schon einer angemacht, weil ich Begriffe aus der Bildverarbeitung genutzt habe. Ich kann das nicht nachvollziehen: Jeder hier kann sich in Sekunden die Bedeutungen solcher Begriffe ergoogeln oder in Wikipedia nachgucken, falls sie ihm nicht klar sind. Zudem wird einem "Buzzwording" auch noch vorgeworfen, wenn das Verständnis der Begriffe überhaupt nicht zum Verständnis einer Aussage in einem Beitrag nötig ist.
Das ist echt jämmerlich.
Was kommt als nächstes? Macht mich bald ein 13-jähriger an, wenn ich von Klassen, Objekten und Vererbung rede und er nichts versteht?
-
Gregor schrieb:
Zudem wird einem "Buzzwording" auch noch vorgeworfen, wenn das Verständnis der Begriffe überhaupt nicht zum Verständnis einer Aussage in einem Beitrag nötig ist.
Was mich zu der Frage führt, warum man überhaupt Begriffe verwendet wenn sie nicht zum "Verständnis einer Aussage" beitragen. Das ist Buzzwording in seiner höchsten Form!