Dieser Episode beinhaltet keine Notizen

Matthias: [00:00:09.64] Willkommen zurück bei einer neuen Ausgabe von der Macht der Craft.

Alex: [00:00:13.29] Heute wollen wir uns erneut mit dem Thema beschäftigen, das den Namen für diesen Podcast gegeben hat.

Matthias: [00:00:19.41] Und uns beiden natürlich auch sehr am Herzen liegt.

Alex: [00:00:22.50] Es soll heute um die Theorie und die Praxis der Software Craft gehen.

Matthias: [00:00:27.96] Dabei soll heute vor allem im Vordergrund stehen, wie wir uns in unserer täglichen Arbeit mit Prinzipien der Software Craft besser zurecht finden können.

Alex: [00:00:35.91] Dann lassen wir mal loslegen.

off: [00:00:40.36] Die Macht der Craft arbeitet für dich.

Matthias: [00:00:47.82] Alles klar? Ja. Wenn wir uns darüber unterhalten, was Software Craft ist, müssen wir uns ja eigentlich auch darauf mal konzentrieren, was Software Craft eigentlich nicht ist. Vielleicht ist das sogar die einfache Frage. Also damit es weniger Missverständnissen kommt.

Alex: [00:01:03.84] Genau. Wir haben in der letzte Folge schon darüber gesprochen mit Andy, was Software Craft so ist und was man damit machen kann. Hm, was meinst du, dass Software Craft dann nicht ist?

Matthias: [00:01:18.33] Also auf jeden Fall ist es keine Zertifizierung, die ich mir irgendwo holen kann und dann bin ich Softwarecrafter. Es ist auch keine Religion, der man angehören kann oder so. Also es ist vollkommen offen für alle Menschen und es hat eigentlich jetzt auch keinen speziellen Bezug zu irgendwelchen Technologien. Also es ist Technologie agnostisch, wenn man so will. Genau. Und letztendlich soll es uns ja einfach auch nur helfen, unseren Job besser machen zu können oder mit mehr Freude machen zu können. So sehe ich das zumindest ein bisschen.

Alex: [00:01:57.68] Ja, ja, ja, ja, total wichtige Aussage. Nicht nur unsere Job besser machen zu können, sondern auch Spaß dabei haben, ist genau um.

Matthias: [00:02:05.46] Dinge, die funktionieren und gut gebaut sind, machen ja deutlich mehr Spaß als Dinge, die nicht funktionieren und so lala gebaut sind. Also da sind wir uns glaube ich alle einig. Naja, und in meiner Erfahrung können halt die Hilfsmittel oder die Prinzipien, die uns die Softwarecraft so ein bisschen mitgibt, dafür nutzen, dass Dinge gut funktionieren und somit auch mehr Spaß machen bei der Entwicklung.

Alex: [00:02:30.12] Okay, aber wenn wir mal kurz darüber nachdenken Wir wissen ja, die ganze Geschichte hat mit diesem Manifesto angefangen. Software-Craftmanship-Manifesto. Aber was steht da drin? Was sind die, die Aussagen?

Matthias: [00:02:48.08] Ja, okay, dann fangen wir noch mal mit dem ersten Punkt an.. Okay. Manifest lautet Not only working software, but also well crafted software. Also nicht nur funktionierende Software, sondern eben auch gut gebaute „well crafted“. Also ich bring da mit sehr viel mit Code-Qualität in Verbindung, also dass sehr gut verständlich ist, dass er nicht unnötig kompliziert ist, sondern dass da halt im Prinzip gewisse Sorgfalt vorgeherrscht hat, als sie entwickelt wurde. Wie siehst du das also?

Alex: [00:03:21.87] Ja, also für mich ist ganz eindeutig der erste Punkt Manifesto ist ganz klar, bezieht sich auf die innere Software Qualität und somit auch auf alles, was Clean-Code betrifft und Qualität und Güte, die unser Code an sich hat. Also jetzt nicht die externen Merkmale, das was, was man von außerhalb sieht, was auch ganz wichtige Themen und Kriterien sind. Aber hier würde ich behaupten, geht es eher darum, dass eben diese Clean Code und alles was drumherum sich bewegt, eingehalten wird und benutzt wird. Das wäre was für mich. Also sich dahinter verstecken, was ich damit in meine tägliche Arbeit mache. Halt.

