|
|
Forum: Offtopic Unfähigkeitssatz der InformatikIrgendwer in diesem Forum hat einmal einen Satz geschrieben, über den ich hin und wieder nachdenke: Erster allgemeiner Unfähigkeitssatz der Informatik:
Vielleicht ließe sich das Erweitern zu: "Ein Informatiker ist nicht in der Lage dazu, ein Program auf die minimal notwendige Funktion zu reduzieren" Dieser Gedanke kam mir beim Betrachten verschiedener STM32 Code-Examples. Naja vollgepumpt mit Profesor:Innen gemaess den Regelungen, waren das überzogene Erwartungen. Die Praxis kommt dann spaeter. Bald muss man eh nur die KI fragen koennen. Christoph M. schrieb: > Ein Informatiker ist nicht automatisch ein Anwendungsentwickler oder primär jemand der Programme schreibt. Das ist viel zu allgemein. Schon mal geschaut was man in theoretischer Informatik so macht. Nur als Beispiel? Informatiker kann jemand mit Ausbildung (Fachinformatiker) oder mit Studium sein. Nicht mal das definiert diese Bezeichnung. Die Gegenfrage wäre nun: Wer schreibt nun die guten Programme die man ausliefern kann? Bäcker? :
Bearbeitet durch User
Cyblord -. schrieb: > ist nicht automatisch ein Anwendungsentwickler oder primär jemand der > Programme schreibt. Ein Informatiker, der keine oder kaum Programme schreibt, kriegt es wohl auch nicht besser hin, als einer, der es tut. Insofern ist der Satz formal nicht zu beanstanden.
Beitrag #7750805 wurde vom Autor gelöscht.
Eigentlich wollte ich ja hier nicht den Berufsstand des Informatikers beleidigen. Das mit dem Unvollständigkeitssatz betrifft mich hin- und wieder auch selbst, obwohl ich kein Informatiker bin aber doch dazu neige, hin- und wieder etwas zu programmieren. Was mir aber in den langen Jahren innerhalb diese Berufes auffällt: Die Leute neigen zur "Feature-ittis" und blasen die Software immer auf, nur um Optionen freizuhalten, die später keiner braucht. Es ist eine hohe Kunst, eine Programm (oder auch ein beliebiges technisches Gerät) auf die einfachste Bedienbarkeit und auf das minimal Notwendigste reduziert, zu entwickeln. Die Frage: Für was brauche ich das Ding eigentlich und wie kriege ich das am schnellsten hin, geht sehr gerne unter. Christoph M. schrieb: > Die > Leute neigen zur "Feature-ittis" und blasen die Software immer auf, nur > um Optionen freizuhalten, die später keiner braucht. Würdest du ein Produkt kaufen, das sich nicht vor Vorgänger unterscheidet, lediglich eine höhere Stabilität bei weniger Bugs verspricht - was meist nicht gleich nachprüfbar ist? Oder würdest du dann beim alten bleiben, wenn die Bugs keine Showstopper sind? Abhilfe: Produkt vermieten. Bringt regelmäßig Geld in die Kasse, ohne zwingend eine Gegenleistung zu erbringen. Funktioniert bestens in Verbindung mit vendor lock in. :
Bearbeitet durch User
Christoph M. schrieb: > Was mir aber in den langen Jahren innerhalb diese Berufes auffällt: Die > Leute neigen zur "Feature-ittis" und blasen die Software immer auf, nur > um Optionen freizuhalten, die später keiner braucht. Bis zu einem gewissen Grad kann das sinnvoll oder sogar "State of the Art" sein: - Dass man Konstanten nicht hardcoded in den Quelltext legt, ist Allgemeinwissen. - Dass man normalerweise nicht anfängt, seinen eigenen Compiler für X-beliebiges-Software-Projekt Nr. 17 zu schreiben, ist auch jedem klar. Dazwischen gibt es ein weites Feld von mehr oder weniger sinnvollen und aufwendigen Generalisierungen, die einem spätere Anpassungen erleichtern können. Wenn man die Wette gewinnt, spart man nachher sehr viel mehr Zeit als man reingesteckt hat - was sonst eine Woche dauert, kann in Minuten "fertig" sein... Aber ja, manchmal hält man sich auch lange an Dingen auf, die am Ende doch keiner braucht. Daher ist es schon gut sich immer mal wieder an die eigene Nase zu fassen und zu fragen: Wie viel Zeit investiere ich, und wie viel Zeit habe ich damit im Mittel gespart? Antoine de Saint-Exupéry ist berühmt für den Spruch: “Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away” Antoine de Saint-Exupery. Leider scheint man das fast nirgendwo zu wissen oder ernstlich zu berücksichtigen. (prx) A. K. schrieb: > Würdest du ein Produkt kaufen, das sich nicht vor Vorgänger > unterscheidet, lediglich eine höhere Stabilität bei weniger Bugs > verspricht - was meist nicht gleich nachprüfbar ist? Ja. > Oder würdest du > dann beim alten bleiben, wenn die Bugs keine Showstopper sind? Ich hätte den Vorgänger nicht gekauft. Kein early adopter, sondern erst die zweite Serie kaufen. Es gibt sehr viele Produkte, die weiterentwickelt unattraktiv geworden sind, und bei denen ma lieber beim alten bleibt, was noch fokussiert auf das zu lösende Problem war. Gerhard O. schrieb: > Antoine de Saint-Exupéry ist berühmt für den Spruch: > “Perfection is Achieved Not When There Is Nothing More to Add, But When > There Is Nothing Left to Take Away” Antoine de Saint-Exupery. > Leider scheint man das fast nirgendwo zu wissen oder ernstlich zu > berücksichtigen. Na ja, JEDER Informatiker bekommt im ersten Semester beigebracht, dass das optimale Programm genau dann vorliegt, wenn es die minimale Anzahl (oder Laufzeit, oder Strombedarf) von Instruktionen ausführt, um das geforderte Problem inklusive Fehlerbehandlung abzuarbeiten, von dem man also nichts mehr weglassen kann. Das überblickt er vielleicht noch bei kurzen Algorithmen wie Bubblesort, danach verliert er den Überblick. Den Rest seines Lebens verbringt der Informatiker damit, Ausreden dagegen zu erfinden "zukunftsorientiert", "wartungsfreundlich", "schneller zusammengeschustert". Also für mich klingt das wie "Mimimimimi, ich komme mit dem fremden Programmierstil nicht klar" und das ist bei Programmierern einigermaßen normal. Quick'n'Dirty war wurde vor einigen Jahren noch völlig salonfähig gemacht... nannte sich "agile Programmierung". Die beiden Buchstaben "fr" am Anfang sind wohl durch einen Bug verlorengegangen. Gerhard O. schrieb: > “Perfection is Achieved Not When There Is Nothing More to Add, But When > There Is Nothing Left to Take Away” Antoine de Saint-Exupery. > > Leider scheint man das fast nirgendwo zu wissen oder ernstlich zu > berücksichtigen. Oder auch KISS! https://de.wikipedia.org/wiki/KISS-Prinzip Wird aber von vielen Akademikern verschmäht, weil das ja "primitiv" ist. https://de.wikipedia.org/wiki/Softwarekrise "Jedoch, trotz verschiedenster Ansätze, gilt die Softwarekrise weiterhin im Allgemeinen als ungelöstes Problem der Informationstechnik. " Tja. :
Bearbeitet durch User
> Erster allgemeiner Unfähigkeitssatz der Informatik: >
Nun, betrachtet man das im Lichte der Beobachtung Edsger Dijkstra:
wird das sicher stimmen. Da "BASIC" allerdings kaum noch in der Erstkontaktphase eines potentiellen Informarmatikstudent liegt, muß man dies womöglich dergestalt aktualisieren:
;-) A) jede SW enthält Fehler B) jede SW kann um eine Zeile verkleinert werden. Nach mehreren iterationen ->> jede SW braucht nur eine Zeile. Und die ist auch noch falsch. :
Bearbeitet durch User
Bei xkcd wurde das Problem mal ganz gut dargestellt: https://xkcd.com/2730/ Irgendwo habe ich mal die Aussage gelesen, dass Ingenieure besser(e) Programme schreiben als Informatiker, weil Ingenieure das Programm so schreiben, wie es gebraucht wird, während Informatiker das Programm theoretisch perfekt schreiben wollen, aber dafür zu lange brauchen oder zu viel Komplexität bekommen. Dabei zwischen Informatikern und Ingenieuren zu unterscheiden ist höchstwahrscheinlich falsch, aber (mindestens) diese beiden Herangehensweisen gibt es. Das habe ich auch mal selber mitgekriegt. Eine Aufgabe in einer Informatikklausur war, eine Form in drei Größen zeichnen zu können (Größe vom Anwender wählbar). Ein Schüler hat das generisch gemacht, so dass jede beliebige Größe darstellbar war, ein anderer hat die drei Fälle hart codiert. Das hart codierte Programm hat funktioniert, das generische war komplizierter, hatte dadurch einen Bug und funktionierte nicht. Wer von denen hat jetzt besser programmiert? Wer hat das bessere Programm geschrieben? Früher hätte ich gesagt, dass das generische Programm besser, weil vielseitiger war. Aber die Anforderung war in der gegebenen Zeit ein funktionierendes Programm zu schreiben und das wurde nur vom hartcodierten Programm erfüllt. Florian schrieb: > Irgendwo habe ich mal die Aussage gelesen, dass Ingenieure besser(e) > Programme schreiben als Informatiker Blitznachricht: Informatiker (zumindest wenn du auf Absolventen des entsprechenden Studiengang abzielst) sind Ingenieure (lt. Ing Gesetz). Wenn ein Post schon mit so viel Unwissenheit anfängt, muss ich den Rest gar nicht lesen. Cyblord -. schrieb: > Blitznachricht: Informatiker (zumindest wenn du auf Absolventen des > entsprechenden Studiengang abzielst) sind Ingenieure (lt. Ing Gesetz). Das habe ich auch kürzlich mit Erstaunen festgestellt. Keiner unserer Informatiker hatte einen Bezug zu technischen Aufgabenstellungen gehabt oder entwickelt. Im Gegenteil: es fehlt am mechanischen, elektrischen und physikalischen Grundwissen, was bei Ingenieuren anderer Fachrichtungen vorausgesetzt werden kann. Bruno V. schrieb: > Keiner unserer > Informatiker hatte einen Bezug zu technischen Aufgabenstellungen gehabt Klingt realistisch. Welcher Informatiker hat schon Bezug zu Technik. Du bist echt ein Clown. > Im Gegenteil: es fehlt am mechanischen, elektrischen > und physikalischen Grundwissen Natürlich natürlich. Der große Ing (Gartenbau) hat gesprochen. :
Bearbeitet durch User
Florian schrieb: > Das habe ich auch mal selber mitgekriegt. Eine Aufgabe in einer > Informatikklausur war, eine Form in drei Größen zeichnen zu können > (Größe vom Anwender wählbar). Ein Schüler hat das generisch gemacht, so > dass jede beliebige Größe darstellbar war, ein anderer hat die drei > Fälle hart codiert. Für den absoluten einfachsten Fall und den dümmsten Typ der das betrachtet (du) mag das klar sein. Jetzt nehme an, du hast die Vorgabe 10.000 Fälle abzudecken. Ist es jetzt immer noch einfacher, 10.000 mal copy und paste zu machen um jeden Fall "hart zu codieren"? Oder ist jetzt plötzlich ein generischer (=variabler) Ansatz besser? Du bewegst dich hier im Bereich einer Schulaufgabe und willst damit irgendwas im realen Entwicklerleben ableiten. :
Bearbeitet durch User
Moin, Also ich kenne eher so Aussagen wie: Informatiker koennen nicht programmieren bzw. Einen Informatiker darfste nix programmieren lassen. Tja. Und tatsaechlich gibt's Informatiker auf die das zutrifft. Wird's aber auch bei Fleischereifachverkaeuferinnen geben. Gruss WK Dergute W. schrieb: > Tja. Und tatsaechlich gibt's Informatiker auf die das zutrifft. Wird's > aber auch bei Fleischereifachverkaeuferinnen geben. Und wer kennt nicht die Aussage: "Eine Fleischereifachverkaeuferin darfste nie hinter ne Theke stellen"? Komischerweise kommen solche Kruden aussagen nur immer im IT Bereich wo jeder Hausmeister und jeder Bau-Ing der schon mal 5 zeilen FORTRAN in 1960 programmiert hat, meint, mitreden zu können. Genau diese Leute würden doch bei jedem auch nur halbwegs komplexen Projekt (hier scheiterst es ja regelmäßig an einer Tastenentprellung) weinen wie kleine Mädchen. :
Bearbeitet durch User
Christoph M. schrieb: > Vielleicht ließe sich das Erweitern zu: > "Ein Informatiker ist nicht in der Lage dazu, ein Program auf die > minimal notwendige Funktion zu reduzieren" Da würde ich gerade keine Informatiker für in Haft nehmen. Berufsmäßig braucht man natürlich was, um sich abzugrenzen, und um sich den "Lebensraum" zu sichern. Ich würde auch nicht unbedingt meinen, das sich die Abgründe des Know Hows der Informatiker gerade bei Mikrocontrollern offenbaren. Außerdem ist vieles Handzusammengestöpselte eher traditionell, während man aktuell eher Bibs zusammenklickt. Außerdem kann man ja auch ganz gut an Internetseiten beobachten, dass die Informatik da eher fehlt. Kann man zwar auch nicht gut verallgemeinern, ergibt aber vielleicht doch gute Hinweise. Nur: wem wollte man an die Gurgel gehen, wenn die vielen verschiedenen und uneinheitlichen Cookie-UIs total nerven? :
Bearbeitet durch User
Bruno V. schrieb: > Das habe ich auch kürzlich mit Erstaunen festgestellt. Keiner unserer > Informatiker hatte einen Bezug zu technischen Aufgabenstellungen gehabt > oder entwickelt. Ist schon sehr lange her, nämlich 1980er, aber in meinem Informatik-Studium (Uni, Diplom) gab es - einen Studienschwerpunkt wie Theorie, Software oder eben Hardware mit Rechneraufbau, Elektronik und Dergleichen, - ein obligatorisches Nebenfach wie Elektrotechnik, Verkehrstechnik oder Energietechnik, das im Idealfall zu späteren Beruf oder wenigstens grob zur Richtung passt. Ing-nahe Kenntnisse sind darin ggf enthalten. :
Bearbeitet durch User
Gerhard O. schrieb: > “Perfection is Achieved Not When There Is Nothing More to Add, But When > There Is Nothing Left to Take Away” Antoine de Saint-Exupery. > > Leider scheint man das fast nirgendwo zu wissen oder ernstlich zu > berücksichtigen. Naja, nur weil das mal irgendein Herr mit wohlklingendem französischen Namen gesagt und zufällig jemand mitgeschrieben hat muss das ja noch lange nicht stimmen. Und dass man das nirgendwo mehr weiß ist nun etwas übertrieben. Diese Plattitüde wird gefühlt täglich irgendwo hochgespült, man kommt ihr kaum aus. Solche Aussagen verleiten, konsequent zu Ende gedacht, zu unleserlichem und unwartbarem Spaghetti-Code, weil man ja unbedingt noch die letzte Instruktion weglassen möchte. Mein Lieblingsbeispiel ist PeDas berühmte Entprellroutine die seit knapp 20 Jahren durchs Forum geistert. Technisch genial, dafür schwer zu verstehen und noch schwerer aufzubohren (aber das muss ja eh niemand, denn Anforderungen ändern sich bekanntlich nie ;-)). Ich weiß nicht wieviele 100 Anfängerfragen es zu dieser Routine regelmäßig gab. Es hätte niemanden weh getan, diesen Algo anders zu formulieren, auch wenn es ein paar nS mehr Rechenzeit gekostet hätte. Und technisch bestand schon im Jahr 2005 keine Notwendigkeit, hier derart zu optimieren. Falk B. schrieb: > Oder auch KISS! Aber KISS ist halt Definitionssache. Für den einen ist die kürzest-mögliche Lösung KISS, alles hartcodiert und unwartbar. Der nächste findet es KISS wenn er über eine Parameterschnittstelle einfach Anpassungen zur Laufzeit machen kann, anstelle an zig Stellen im Code rumzuwurschteln und alles neu zu bauen. Und nun? Die Antwort auf die Frage nach dem besten Programm, dem besten Programmierstil ist halt ein unbefriedigendes "kommt drauf an". :
Bearbeitet durch User
Rbx schrieb: > Außerdem kann man ja auch ganz gut an Internetseiten beobachten, dass > die Informatik da eher fehlt. Zur Ausbildung in Informatik konnte auch zu meiner Studienzeit Anwendungs- und Anwenderorientierung gehören. Da das Web damals irrelevant war, kenne ich heutige darauf abzielende Richtungen nicht, bin aber sicher, dass es sie gibt. Cyblord -. schrieb: > Klingt realistisch. Welcher Informatiker hat schon Bezug zu Technik. Dir ist aber schon klar, dass ein Großteil der embedded-Programmierung einen technischen Hintergrund erfordert? Da ist es kontraproduktiv Informatiker "Ingenieur" zu nennen, wenn sie zur Technik keinen Bezug brauchen. Das wäre so (um im Beispiel zu bleiben), als wenn ein gelernter Viehhändler automatisch Fleischereifachverkäufer ist. Bruno V. schrieb: > Dir ist aber schon klar, dass ein Großteil der embedded-Programmierung > einen technischen Hintergrund erfordert? Dir ist schon klar was Ironie ist? Florian schrieb: >> Das habe ich auch mal selber mitgekriegt. Eine Aufgabe in einer >> Informatikklausur war, eine Form in drei Größen zeichnen zu können >> (Größe vom Anwender wählbar). Ein Schüler hat das generisch gemacht, so >> dass jede beliebige Größe darstellbar war, ein anderer hat die drei >> Fälle hart codiert. Cyblorad schrieb >Für den absoluten einfachsten Fall und den dümmsten Typ der das >betrachtet (du) mag das klar sein. >Jetzt nehme an, du hast die Vorgabe 10.000 Fälle abzudecken. Ist es >jetzt immer noch einfacher, 10.000 mal copy und paste zu machen um jeden >Fall "hart zu codieren"? Oder ist jetzt plötzlich ein generischer >(=variabler) Ansatz besser? >Du bewegst dich hier im Bereich einer Schulaufgabe und willst damit >irgendwas im realen Entwicklerleben ableiten. Exemplarischer hätte man die Ursache des "Unfähigkeitssatz der Informatik" nicht darstellen können. Christoph M. schrieb: > "Unfähigkeitssatz der Informatik" Den es nicht mal gibt. Von dem du aber so gerne redest. Und dann auch noch unqualifiziert. :
Bearbeitet durch User
Christoph M. schrieb: > Vielleicht ließe sich das Erweitern zu: > "Ein Informatiker ist nicht in der Lage dazu, ein Program auf die > minimal notwendige Funktion zu reduzieren" Auf die Programmierer von Kfz-Bordcomputern trifft das definitiv zu. Beispiel: Beim Öffnen der Fahrertür ertönt ein akustisches Warnsignal. Für wie grenzdebil halten die die Autofahrer eigentlich? Udo schrieb: > Auf die Programmierer von Kfz-Bordcomputern trifft das definitiv zu. > Beispiel: Beim Öffnen der Fahrertür ertönt ein akustisches Warnsignal. > Für wie grenzdebil halten die die Autofahrer eigentlich? Der kleine Udo glaubt also, dass sich die Programmier-Inder selbst die Features und Funktionen ausdenken die sie in die Autos programmieren? Cyblord -. schrieb: > Udo schrieb: >> Auf die Programmierer von Kfz-Bordcomputern trifft das definitiv zu. >> Beispiel: Beim Öffnen der Fahrertür ertönt ein akustisches Warnsignal. >> Für wie grenzdebil halten die die Autofahrer eigentlich? > > Der kleine Udo glaubt also, dass sich die Programmier-Inder selbst die > Features und Funktionen ausdenken die sie in die Autos programmieren? Vielleicht habe ich ja auch nur den falschen Blickwinkel. Möglicherweise dient das Warnsignal nur dazu, den gewohnten Geräuschpegel aufrechtzuerhalten, denn es piepst, pingt oder quäkt ja heutzutage immer irgend etwas. Da würde die plötzliche Stille nur stören. Le X. schrieb: >> Oder auch KISS! > > Aber KISS ist halt Definitionssache. Nicht so ganz. Keep it smart/sound/stupid simple. Einfach ist nicht primitiv oder doof. Sondern so einfach, als daß es die Anforderung der Aufgabe erfüllt. Diese Anforderung kann auch implizit sein, daß die Software wartbar ist. Oder auch nicht! Einfach heißt, keine Anfodrungen erfüllen, die gar nicht existieren. Kein Overengineering! > Der nächste findet es KISS wenn er über eine Parameterschnittstelle > einfach Anpassungen zur Laufzeit machen kann, anstelle an zig Stellen im > Code rumzuwurschteln und alles neu zu bauen. Und nun? Nur dann, wenn diese Schnittstelle auch direkt benutzt wird und nicht irgendwann mal vielleicht nützlich ist. > Die Antwort auf die Frage nach dem besten Programm, dem besten > Programmierstil ist halt ein unbefriedigendes "kommt drauf an". Vielleicht muss man gar nicht nach dem Besten fragen oder streben. Es reicht meistens, wenn es einfach gut ist. Allein das ist oft genug schon nicht der Fall. :
Bearbeitet durch User
Udo schrieb: > Für wie grenzdebil halten die die Autofahrer eigentlich? Das ist doch eigentlich ganz einfach, wenn auch geistig schwächer ausgestattete Leute Autofahrer sein dürfen. Intelligente Leute zu unterfordern, mag diese nerven, aber Leute zu überfordern geht in die Hose. Also sei froh, dass du dich in dieser Frage auf der unterforderten Seite siehst. Betrachtet auch die andere Seite, also Programmierer bzw Gerätedesigner. Die müssen sich vorstellen, wie alle möglichen Fahrer funktionieren, wie sie denken, was sie können. Das ist bei grossem Unterschied im Intellekt keineswegs einfach. :
Bearbeitet durch User
Bruno V. schrieb: > Da ist es kontraproduktiv > Informatiker "Ingenieur" zu nennen, wenn sie zur Technik keinen Bezug > brauchen. Ich betrachte Informatiker nicht generell als Ingenieure. Bradward B. schrieb: >
"Programmierdenke" hat nichts mit der verwendeten Programmiersprache zu tun. Wenn ich will, kann ich auch in C oder Pascal Spaghetticode schreiben. Wer es nicht fertigbringt, ein Problem zu analysieren und in logische Schritte zu zerlegen ( bevor er sich an die Tastatur setzt), wird in keiner Programmiersprache etwas brauchbares zustande bringen. Ich nehme an, Edsger Dijkstra war nur stinkig, dass es da plötzlich eine Programmiersprache gab, die sich in kürzester Zeit auch ohne Hochschulstudium erlernen liess. :
Bearbeitet durch User
Udo schrieb: > "Programmierdenke" hat nichts mit der verwendeten Programmiersprache zu > tun. Es gibt ein eher abstraktes Konzept von Programmiertätigkeit, das allerdings schon ein wenig von Sprachen abhängig, nämlich über Programmierparadigmata. Sprachen wie C oder Pascal gehören zum gleichen Paradigma und die Unterschiede betreffen Details, nicht die Grundprinzipien des Programmierens damit. https://de.wikipedia.org/wiki/Programmierparadigma > Wenn ich will, kann ich auch in C oder Pascal Spaghetticode > schreiben. In Lisp oder Prolog ist das schon etwas schwieriger, sofern man mit Spaghetticode einen explizit spezifizierten Programmablauf meint. :
Bearbeitet durch User
(prx) A. K. schrieb: > Intelligente Leute zu > unterfordern, mag diese nerven, aber Leute zu überfordern geht in die > Hose. Aber gerade die verschiedenen Piepssignale ueberfordern viele. "Warum hat das jetzt gehupt?" Meine Erfahrung in der Programmierung ist, dass einfache Programme auch mit einfachen Programmierkonstrukten und einfachen Sprachfeaturen gebaut sein sollen, waehrend zunehmend komplexere Programme von ausgefuchsten Architekturen profitieren. Die Trennung kann es auch innerhalb eines Programms geben, wo ein eher statischer Kernteil/Bibliotheken mit allen erdenklichen Sprachmitteln ein leistungsfaehiges Grundgeruest bildet, und daran angeflanscht Quick-und-Dirty-Funktionen, die schnelle Aenderungen erlauben und durch ihre Einfachheit auch gut verstaendlich sind. Da verzichtet man dann bewusst auf Vererbung, Interfaces usw. Ein Informatiker, der was auf sich haelt wird sich also eher im hinteren Teil aufhalten und nicht in den Anbauten mitmurksen wollen. Ich weise von mir, in technischen Dingen und allen Details unfähig zu sein zu müssen, bloss weil ich Informatiker bin. :) Das lässt sich bei Eignung durchaus miteinander verbinden. Muss aber nicht. Das gilt auch für Ings. Bloss weil man sich Ing nennen darf, wird man nicht automatisch zum allumfassenden Genie. Auch wenn manche Ings ihren Status zum Anlass nehmen, sich über alles erhaben zu fühlen, das sie nicht verstehen. Grundlagen guter Programmierung inklusive. :
Bearbeitet durch User
Gerade kam mir in den Sinn, noch mal die Softwaremethode des "extremen Programmierens" zu überfliegen: https://en.wikipedia.org/wiki/Extreme_programming Unter Activities->Code sind mir sofort die oben erwähnten nicht-programmierenden Informatiker eingefallen: >The advocates of XP argue that the only truly important product of the >system development process is code – software instructions that a computer >can interpret. Without code, there is no working product. :
Bearbeitet durch User
Falk B. schrieb: > Keep it smart/sound/stupid simple. Die KISS Faustregel ist ein Lieblingskonzept vom Emil P von Bethesda. Der verwechselt aber irgendwie, dass sich das eher auf den Programmcode bezieht, und weniger auf ingame Spielinhalte. So hat das Starfield-Game von Bethesda praktisch die ganzen negativsten Seiten von den Bethesdaspielen aufakkumuliert. Spielspaß? Wer braucht den schon. MS gibt sich durchaus Mühe, da noch was geradezubügeln - aber da hat wohl noch einer ein Bethesdaspiel gespielt. ;) Christoph M. schrieb: >>The advocates of XP argue that the only truly important product of the >>system development process is code – software instructions that a computer >>can interpret. Without code, there is no working product. Die Aussage ist richtig, aber unvollständig und damit falsch. Gerade bei "komplexeren" Softwareprodukten ist das Konzept und die Dokumentation mindestens genau so wichtig. Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.
|
|
Thread beobachten
Seitenaufteilung abschalten