Vielen Dank, dass Du dieses Thema öffentlich machst. So eine Debatte hätte ich mir schon vor 20 Jahren gewünscht. Es ist nicht notwendig, alles im Leben perfekt zu gestalten, sondern es ist ausreichend, Dinge gemäß den jeweiligen Bedürfnissen und Anforderungen angemessen gut zu erledigen.
Man sollte auch nicht vergessen, dass dieser iterative Prozess überall in der Entwicklung angwendet wird und auch darüber hinaus. Nicht umsonst wird auch bei der Hardwareentwicklung alle paar Jahre eine neue Generation herausgebracht. Man muss sich damit abfinden, dass man nicht optimal entwickeln kann, da man bestimmte Einflüsse nicht kennt und manche Vorgaben (Zeit, Tools), die es einem auch nicht erlauben nach bestem Wissen perfekt zu entwickeln. Wichtig ist, dass es gut genug ist, um die Anforderungen zu erfüllen und anschließend kann man sich entscheiden, ob nochmal nachgebessert werden muss. Fakt ist, dass man enorme Marktanteile verlieren kann, wenn man zu langsam entwickelt und dann der beste Algorithmus, an dem man ewig gefeilt hat, leider die Masse nicht erreicht. Es ist viel wichtiger geworden erst die Masse zu erreichen, zu sehen, was die Kunden wirklich nutzen wollen und dann sich an die quality of life improvements zu machen.
Volle Zustimmung! "Wenn man weiß, was man tut, darf man schlampen." Gruß vom Ingenieur, der gerne Code schreibt, um Zeit bei seiner Alltagsroutine zu sparen.
Pair programming hatte ich im Studium und ich muss ehrlich sagen, es war bisher meine bevorzugte Art zu programmieren. Erfahrungsgemäß hat meist die andere Person genau die Lösung für das Problem, bei dem man selbst ewig auf der Stelle trampeln würde und anders rum. Man kann Fehler in der Logik und im Code früh entdecken und beheben. Zudem hilft es ungemein bei der Motivation, was echt viel Wert ist.
Sehr gut. Ich unterscheide 3 Entwicklungsstufen eines Programmierers. Der Stufe 1 Programmierer schreibt einfachen Code, weil er nicht anders kann. Der Stufe 2 Programmierer schreibt komplizierten Code, weil er es kann. Der Programmierer der 3. Stufe schreibt einfachen Code, weil er es kann. Er muss nicht zeigen, dass er dieses oder jenes Feature kennt. Der Code ist idealerweise so, dass ein anderer drauf schaut und sagt: ja, so hätte ich es auch gemacht. KISS.
Oh Gott bei meiner alten Arbeit gab es per Prozess (dummes Quartalsdenken) so viele technische Schulden, dass ich kündigen musste. Dieser Code hat mich in die Depression getrieben.
Deadlines können auch zum Burnout führen, weswegen sie vermutlich auch Deadlines heißen oder der Begriff das Wort Dead beinhaltet. Das KISS-Prinzip mag für eine effiziente Softwareentwicklung unerlässlich sein, aber Ideen, Wünsche und Vorstellungen sind zu jeder Zeit viel vielfältiger als irgendeine Umsetzung es jemals berücksichtigen könnte.
Diese Thematik ist nicht nur in der IT ein großes Problem. Ich habe mehrere Jahre in der Qualitätskontrolle eines Biotechunternehmens gearbeitet. Es wurde mit einem Qualitätsmanagementsystem (QMS) gearbeitet, quasi einer Betriebsanleitung für die einzelnen Arbeitsprozesse und Zuweisung der Zuständigkeiten. Problematisch wird es nicht nur wenn sich nicht an das QMS gehalten wird, sondern auch wenn diese Betriebsanleitung nicht dynamisch an die Anforderungen angepasst wird. Dafür ist die angesprochene Kommunikation wichtig und ein Verständnis der "Führungsriege" für QM. PS: Ich arbeite dort nicht mehr 😏, weil das QMS nur ein schickes Gütesiegel war um die Kunden ruhigzustellen.
Es gibt einen Trade-off zwischen schnell und überlegt Code zu schreiben. Schnell schreiben bringt einen schnell in Kontakt mit den echten Problemen, d.h. man versteht das Problem schneller besser und findet im Zweifel sogar schon eine Lösung. Es führt aber zu schlechter Qualität im Code, was sich mit der Zeit ansammelt bis der Code irgendwann mehr Fehler enthält und schwerer zu verstehen und zu ändern ist. Gleichzeitig braucht man aber oft ein besseres Verständnis, bevor man hochwertigen Code schreiben kann, und der beste Weg das zu erreichen ist, schnell und schlampig seine Ideen einzubauen. Dabei deckt man Probleme bei seinem internen Modell auf (Missverständnisse) und kann lernen und das Design weiterentwickeln. Irgendwann hat man eine schlampig implementierte Lösung und an dem Punkt sollte man sich die Zeit nehmen und den Code aufräumen und schön machen. Sonst wird es später unmöglich "mal eben schnell" eine Idee zu implementieren weil einem ständig die Schlamperei von letztem Jahr auf die Füße fällt.
Hi Morpheus, Light hier. Es ist schön zu sehen, dass Du das alles erwähnst und erklärst. Aus meiner Perspektive siehst Du noch relativ jung aus, daher meine Frage. Hast Du das alles selbst erfahren, hast es also über den harten Weg gelernt, oder gab es auch bei Dir einen Mentor, der Dir das eine oder andere an Erfahrung erspart hat und Dich um so manches Problem geschifft hat? Musst nicht antworten, ich bin jedoch neugierig. BTW Frohe Ostern.
Leider sowohl als auch.. Auch wenn ich jung aussehe lernt man in über 10 Jahren dann doch einiges^^ Und fairerweise hat's bei mir schon früher angefangen und vieles kam auch in Dialogen mit anderen zum Ausdruck
Danke für dein Video! Die Problematik klingt nach "ich habe Angst, später nichts mehr ändern zu können". Aber eigener Code ist keine Fremdbibliothek: was fehlt oder nicht passt, könnt ihr einfach ändern. Solange ihr vermeidet, es zu Public API zu machen. Was es auch gibt: ständig in neue Bereiche zu kommen und zu wenig zu fragen, ob ich das grade richtig mache. Wo KISS vermeiden: bei Sicherheit. Allgemein: bei Anforderungen, bei denen eine Unterschätzung der Anforderung eine Katastrophe bedeutet, nutz KISS lieber nicht, sondern stell sicher, dass du genau weißt, was wirklich die Anforderungen sind und überschätz sie lieber. Sicherheit, Datenschutz - all das, bei dem du als Entwickler die Last Line Of Defense bist.
komplizierter ist nicht sicherer. Einfacher Code ist in der Regel einfach zu kontrollieren und zu überprüfen. Es ist wie eine Maschine: Je weniger Teile sie hat, desto weniger Teile können kaputt gehen.
Das kenne ich leider zugut. Ich habe mich gestern den ganzen Abend darin verloren, die Animation einer Tabellenzelle (User ändert Eintrag in der Tabelle => optisches Feedback) anzupassen, bis ich zufrieden war. Sie war bestimmt schon beim zweiten oder dritten Versuch ausreichend elegant. Vielleicht hast du mal was vom Pareto-Prinzip gehört. Das trifft auf viele Entwickler zu..
Wer hat auch schon mal ne Stunde überlegt, wie man die Variable nennen soll, und dann hieß sie später einfach v? Bzw. man überlegt ob man "var v" schreibt oder doch x oder a...
Kann Pair-Programming gerade am Anfang sehr empfehlen. Finde Schade dass die Uni sowas bei einfachen Projekten erzwingt, da wärs wirklich nicht notwendig....
@@Hofer2304 Der Vorteil wurde mir z.B. erst wirklich klar bei schwereren Aufgaben, wenn man extrem einfache Programme im Pair-Programming macht wirkt das Konzept komplett useless, da man es schneller alleine hätte machen können.
@@Timm2003 Die Vorteile von Pair-Programming kommen auch erst bei schwierigen Problemen zumTragen. Aber wie verläuft die Kommunikation zwischen den Teilnehmern? Sitzt man am besten wirklich gleichzeitig vor dem Bildschirm oder schreibt man ein kleines Stück Code und lässt es dann kritisieren? Wie oft passiert der Rollenwechsel? Alle fünf Minuten oder täglich? Wie wird die Entwicklungsumgebung am besten genutzt? Welche Funktionen stehen zur Verfügung? Wenn das alles bei Spielzeugprojekten gut funktioniert, kann jeder seine volle geistige Kapazität für eine Lösung anspruchsvoller Projekte verwenden.
@@Hofer2304 Hab bisher nicht viel damit gemacht, wie das ganze daher im Alltag aussieht kann ich nicht wirklich beantworten, bei mir war es so, dass wir ca. alle halbe Stunde gewechselt haben, ein Bildschirm, eine Maus und eine Tastatur hatten und uns während des Schreibens unterhalten haben. Das war allerdings auch ein Workshop mit noch nicht so sehr erfahrenen Programmierern, daher wie gesagt, kann ich es nicht ganz beantworten.
Ich wollte mal ein Programm bauen dass den Twitch Chat über die MS Speech API vorlesen kann. Ich habe jetzt ein Twitchbot mit einem MP3 Player, einem Pluginsystem, JSON Formbuilder und bereits erstellte Plugins wie Google Translate oder Twitch Chat im Greenscreen-Fenster 😅
Ich habe Perfektionismusprobleme beim Lernen. Ich muss irgendwie versuchen soviel wie möglich kleine Details von einer Programmiersprache oder Framework zu lernen
Was ich hier völlig vermisse ist das ausreichende "Kommentieren des Codes" und das deckt sich ja auch mit der Realität. Weiterhin macht es einen großen Unterschied ob man angestellt ist oder in Eigenverantwortung arbeitet.
Super spannendes Thema, danke für die gute Zusammenfassung. Allerdings ist mir während des gesamten Videos aufgefallen, dass du nicht "flüssig" sprichst, also als ob du noch ein Text im Hintergrund ablesen würdest bspw. Hier und da wirkte es dann so als seiest du nicht sicher über die Aussagen, weils sie dann so "abgehackt" kommen. Aber an und für sich super informatives Video. Es hilft vorallem Studenten wie mir, die relativ Unsicher sind, was später von uns erwartet wird im Berufsleben.
@@Hofer2304 Für den RU-vidr sorgt es dafür, dass durch "Zurückspulen" der User mehr Viewtime zustandekommt und die Verweise auf andere Videos ebenfalls mehr Viewtime bringen. Für den User sorgt es dafür, dass die Information griffbereit beim richtigen Zeitstempel erscheint. Das mit der Videobeschreibung klappt nie so richtig, bei niemandem. 😄