Matthias: [00:04:09.72] Okay, dann gehen wir doch mal zum Zweiten Punkt über, der da wäre not only responding to change but also steadily adding value. Also auf Deutsch nicht nur auf Änderungen reagieren, sondern auch stetig neue Werte der Anwendung hinzufügen. Und für mich ist es also, wenn ich wieder an meine tägliche Arbeit denke, bedeutet es für mich halt, wenn ich irgendwo zum Beispiel einen Bug fixen muss, weil halt irgendwas nicht richtig funktioniert hat. Das sehe ich, wenn ich was anderes auch noch sehe, was man verbessern könnte. Ist mir halt auch mit anschaue und nicht ignorieren, nur weil es nicht zu der aktuellen Situation gehört. Somit halt auch immer iterativ weiter die Anwendungen verbessern.

Alex: [00:05:02.01] Na, ich sehe da, dass der wichtigere Punkt ist Mehrwert schaffen, so dass wir schnell Mehrwert für den Kunden schaffen. Und das erreichen wir mit Methoden wie vertical slicing oder mit Features. Iterativ verbessern heißt nicht erst einmal alles planen und gucken, wie alles am Ende aussehen soll, sondern einfach mal ein Grundgerüst, eine Grundidee haben, die von oben bis unten durchgeht und die erst einmal implementieren und immer mehr Funktionalität darein packen. Wie ist es den Kunden Wert schafft, die wir haben wollen. Das ist was ich da. Hm. Damit sie also irgendeinen Mehrwert schaffen.

Matthias: [00:05:51.18] Merkt man schon, dass man da ganz unterschiedliche Sichtweisen drauf haben kann. Aber es macht total Sinn, was du sagst.

Alex: [00:05:58.59] Danke.

Matthias: [00:06:01.26] Ähm, aber so habe ich den Satz oder das Statement tatsächlich nie betrachtet. Aber vielleicht habe ich für mich auch einfach nur schlecht übersetzt.

Alex: [00:06:10.20] Natürlich, das was du sagst ist auch nicht falsch, oder?

Matthias: [00:06:13.02] Ja klar.

Alex: [00:06:14.10] Auch eine wichtige Tätigkeit, die wir da durchmachen. Aber da wäre ich eher bei beim ersten „well crafted“, ja, immer wieder verbessern. Hm. Natürlich kann man auch da reinpacken in den zweiten, aber warum auch nicht? Aber das machen wir nicht, weil es schön ist und weil es cool ist und weil es modern ist, sondern weil es uns erlaubt, bessere Software, bessere Ergebnisse für unsere Kunden zu erzielen. Wir können schneller arbeiten. Wir können sicherer arbeiten.

Matthias: [00:06:52.21] Okay. Haben wir zu dem Punkt noch was oder sollen wir zum nächsten.

Alex: [00:06:55.24] nö, könn ma rüber.

Matthias: [00:06:57.25] Da hätten wir dann not only individual and interactions, but also a community of professionals, also nicht nur Individuen und Interaktionen unter diesen Individuen, sondern eben auch eine Community von professionellen Entwickler, Entwicklerinnen. Genau. Für mich ist da ganz viel, über das wir auch schon ganz oft geredet haben. Also einfach W issen teilen mit anderen untereinander, wenn man im gleichen Team ist und ja, sich austauschen, Probleme aufzeigen, eventuell gleich Lösungen und so einfach auch das Wissen, das man in seiner täglichen Arbeit so erlangt hat. Weil häufig ist es ja doch so, dass man auf Probleme stößt, die man in irgendeiner Weise lösen muss. Und man unterschätzt häufig, wie viele andere Menschen auf die gleichen Probleme stoßen und wie viel Stunden die sparen können, wenn die Lösung dafür an einer geeigneten Stelle hinterlegt ist.

