Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03275.jsonl.gz/1888

Hi!
> Warum muss ein KFZ-Mechaniker einen Motor zeichnen können,
Gute Frage, ich bevorzuge eigentlich Mechaniker, die wissen was sie tun und nicht nur zeichnen koennen, dafuer beauftragt man Zeichner. Schliesslich folgt aus reinem Wissen ja nicht automatisch die Faehigkeit dieses Wissen auch sinnvoll anzuwenden.
Natuerlich muss der Mechaniker wissen wie ein Motor funktioniert und ein Programmierer muss sich einen sinnvollen Programmablauf ausdenken koennen, aber IMHO muss keiner der Beiden das aufzeichnen. Voralllem nicht, wenn der Programmierer alleine arbeitet. Struktogramme koennen eine Hilfe sein, aber sie koennen auch einfach nur sinnlos Zeit fressen. Wuerdest du z.B. fuers HDS ein Struktogramm zeichnen wollen? Oder als anderes extrem fuer ein Gaestebuch? Das kann man in 10 Minuten schreiben, man kann in der Zeit aber auch Struktogramme malen.
Das sieht man schoen im Informatikunterricht: Mit Stuktogramm dauert fast alles laenger und bringt fuer mich keinen Gewinn weil ich mir den Algorithmus eh vorher ueberlege und dann dank Struktogrammen in zwei Sprachen umsetze.
Wenn deine Kunden dir die Zeit bezahlen wollen koennen sie das ja gerne tun, aber ich sehe keinen Grund dafuer, dass jeder Stuktogramme malen (koennen) soll. Glaubst du fuer Linux, GNU oder Apache existieren welche? Funktioniert diese Software?
Was bringt dir dein Struktogramm wenn du dann beim Umsetzen auf einmal merkst dass es so doch nicht geht (z.B. weil die Sprache da beschraenkt ist oder der Compiler/Interpreter sich nicht ganz nach Doku verhaelt)? Oder was tust du, wenn du beim Programmieren auf eine bessere Loesung stoesst? Aenderst du dann deine Struktogramme? Wenn nein: Was tut dann jemand, der das Programm spaeter aendern soll wenn die Doku (=Struktogramm) nicht mit dem Sourcecode uebereinstimmt? Entweder er wirft die Doku ganz weg, dann war die Arbeit umsonst oder er raetselt erstmal rum warum er das beschriebene Vorgehn nicht im Source erkennen kann.
> mit Werkzeug umgehen können (falls er etwas ohne Werkzeug machen
> soll, sonst natürlich schon)
Ungueltige Verallgemeinerung. Du musst _nichts_ ueber Datenbanken wissen wenn du mit was anderem arbeitest. Oder kennst du alle Befehle, Module und Protokolle deiner bevorzugten Sprache auswendig, nur weil man sie ja irgendwann mal brauchen _koennte_? Also ich sehe keinen Grund warum dein genannter Mechaniker wenn er meinen PKW repariern soll Ahnung von LKW haben muss.
> und mit Standardteilen umgehen können?
OOP ist kein von jedem verwendeter Standard. Man kam ca. 30 Jahre ohne aus und muss es auch heute nicht benutzen. Es ist auch sicher nicht ueberall sinnvoll.
> Schließlich kann kann man mit Standardteilen genauso gut oder
> schlecht reparieren wie ohne.
Sofern das zutrifft (was bei OOP vs. !OOP eben so ist) sehe ich da kein Problem.
> Auch für tieferes Wissen über die Straßenverkehrsordnung sehe ich
> keinen Grund,
Gut, ich auch nicht. Der Mechaniker soll das Auto reparieren und nicht damit rumfahren. Warum ist es da noetig zu wissen, dass man z.B. nicht rechts ueberholt?
> warum sollte ein KFZ-Mechaniker mehr darüber wissen als dass man
> vorwärts und rückwärts fahren kann?
Ungueltige Verallgemeinerung. Er muss wissen, was das Auto koennen soll und was er tun muss, dass es das kann.
> Was hat die Fähigkeit, einem Kunden seine Tätigkeit zu vermitteln,
> mit KFZ-Technik zu tun?
_Das_ frage ich mich auch. Wenn der Kerl mir erklaeren kann wie man das macht ist er entweder im falschen Beruf und haette Lehrer werden sollen, oder seine Aufgabe ist so trivial, dass ich sie selbst uebernehmen koennte. Oder fragst du deinen Apotheker auch nach der Strukturformel der Medikamente und laesst dir dann die genaue Wirkungsweise erklaeren? Die Frage kam wohl von jemandem, das der nicht selber Programmiert. Wie soll er unterscheiden, oder jemand ihm gerade etwas sinnvoll erklaert hat oder sich einach nur irgendwas ueberlegt hat, was sich logisch anhoert?
> Es gibt auch genug Leute die einfach gut reden koennen und Dir den
> _Eindruck_ vermitteln etwas zu koennen...
Das schrieb ich schon. Du hast es mit deiner Analogie auch nicht widerlegt.
Jan-Martin
als Antwort auf: [#85672]