Der schnellste Programmierer der Welt!
-
_-- schrieb:
ich hab mal in einem microsoft buch gelesen (jaa, ein buch und von ms
), ist zwar schon etwas her, aber es war auf jeden fall >50k und <100k ca. 80k müssten es als topwert gewesen sein und die haben schon verdammt viele gute angestellte 
Bei 22 Arbeitstagen im Monat sind das fast schon 4k Zeilen am Tag bzw. 500 pro Stunde. Und zwar als Durchschnittsleistung. Daran glaube ich nicht. Nicht einmal wenn es alles 08/15 Code waere, den man praktisch direkt runtertippen kann.
-
weiß leider nicht in welchem buch es war, es ging auf jeden fall um aufwandsschätzung und als ich das vor ca. 5-6 jahren gelesen hab, hab ich auch so geschaut (btw. heute noch immer)
vllt. war es ein verkappter programmier autist, keine ahnung
-
William Henry Gates III schrieb:
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
-
Hi,
was will ich wirklich rechnen? Wenn ich einfach nur die Zeilenumbrüche zähle komme ich auf gute Werte.
Aus meiner Sicht ist die einfachste Möglichkeit alle Zeilen mit einer Zuweisung zu zählen. Das ist zwar weniger als die eigentlichen Programmzeilen, aber aus meiner Sicht die einfachste Weise eine wirklich verwerbare und vergleichbare Summe zuu bekommen.10 Zeilen pro Tag scheinen mit ein wenig zu wenig geschätzt, aber 500 Zeilen pro Stunde, das sind gerade mal 7,2 Sekunden pro Zeile, das braucht ja schon eine Sekretärin zum normalen abschreiben. Bei Aufgaben wo man dabei mit denken muss, kann ich mir das nicht vorstellen. Selbst wenn man Vereinbarungen, Kommentare... mitzählt.
Wobei es sicher eine Frage der Programmiersprache ist. Bei sehr schreibintensiven Sprachen wie Cobol kommt man sicher auf mehr, als bei C++ und ähnlichen Sprachen.Nebenbei, bei manchen Programmen merkt man, dass die Programmierer nach Zeilenleistung arbeiten.
Gruß Mümmel
-
@dot musst du sowas unbedingt in meinen thread reinfädeln?
-
muemmel schrieb:
Aus meiner Sicht ist die einfachste Möglichkeit alle Zeilen mit einer Zuweisung zu zählen.
Wusste ich doch schon immer, dass diese Haskeller faule Säcke sind.
-
HI,
Bashar schrieb:
muemmel schrieb:
Aus meiner Sicht ist die einfachste Möglichkeit alle Zeilen mit einer Zuweisung zu zählen.
Wusste ich doch schon immer, dass diese Haskeller faule Säcke sind.
kannste immer nur auf gleiche Programiersprachen anwenden. Selbst verschiedene Versionen der gleichen Sprache sind da nur bedingt vergleichbar.
Wenn Du ein Programm aus den Anfangszeiten von C++ nimmst, wo generische Programmierung noch nicht so die Rolle spielte, dann wirst Du da sicher merh Zeilen am Tag schaffen, als wenn Du heute mit arbeitest.
Aber saubere generische Programmierung schreibt sich (für die meisten) eben nicht so flüssig runter. Man muss sich mehr Gedanken machen was man will, braucht pro Zeile mehr Zeit, aber schafft das Ergebnis schneller mit weniger Zeilen und vor allem weniger Fehlern.Da ich arbeitsbedingt fast völlig auf Delphi umgestiegen bin, kann ich da natürlich eher dazu was sagen, aber es hat sich auch weiterentwickelt. Es wird immer mehr ein C++ mit Pascalsyntax. Abgesehen von der anderen Syntax ist aber delphi aus meiner Sicht eher auf der Ebene von Java angesiedelt.
Gruß Mümmel
-
muemmel schrieb:
Nebenbei, bei manchen Programmen merkt man, dass die Programmierer nach Zeilenleistung arbeiten.
Das Schlimme ist: es gibt auch genug Programmierer die nicht nach Zeilen bezahlt werden, die aber trotzdem Bugware (tm) Copy+Paste Code schreiben.
500-Zeilen Funktionen die ordentlich gefaltet (in mehrere Funktionen aufgeteilt und sinnlos-kompliziert Konstrukte entfernt) 80-120 Zeilen lange sind.
2-3 davon pro durchschnittlichem Source-File. Uh jeah Bebe!
-
Naja, mit virtuosem Skriptkiddie-tum, und das fließt sicher auch in die Microsoftschätzung ein, kann man eine ganze Menge schaffen...
Es ist also auch die Frage, ob man in einem vertrautem Bereich arbeitet, oder eher an einem Alles-Ist-Möglich-Contest teilnimmt.
Dann wäre noch die Frage, ob es generell um Tippgeschwindigkeit geht, oder zum Beispiel um das virtuose Vermischen von Scripsprachen-Code mit schneller-Code.
So gesehen ist die Frage nach der Menge bei der Frage nach dem schnellsten Programmierer ziemlich irrelevant.
Die Frage ist auch für Wirtschaftler völlig daneben, die brauchen Programmierer, die Geld bringen bzw. sparen.
Und ausserdem wäre dann Anschläge pro Minute beim Tippen irgendwie aussagekräftiger, weil dieser Messungstyp sich direkt aufs Tippen und nichts anderes bezieht. Und da kann man dann gucken, wie schnell die schnellsten Tipper sind und wenn es sich dann um eine einfache Programmierarbeit zum Test handelt, sagen wir mal eine Htmlseite gestalten, dann kann man schon ziemlich gut ableiten, was hinterher rauskommen kann.
Ganz grob würde ich mal schätzen, dass Lisp-Coder sehr schnell sein können.
-
Steffo schrieb:
Man ist ja nicht ununterbrochen am Coden. Was ist mit Tests, Wartung, Bugfixing, Planung, Refactoring etc.? Unterm Strich bleiben dann effektiv 10 Zeilen Code pro Tag.
Nein. Immernoch nicht.
-
@Steffo
Nö, 10 Zeilen/Tag ist definitiv zu wenig. Viel zu wenig.Natürlich kommt es immer drauf an was man genau macht.
Wenn man komplexe Algorithmen implementiert schafft man weniger Output/Zeit als wenn man "einfach" nur GUI Frontends runterklopft oder die 100. Datenauswertung nach Schema-F programmiert.Die meisten Programmierer-Jobs liegen aber in einem Bereich, wo man dich mit 10 Lines/Tag ganz schnell rausschmeissen würde.
-
Eine Wochenarbeit:
package nano.kernel; import nano.core.MultiList00; import nano.core.MultiList01; /** * * @author Zeus */ public class App { public static void main(String[] args) { Graph<MultiList00, MultiList00> graph = new GraphDefault<>(); Place<Object> place1 = new PlaceQueue<>(); Place<Object> place2 = new PlaceQueue<>(); Transition<MultiList01<Object>, MultiList01<Object>> trans1 = new TransitionDefault<MultiList01<Object>, MultiList01<Object>>() { @Override public Command<MultiList01<Object>, MultiList01<Object>> getFunction() { return new Command<MultiList01<Object>, MultiList01<Object>>() { @Override public void invoke(MultiList01<Object> argument, MultiList01<Object> result) { for (long index = 0; index < 987654321L; ++index) { } System.out.println("Done..."); result.setOne(argument.getOne()); } }; } }; graph.add(place1); graph.add(trans1); graph.add(place2); graph.connect(place1, trans1); graph.connect(trans1, place2); place1.add(new Object()); place1.add(new Object()); place1.add(new Object()); place1.add(new Object()); Platform p = new Platform(); p.setGraph(graph); p.start(); } }Glaub eher bisschen mehr xD
-
-
hustbaer schrieb:
@Steffo
Nö, 10 Zeilen/Tag ist definitiv zu wenig. Viel zu wenig.Natürlich kommt es immer drauf an was man genau macht.
Wenn man komplexe Algorithmen implementiert schafft man weniger Output/Zeit als wenn man "einfach" nur GUI Frontends runterklopft oder die 100. Datenauswertung nach Schema-F programmiert.Die meisten Programmierer-Jobs liegen aber in einem Bereich, wo man dich mit 10 Lines/Tag ganz schnell rausschmeissen würde.
Die Zeilenangaben stammen vom Mystical Man Month und ich rede wie gesagt nicht von Spitzenzeiten, sondern vom Durchschnitt. Mir ist schon klar, dass man am Tag mehrere tausend Zeilen am Tag schaffen kann, aber das ist eben nicht der Durschnitt. Manchmal sitzt man auch mehrere Tage an nur einem Bug dran und auch an anderen Punkten, die ich aufgelistet habe.
Wenn man sich verschiedene Entwicklungsmodelle anschaut, dann ist die Implementierung, nur ein Teil von mehreren.L. G.
Steffo
-
Hmpf. Und ich investiere Zeit, um mir hintenraus Codezeilen zu sparen. Ich mach wohl was falsch...
-
Hi,
es heist ja nicht umsonst "die dümmsten Programmierer haben die dicksten Programme".
Mit husch-husch einen langen Copy-Paste-Brief an den Compiler schreiben schindet man natürlich gewaltig Zeilen, und bei Cheffs, die am Ende die Zeilenzahl angucken statt den Code macht man da gewaltig Eindruck. (Ich verweise hier mal wieder auf das alte Lenin-Zitat "der Fisch fängt am Kopf zu stinken an", d.h. ein Team programmiert meist nicht besser als es der Cheff ermöglihct).
Für wirklich gute Programmierung ist das Codieren letzlich nur noch der allerletze Schritt zum ausführbaren Programm. Ist bei mir selbst aber mittlerweile auch die Ausnahme. Wenn der Cheff 30 Minuten (oder auch mal 2 Stunden) nach Auftragserteilung erst mal was fürs Auge sehen will, also eine erste Benutzeroberfläche, dann läufts eben andersrum, erst formulare stricken und dann Verarbeitung reinhängen. Und nach der 500sten Wünsch-Dir-Was-Änderung ist dann eben ein Rucksackprogramm draus geworden. Wat solls. Ich bin Software-Entwickler und nicht Diplom-Cheff-Domestizierer. Muss ich eben sehen, wie ich trotzdem noch einigermaßen Qualität leisten kann. Zum Beispiel in dem ich mir für sehr viele Sachen wenn Zeit ist eigene Komponenten vorfertige, aus denen ich dann das eie oder andere Baukastenmäßig zusammensetzen kann. Oder in dem ich versuche, immer mehr von der programmierten Lösung weg hin zu SQL-Lösungen zuz kommen. Und in vielen anderen Betrieben ist es auch nicht so viel anders.
Vor allem da, wo wie bei mir nur ein einzelner Einzelkämpfer sitzt, wird es immer einen schleichenden Verfall geben, weil man zu sehr im eigenen Saft schmort und zu wenig neuen Input hat. Allerdings ist Delphi mittlerweile sehr C++ -ähnlich, so dass man da aus guten C++Büchern einiges lernen kann. Bedingt durch die jährlichen Versionswechsel von Delphi macht sich ja mittlerweile kein Verlag mehr die Mühe da aktuelle Bücher rauszubringen.
Gruß Mümmel
-
@Mümmel: Wieso wechselst du nicht die Arbeitsstelle? Es gibt durchaus Firmen, die anders vorgehen und der Chef auch Ahnung hat bzw. auf die Kompetenzen ihrer Mitarbeiter vertraut und weiß, dass Softwareentwicklung seine Zeit braucht.
-
Sinngemäßes Zitat aus dem Lama Buch:
Faulheit ist eine Tugned. Denn faule Menschen wollen nicht viel arbeiten und entwickeln daher Methoden die ihnen die Arbeit erleichtern. Und aus diesem Kontext heraus entstand Perl.Summa Sumarum:
Die Frage nach LOC ist unsinnig. Viele LOC deuten aber auf sehr schlechten Code (Copy Pase Modify) hin, während wenige LOC eher ein Indiz auf wiederverwendbaren Code hinweisen.
-
Ich schlussfolgere:
Der schnellste Programmierer wird viel wiederverwertbaren Code schreiben, welcher durchaus einem Design-Prozess unterliegen kann/muss und evt. einer strengen Testphase unterliegt. Der Quotient LOC/Zeit dürfte hier relativ niedrig sein.
Aber wenn ein neues Problem auftaucht, wird er das Problem wie mit einem Lego-Baukasten Stück für Stück, dank der wiederverwendbaren Komponenten, relativ schnell zusammensetzen. Und auch hier ist der Quotient LOC/Zeit relativ niedrig.
-
Hi Steffo,
Steffo schrieb:
@Mümmel: Wieso wechselst du nicht die Arbeitsstelle? Es gibt durchaus Firmen, die anders vorgehen und der Chef auch Ahnung hat bzw. auf die Kompetenzen ihrer Mitarbeiter vertraut und weiß, dass Softwareentwicklung seine Zeit braucht.
weil es eben immer ein Gesamtpaket ist. Wenn man eine Arbeitsstelle hat wo man sich insgesamt wohl fühlt, mit den Kollegen (auch Cheffs) menschlich gut klar kommt, recht gut bezahlt wird (zumindest für hier im Osten), einen relativ sicheren Job in Landesdiensten hat und mittlerweile 55 ist, dann sollte man das nicht ohne wirklichen Grund aufgeben. Es ist ja nun nicht so, daß ich hier geistig nicht mehr gefordert werde. Bei mir steckt das interessante eben unter der Oberfläche, also die kleinen Hilfsmittel und Lösungswege die ich mir baue, vor allem aber auch im Zusammenwirken zwischen (mittlerweile erworbenem) Fachwissen und Programmierwissen. Es ist ein Gesamtpaket das passt, und da muss ich halt wie jeder andere auch mit einigen Klemmstellen leben.
Gruß Mümmel