Alex: [00:07:59.95] Für mich hat dieses Prinzip zwei Aussagen in sich, die mit meiner täglichen Arbeit tatsächlich zu tun haben. Der eine ist Professionalität. Und der zweite ist dieser Austausch. Also ein bisschen teilen, wie du gesagt hast. Das sind die zwei Komponenten, die für mich in diesem Prinzip stecken. Und bei der Arbeit bedeutet das nicht bunkern, Wissen teilen, mit, mit dem ganzen Team, mit dem Kollegen, auch außerhalb des Teams und vor allem aber diese wissensteilen Komponente ist total wichtig. Wir lernen nie aus. Es gibt immer irgendwas Neues in der Branche und irgendwas, was wir noch lernen können oder wo wir uns verbessern können. Und das gehört für mich auch hier drin in diese, in diese Prinzip immer sich weiter zu bilden, neues Lernen, das was man kann vertiefen und das nicht einfach im Keller alleine machen, sondern mit anderen Menschen. Weil das ist wahrscheinlich wie du am besten lernen kannst, von anderen Menschen lernen und deren Erfahrungen, die ich haben, die du gesagt hast. Wahrscheinlich die Probleme, die du jetzt hast, wahrscheinlich auch schon mal gehabt. Und es gibt Lösungsansätze, die du da lernen kannst, wie man das machen kann.

Matthias: [00:09:33.76] Oder eben auch teilen, wenn man selber natürlich gelöst hat und vorher keine Lösung gefunden hat in zum Beispiel den internen Dokumentationen dahingehend auch wieder einen Mehrwert schaffen. Natürlich, aber in dem Sinne jetzt nicht für ein einzelnes Produkt, sondern eben für alle, die noch Zugriff haben und das genauso nutzen.

Alex: [00:09:57.89] Ja, ja, durchaus ein wichtiger Aspekt. Finde ich schon, schon. Was für mich zumindest Craft bedeutet. Ja, also ein wichtiger Aspekt oder einer der wichtige Aspekte von die ganze Geschichte. Softwarecraft ist für mich diese, diese Austausch, diese Wissensvermittlung und dieser Wissensaustausch. Okay, und dann der der vierte und letzte, ja.

Matthias: [00:10:26.21] Der letzte Punkt, genau der lautet not only customer collaboration, but also productive partnerships. Also nicht nur mit meinen Kunden zusammenarbeiten, was eh schon wichtig ist, sondern eben aber auch eine produktive Partnerschaft dabei zu haben. Also, dass ich quasi nicht nur Sagen, Anforderungen und Bugs von meinem Kunden bekomme, sondern dass man da eben in einem besseren Austausch ist, also dass man vielleicht auch Dinge zusammen erarbeiten kann und vor allem Feedback von echten Kunden bekommen. Das ist dann auch immer Gold wert.

Alex: [00:11:08.66] Das heißt, für mich ist eine der zentralen Themen in diesem und diesem Punkt Kundennähe. So nah an den Kunden arbeitet sich du sagst Feedback vom Kunden wirklich holen, frühzeitig auch mit dem Kunde zusammenzuarbeiten. Das hat ein Kunde auch mal gesehen zu haben. Ich meine, in echt. Nein, nein. Also nun nicht nur wissen, dass es den gibt, sondern den auch mal gesehen haben mit dem gesprochen haben als als Entwickler. Es ist auch eine eine gute Sache, weil das das Verständnis verbessert von was er will und wie wir das machen können. Nicht nur über irgendeine dritte Person immer die Informationen bekommen. Der Kunde hat gesagt, weil was der Kunde gesagt hat und das was wir vermittelt bekommen und das, was wir dann am Ende verstehen, sind nicht unbedingt immer das Gleiche. Das hat sich in vielen, vielen, vielen Jahren, vielen Projekte gezeigt. Das ist nicht unbedingt immer das Gleiche ist. Deswegen, wenn man mit dem Kunden arbeiten kann, das ist ein total im Vorteil für alle, für den Projekt, für das, was wir gerade machen, weil der Kunde sieht, wo wir hinlaufen. Wir können besser verstehen, was vermittelt wird, was unsere Arbeit ist. Ja, ich denke, das ist, das wäre für mich die die Quintessenz von von diesem Prinzip, dass das, was tatsächlich praktisch zu tun wäre.

