Der Flaschenhals in der Softwareentwicklung war nie das Programmieren, sondern das Verstehen des Problems. Über den unterschätzten ROI von Verständnis.
The bad programmer writes a lot of spaghetti code that is impossible to debug or fix, so it has to be rewritten. The good programmer writes a few lines of efficient code and is done with the work. The enlightened programmer realizes this feature already exists somewhere else and doesn’t have to be rewritten. The enlightened programmer writes no code.
Das Problem war nie das Schreiben von Code, sondern wie man es schafft, mit möglichst wenig Code möglichst das zu haben, was man braucht. Frei nach Elon Musk: The best part is no part. Bedeutet, wenn es ohne geht, dann besser ohne.
Interessant, dass du hier Elon Musk zitierst, der ja bekannterweise nach der Twitter-Übernahme Leute auf Basis von “Lines of code written last year” gefeuert hat.
Ich glaube nicht, dass das von Musk ist. Die Idee ist älter als Musk selber.
Auch die Kritik an überbordender Konplexität in Software ist nicht neu. Z.B. hat Niklaus Wirth nicht nur schon diese Kritik geäußert, sondern mit dem Projekt Oberon schon seit 1985 gezeigt, dass man Software wie ein ganzes Betriebssystem mit weniger Komplexität schreiben kann und auch schneller fertig wird. Ähnliche Gedanken hat un jüngerer Zeit Rich Hickey entwickelt , von dem es eine Reihe Brillante Youtube-Videos gibt, und der die extrem elegante Sprache Clojure entwickelt hat.
Zeigt halt schön, welches gute Marketing der hatte. Dein Zitat wird irgendwer ihm geschrieben haben, er hat es ausgeplaudert, Leute haben ihn deswegen für klug gehalten. Und dann stellt sich nachher raus, dass er null Plan hat.
Naja, ich meine eher, weil er ja tatsächlich versucht hat das im großen Stil umzusetzen und damit nur gezeigt hat, dass es eben doch nicht so wahr ist.
Dochdoch. Wenn man etwas mit mehr code effizienter / schöner / besser wartbar macht, dann ist das nicht unnützer Code. Abgesehen davon ist
weniger = mehr im coden. Jede Zeile Code ist eine Schuld in Wartung und Bugs.
The Zen of Programming:
Das Problem war nie das Schreiben von Code, sondern wie man es schafft, mit möglichst wenig Code möglichst das zu haben, was man braucht. Frei nach Elon Musk: The best part is no part. Bedeutet, wenn es ohne geht, dann besser ohne.
Interessant, dass du hier Elon Musk zitierst, der ja bekannterweise nach der Twitter-Übernahme Leute auf Basis von “Lines of code written last year” gefeuert hat.
Ich glaube nicht, dass das von Musk ist. Die Idee ist älter als Musk selber.
Auch die Kritik an überbordender Konplexität in Software ist nicht neu. Z.B. hat Niklaus Wirth nicht nur schon diese Kritik geäußert, sondern mit dem Projekt Oberon schon seit 1985 gezeigt, dass man Software wie ein ganzes Betriebssystem mit weniger Komplexität schreiben kann und auch schneller fertig wird. Ähnliche Gedanken hat un jüngerer Zeit Rich Hickey entwickelt , von dem es eine Reihe Brillante Youtube-Videos gibt, und der die extrem elegante Sprache Clojure entwickelt hat.
ja haha das war wohl etwas unglücklich zitiert.
Zeigt halt schön, welches gute Marketing der hatte. Dein Zitat wird irgendwer ihm geschrieben haben, er hat es ausgeplaudert, Leute haben ihn deswegen für klug gehalten. Und dann stellt sich nachher raus, dass er null Plan hat.
Ah ja, Elon Musk. Der Meister der Rationalisierung. /s
Auch ein blindes Huhn stiehlt mal ein Korn
Gerade ja nicht. Er hat ja das Konzept versucht mit DOGE umzusetzen und fast das Gegenteil bewiesen.
Er mag das von einem Ingenieur gestolen haben, aber wahr ist es trotzdem.
Naja, ich meine eher, weil er ja tatsächlich versucht hat das im großen Stil umzusetzen und damit nur gezeigt hat, dass es eben doch nicht so wahr ist.
Dochdoch. Wenn man etwas mit mehr code effizienter / schöner / besser wartbar macht, dann ist das nicht unnützer Code. Abgesehen davon ist weniger = mehr im coden. Jede Zeile Code ist eine Schuld in Wartung und Bugs.