Matthias: [00:12:48.97] Das ist eine schöne Zusammenfassung. Also ich kann auch nur sagen, dass es einfach total Sinn macht. Also wie gesagt, den Kunden mit Respekt zu behandeln, weil dann wird man selber vielleicht auch mit mehr Respekt behandelt. So Dinge, die er vielleicht haben will, die man selber nicht zu haben wollen würde, kann man gern beraten, aber halt ihn nicht irgendwie abfällig behandeln oder so was eh klar.

Alex: [00:13:16.82] Ist, muss das sowieso nicht sein.

Matthias: [00:13:19.82] Aber das ist halt auch Ebene. Man soll eben gut mit seinen Kunden zusammenarbeiten, produktiv.

Alex: [00:13:28.04] Vor allem zusammen. Also ich kenne Projekte, wo, wo ich gewesen bin, wo ich gearbeitet habe, wo ich meine den Kunden noch nie zu Gesicht bekommen habe, wo ich wo, wo ich wusste, dass es einen Kunden gibt, aber den habe ich noch nie gesehen. Hm, die das könnte auch irgendwas virtuelles sein, die Sekunde nicht nicht existent und so, weil ich noch nie mit dem gesprochen hatte oder gesprochen habe, weil immer dazwischen irgendeine Schicht war, die sich darum gekümmert hat. Damit will ich nicht sagen, dass diese Menschen, die, die diese Tätigkeiten ausführen, nicht notwendig sind. Das sind sie auch, aber diese komplett die Entwickler abkapseln und die sollen den Zeug programmieren und sich nicht um alles andere kümmern. Das glaube ich, funktioniert nicht wirklich gut.

Matthias: [00:14:20.33] Wenn dann nur in Ausnahmesituationen.

Alex: [00:14:22.76] Ja und dann auch nicht. Also dieser Kontakt hilft auch, die Qualität unserer Produkte zu verbessern, weil wir auf den direktem Weg die Informationen bekommen. Es um wie gesagt, das bedeutet nicht, wir wussten diese Menschen, die sich zwischen die, die in eine klassische Entwicklungsvorgehensweise zwischen den Kunden und in der Entwicklung waren, müssen wir sie nicht loswerden. Wir müssen versuchen, alle gemeinsam zu arbeiten. Formate und Methoden finden, in dem wir alle gemeinsam mit dem Kunden zu Lösungen für den Problemen, die wir haben, kommen. Und das ist für mich, was sich dahinter verstecken kann.

Matthias: [00:15:09.50] Wenn man sich das jetzt noch mal so alles überlegt, was wir dazu gesagt haben, finde ich da also in meinem Kopf kommt da immer wieder das Wort Professionalität auf. Also für mich hat es alles, was mit professionell arbeiten zu tun, was wir jetzt so im Manifest gefunden haben, sozusagen. Aber was macht jetzt Professionalität aus? Also es wäre auch noch eine interessante Frage.

Alex: [00:15:34.61] Und was wäre deine Antwort darauf?

Matthias: [00:15:37.82] Na ja, also ich kann natürlich nur für mich selber sprechen. Also für mich hat es ganz viel mit Verantwortung übernehmen zu tun für das, was ich halt mache in meinem täglichen Doing. Das ist mir nicht egal ist, was aus einem Feature eine Anwendung oder sonst was wird, sondern dass ich halt mit einem professionellen Anspruch daran gehe und das Beste rausholen will.

Alex: [00:16:04.70] Kannst du es mir anders erklären? Ja.

Matthias: [00:16:09.25] Ja. Was meinst du mit anders?

Alex: [00:16:10.67] Also ja, du hast die diese Professionalität definiert, in der du professionell dran gehst.

Matthias: [00:16:18.89] Ja. Okay.

Alex: [00:16:22.25] Ja. Also Verantwortung übernehmen. Was bedeutet für dich Verantwortung übernehmen?

Matthias: [00:16:27.41] Na ja, wie gesagt, dass es mir nicht egal ist, was aus einem Feature oder einer Anwendung wird. Also, ich will immer schauen, dass ich nach bestem Wissen und Gewissen das Beste aus dem, was gerade für mich zu tun ist, raushol.

Alex: [00:16:48.11] Qualitativ meinst du.

Matthias: [00:16:50.42] Qualitativ. Aber auch jetzt – nehm wir mal ein praktisches Beispiel. Also ich würde jetzt nicht nur weil es fancy ist, irgendeine bestimmte Sprache einsetzen, weil mir das gerade irgendwie in den Kram passt und weil ich die eh schon immer mal lernen wollte, sondern ich würde in meiner täglichen Arbeit insofern Verantwortung übernehmen, dass ich da eine Sprache halt nehmen, die Sinn ergibt für das Problem, für die Gegebenheiten, also das Team, was die Leute können und so halt.

Alex: [00:17:26.33] Ja, okay, mit. Verstehe ich also, was du meinst. Ja Verantwortung übernehmen. Was bedeutet das für mich? Es bedeutet für mich, dass wir sozusagen die Pflicht haben. Aber das ist vielleicht ein bisschen falsch ausgedrückt, dass wir uns für das, was wir tun, voll reinknien müssen. Also wir sollen nicht halbe Sachen machen, wir sollen das bestmögliche Ergebnis für unsere Kunden und für unsere Kollegen, Mitarbeiter, Freunde halt auf die Reihe bekommen, sodass dass wir wirklich nicht Halbgares in die Welt setzen, sondern irgendwas mit Sinn und Verstand, wo wir uns Gedanken darüber gemacht haben, wo wir das auch so gut auf die Reihe bekommen haben, wie es möglich war, immer mit dem Abwägen, Kosten, Nutzen usw., so dass diese Kriterien alle balanciert sind, um zu der höchstmögliche innere und äußere Qualität führen. Was denkst du dazu?

Matthias: [00:18:45.77] Ja, klingt gut.

Alex: [00:18:49.43] Sagt auch was oder war nur Leere Gelaber?

Matthias: [00:18:52.01] Genau das muss ich mir glaub ich noch mal anhören. Nee, aber ja, ich meine, es ist halt doch letztendlich schwer zu erklären, was bedeutet Verantwortung übernehmen? Also es ist ja gar nicht so einfach, denn sonst würde es ja auch jeder machen, wenn es so einfach wäre.

Alex: [00:19:10.97] Es soll aber ja jeder machen.

Matthias: [00:19:12.59] Dann muss es einfach werden. Na ja, also letztendlich würde ich halt einfach sagen schaut, dass ihr halt am Ende des Tages das Beste macht, was ihr könnt.

Alex: [00:19:24.20] Einfach einen Job hinlegen, wo man.

Matthias: [00:19:27.38] Guten Gewissens.

Alex: [00:19:29.30] Wenn schon nicht, wenn schon nicht stolz drauf sein soll, zumindest erhobenen Hauptes nach Hause gehen kann.

Matthias: [00:19:37.58] Ja, genau.

Alex: [00:19:39.44] Ohne sich schämen zu müssen, was da entstanden ist oder so. Also schön in der Richtung halt. Ich denke aber auch, Verantwortung und innere und äußere Qualität sind auch im Auge des Betrachters.

Matthias: [00:19:53.30] Na klar, wie man Verantwortung übernehmen kann. Auf der anderen Seite auch bedeuten, dass ich, wenn ich einen Fehler gemacht habe und irgendwo irgendwie richtig Mist gebaut habe, dass ich das halt nicht versucht zu vertuschen, sondern halt dazu stehe. Daraus lerne.

Alex: [00:20:08.66] Natürlich.

Matthias: [00:20:09.41] Und versucht das in Zukunft halt anders zu machen. Das kann auch Verantwortung sein.

Alex: [00:20:13.94] Ja. Das nächste ist das, was wir immer so gerne immer wieder erwähnen lernen. Professionelle Softwareentwicklung kommt nicht ohne ständiges und dauerhaftes Lernen aus. Das heißt, wir müssen immer wieder was Neues lernen. Habe ich vorher auch, glaube ich erwähnt. Und das hört nie auf. Es gibt immer, sowohl technisch als auch methodisch, Neue Sachen, die wir lernen können, die wir lernen sollen, damit wir dann tatsächlich auswählen können, was gerade am besten ist für für das Problem, die wir lösen wollen. Das bedeutet eben für mich, dass wir einiges an Zeit aufwenden, um uns weiterzubilden, um Neues zu lernen, um die Zusammenarbeit im Team besser zu gestalten. All diese Sachen gehören für mich auch zu diese professionelle Arbeitsweise. Im Team arbeiten, gemeinsam arbeiten und immer uns auch alle gemeinsam weiterbilden. Es ist eine ganz coole Sache. Natürlich kann jeder für sich lernen, was er möchte, aber auch gemeinsam lernen. Gemeinsam Neues zu entdecken ist eine ganz interessante Übung für mich innerhalb der Teamdynamik und der Teamarbeit. Ein ganz wichtiger Aspekt von das, was wir tun. Und das machen wir tatsächlich. Es ist nicht nur daher gesagt, dass wir lernen sollen, sondern wir tun es auf der einen oder andere Weise. Sowohl als Einzelmensch als auch als Ding.

Matthias: [00:22:01.81] Genau. Und wie eben auch bei dem Thema Verantwortung übernehmen ja auch schon gesagt. Auch aus Fehlern sollte man lernen. Also ein Fehler ist erst ein Problem, wenn ich ihn wiederhole. Deswegen versuche ich tatsächlich, Fehler immer nur einmal zu machen. Und auch wenn ich irgendwelche Probleme gelöst habe, wie vorhin auch schon mal erwähnt, dann versuche ich die halt instant zu dokumentieren und an einer Stelle, die für alle klar ist, häufig zum Beispiel die Readme-Datei des Projekts oder so was, wo dann solche, was weiß ich, dann beim Einrichten der IDE irgendwas ganz besonderes zu beachten ist oder so, das sollte halt irgendwo stehen, wo es dann wichtig ist. Und ich finde auch, das können immer Learnings sein. Weil je weniger mich andere Leute fragen müssen, wie ein bestimmtes Problem zu lösen ist, desto mehr Zeit habe ich für andere Dinge, zum Beispiel andere Sachen lernen. Und wie gesagt, auch bei wenn ich Wissen teile, lerne ich ganz viel. A zum Beispiel wie ich Wissen vielleicht besser vermitteln kann. Ich lerne den Menschen, dem ich das Wissen vermittle, besser kennen, weil ich muss ja mit ihm interagieren. Also es hat ganz viele Vorteile und also für mich gehört es auch schon immer dazu. Lernen, lernen, lernen, entweder aus Erfahrungen oder eben weil man sich mal mit irgendeinem neuen Problem auseinandersetzen muss.

Alex: [00:23:29.86] Mit welch auch immer. Geeignete Methode zum Lernen, aber. Aber das Lernen an sich ist das.

Matthias: [00:23:36.31] Für die Lernmethoden haben wir ja eine eigene Folge.

off: [00:23:38.65] Ja genau.

Alex: [00:23:41.68] Ja, also wir lernen stets Neues und das gehört zu der zu diese professionelle Haltung des Thema Lernen. Ganz wichtig, ganz alltäglich. Irgendwas, was wir dauernd machen und die wir nicht vergessen sollen. Und es gehört irgendwie einfach dazu. Also es ist nicht irgendwas, was wir trennen von unsere tägliche Arbeit als professionelle Softwareentwickler, sondern es ist das Lernen gehört einfach zu dem Prozess. Somit werden wir auch auf den Thema Austausch, Wissensvermittlung so ein ganz wichtige Aspekt, die jede Softwarekrafterschafterin umarmen muss. Ja.

Matthias: [00:24:32.81] Sehr schön formuliert.

Alex: [00:24:34.30] Ja. Ist Wissen austauschen. Also Sie wollen Neues lernen? Das haben wir ja im letzten Punkt. Aber auch das Wissen, das man selber hat, die Erfahrung, die man selber hat, mit anderen zu teilen. Das ist auch für mich ein wichtiger Aspekt. Wir sollten nicht nur kodieren, nicht nur lernen, sondern auch geben. An anderen Kollegen, an dein Team, an andere Menschen, an andere Software Crafter, deine Erfahrungen teilen, dein Wissen weitergeben, damit auch andere davon profitieren können. Wie hast du ein Problem gelöst? Oder wie kann man so irgendwas machen? Und es ist immer ein gutes, ein gutes Thema, um andere Menschen mal was neues beizubringen, damit sie mal auch was anders sehen über den Tellerrand oder über die eigene Methoden und Formate sehen. Sie ist für mich auch ein zentraler Aspekt und das was wir tun.

Matthias: [00:25:32.86] ja, und anfangen würde ich persönlich tatsächlich im eigenen Team einfach da schauen, dass man auch eine Kultur des Wissensaustausches entwickeln kann. Also, dass man nicht der der Einzelkämpfer ist, der versucht, die Prinzipien hochzuhalten, aber sich abmühen muss oder so, sondern zum Beispiel durch klassisches lead by example einfach vorzuleben, wie so was vielleicht auch mit mehr Freude am Job vonstatten gehen kann, um einfach auch Leute damit auch ins Boot zu holen. Und in meiner Erfahrung ist es tatsächlich so Wenn man selber mit seinem Wissen relativ frei umgeht und es auch anderen Leuten anbietet, dann kommt auch letztendlich was zurück.

Alex: [00:26:19.03] Behalte dein Wissen nicht für dich, sondern gibt es einfach weiter, weil das hilft den gesamten Team, aber auch andere Menschen in kleineren Konferenzen, MeetUps, was auch immer, wo man hingeht, da kann man auch gerne auf die eigenen Erfahrungen zurückgreifen und den Menschen irgendwas erzählen. Das muss ja nicht das beste Beispiel. Es muss ja nicht die der heilige Gral der Softwareentwicklung werden. Einfach nur sich austauschen und voneinander lernen ist völlig ausreichend und wichtig, und relevant in meinen Augen. Mit gutem Beispiel vorangehen, dass man sieht, das ist kein Lippenbekenntnis, sondern das kann man tatsächlich machen produktiv. Das funktioniert auch.

Matthias: [00:27:10.21] Genau. Und zu guter Letzt stellt sich dann aber für mich noch immer die Frage wie viel brauchen wir letztendlich dann davon?

Alex: [00:27:17.29] Hmm.

Matthias: [00:27:18.19] Also man kann da wieder so ein Stichwort Pragmatismus in den Raum werfen.

Alex: [00:27:23.41] Also das ist für mich total wichtig, Ja, weil all diese Theorien und all diese Methoden und all diese Prinzipien und was auch immer, alles schön und gut, aber man soll die Sache pragmatisch anpacken und sagen, das heißt, man soll nicht immer alles zu 100 % mit alle Prinzipien und alle Methoden anwenden, wie es geht, weil sonst kommst du nicht zu Potte. Du, du, du, du schaffst dann halt gar nix. Sondern pragmatisch die Sache angehen und so viel Qualität, so viel Kraft, so viel Hirnschmalz daran verwenden, wie es notwendig ist, damit die Sache rund wird und sich nicht künstlerisch da irgendwie länger aufhalten, als es notwendig ist. So viel Qualität reinbringen, wie wir tatsächlich brauchen.

Matthias: [00:28:17.20] Wo man auch wieder den Bogen zur Professionalität schlagen kann. Hm, also vielleicht ist es auch eine Form der Professionalität, dass man eben diesen gewissen Pragmatismus an den Tag legen kann und eben nicht auf allen möglichen rum reitet, nur weil es irgendwo irgendjemand gesagt hat, dass es anders wäre. Wichtig ist tatsächlich, dass am Ende des Tages die Anwendung funktioniert und gut gebaut ist. Und genau und das.

Matthias: [00:28:48.52] Bestmöglichen Zustand, was halt aber auch die Umgebung zulässt. Also ich meine, auf vieles haben wir auch einfach keinen Einfluss.

Alex: [00:28:57.61] Und nicht verharren die Prinzipien zu 100 % immer und überall Anwendung zu müssen und zu wollen, sondern eben die Sache pragmatisch anpacken und wir müssen auch was liefern. Wir müssen auch ein gewisse Deckungsbeitrag erzielen. Wir müssen einfach abwägen, wie viel Zeit für was wir anwenden können. Und das ist für mich einfach, die Sache pragmatisch anzugehen, nicht nicht dogmatisch. Alle Prinzipien und alle Methoden und alle was auch immer regeln.

Matthias: [00:29:33.34] Solang ich die Verantwortung übernehmen kann. Um nochmal einen kleinen Bogen zurück zurückzufinden.

Alex: [00:29:38.98] Ja, natürlich.

Matthias: [00:29:40.18] Natürlich kann ich natürlich frei entscheiden, wie weit ich diese Prinzipien verfolge. Aber ich muss halt die Verantwortung dann auch dafür übernehmen. Wenn ich entscheide, XY nicht gemacht zu haben, dann hat es irgendeinen Grund und zu dem muss ich halt stehen.

Alex: [00:29:58.03] Was für mich auch ein Punkt ist in diese Richtung und diese pragmatische Richtung geht, ist, obwohl ich hohe Qualität in alle Bereiche abliefern will. Es ist tatsächlich so, dass es Bereiche in meinen Code oder meine Anwendungen, die potenziell zumindest eine höhere Wahrscheinlichkeit haben, sich zu verändern und ich versuche, den Fokus an dieses Stellen zu setzen, da deutlich mehr zu investieren. Das werden die Stellen, wo wir höchstwahrscheinlich wir weiterarbeiten müssen, wir öfters was ändern müssen. Usw. und so fort. Und deswegen ist dort durchaus die Qualität ein Tick wichtiger als zum Beispiel an einer Stelle, wo keine große Änderungen zu erwarten sind. Natürlich bedeutet nicht, dass an dieser Stelle in Qualität nicht wichtig sein und wir unsere Kraft nicht dort anwenden sollen. Das ist es nicht, weil es hat sich auch im Leben gezeigt. Die Sachen, die man dachte, es wird sich nie ändern, dann ändert sich doch irgendwann.

Matthias: [00:31:11.47] Es kommt immer anders als du denkst.

Alex: [00:31:13.48] Aber an den Stellen, wo du weißt, dass du öfters rumschrauben werden musst, da besonders achtzugeben, das sind die Stellen, wo wo man tatsächlich drauf achten muss, um vielleicht ein bisschen mehr Zeit verwenden sollte, um diese innere Qualität ein bisschen weiter zu fördern als an Stellen, wo die Änderung oder der Änderungspotenzial nicht so groß ist.

Matthias: [00:31:42.59] Volle Zustimmung.

Alex: [00:31:43.78] Auch sehr persönliche Meinung. Das ist irgendwas, was was ich gerne in meine in meine Projekte machen. Also nicht überall alles zu 100 % picobello. Goldene Wasserhähne.

Matthias: [00:31:55.63] Sondern ja pragmatisch.

Alex: [00:31:59.74] Abwägen, abwägen und dann entsprechend handeln.

Matthias: [00:32:07.46] Genau. Ja, so ein schöner Abschluss eigentlich. Ja. Wir haben heute nicht nur darüber gesprochen, was Softwarecraft ist.

Alex: [00:32:17.21] Sondern auch, was es nicht ist. Und das ist genauso wichtig.

Matthias: [00:32:22.67] Aber wie immer gilt Abonniere unseren Podcast, falls du es noch nicht gemacht hast. Und dann wirst du auch nie wieder eine Folge verpassen.

Alex: [00:32:29.99] Und ganz gerne auch mit deiner Kollegen teilen, damit sie wichtige Themen oder Themen, wo sie interessiert sind, sich anhören können und weiterverbreiten können.

Matthias: [00:32:40.85] Und sei auch das nächste Mal wieder dabei, wenn wir uns mit sauberem Code beschäftigen. Und wir freuen uns auf dich.

Alex: [00:32:47.42] Okay, also ciao. Bis dann.

Matthias: [00:32:50.12] Ciao.

Off: [00:32:54.12] Die Macht der Craft arbeitet für dich.