Des Pudels Kern

David Tielke stellt in diesem Viedo seine Kriterienskala vor, nach der er das Niveau von Softwareentwicklern bewertet und ich muss eingestehen, dass ich nach dieser Skala nicht über Level 1 hinauskomme.80 % Prozent GUI / Frontend-Skills kann ich nämlich nicht vorweisen. Vor etwa 15 Jahren hätte ich das vielleicht gekonnt, aber da habe ich die Kriterien des ersten Levels - sauberen Code zu schreiben - noch nicht erfüllt.(Okay, ideal sauber ist mein aktuell geschriebener Code immer noch nicht, aber auf jeden Fall besser als das, was ich damals verbrochen habe).

Wie ist die letzte Wochen beruflich verlaufen? Nachdem uns die Problemstellung aus verschiedenen Kundenperspektiven dargestellt wurde, stellte sich uns die Frage, wie wir nun weiter machen, um eben dieses Problem zu lösen. Befindet man sich im Chaos und weiß erst einmal nicht weiter, lautet die Devise: Handel! Wir führten ein Brainstorming durch, bei dem jedes Teammitglied Ideen für Arbeitspakete aufschreiben sollte, die sich seiner Meinung nach aus dem bisher Erfahrenen ergeben. Diese Ideen ordneten wir dann bestimmten Themenbereichen (Produkten / Komponenten / Schnittstellen) zu. In einem weiteren Planungsmeeting haben wir aus diesen Ideen konkrete Arbeitspakete mit konkreterer Beschreibung und Akzepttanzbedingungen erstellt, diese geordnet und uns zwei Pakete für unseren ersten Sprint (ein Zeitraum von 2 Wochen) ausgewählt. Das ist knifflig, da wir hierfür prognostizieren müssen, ob wir diese Pakete in diesem Zeitraum auch schaffen können. Zu diesem Komplex ließe sich vieles sagen. ...

Ende des letzten Jahres wurden bei uns Mitarbeiter für ein neues Softwareprojekt gesucht. Ich meldete mich und vor zwei Wochen ging das Projekt an den Start. Es trat bei mir jedoch ziemlich schnell Ernüchterung ein. Vom Thema schien ich überhaupt nichts zu verstehen, die anderen Kollegen waren mir meilenweit voraus, es sah aus, als würden wir die nächsten Wochen nur über Anwendungsfälle und Anforderungen reden und überhaupt war ich völlig nutzlos. Als ich mit dieser Stimmung in das damalige Wochende ging, hatte ich den Entschluss gefasst, aus dem Projekt auszusteigen. Allerdings war ich noch vernünftig genug, das Problem zuvor an Steinchen heranzutragen. Dieser rief mich daraufhin direkt an und überzeugte mich, dem Projekt doch erst noch etwas Zeit zum Aufblühen zu geben und vielleicht auch das persönliche Gespräch mit den anderen Projektteilnehmern zu suchen. Wir tauschten uns noch weiter über Softwareprojekte im allgemeinen und speziellen aus, über Wasserfälle und Agilität und das h...

Ich hatte gestern Freigang und mich mit meinen Kollegen zum Essen getroffen. Wir diskutierten unter anderem den Einfluss von KIs auf unsere Arbeit als Softwareentwickler. Der allgemeine Tenor war optimistisch. Ich hatte den Ladies-Teller und den Schokoladenkuchen.

Wann soll man Details einer Funktion in Unterfunktionen extrahieren, weil man ansonsten "den Wald vor lauter Bäumen nicht sieht"? Und wann soll man lieber die Details sichtbar lassen? Welches sind die Vor- und Nachteile ​​der folgenden Beispiele und welches favorisiert ihr? 1. Alle Details import sys def main(): numbers = [int(argument) for argument in sys.argv[1:] if str.isnumeric(argument)] for i in range(0, len(numbers)): for j in range(1, len(numbers) - i): if numbers[j] 2. Alle Details mit Kommentaren import sys def main(): #Read numbers from command line numbers = [int(argument) for argument in sys.argv[1:] if str.isnumeric(argument)] #Sort numbers for i in range(0, len(numbers)): for j in range(1, len(numbers) - i): if numbers[j] 3. Drei Unterfunktionen mit konkreten Namen import sys def main(): numbers = readNumbersFromCommandLine() sort(numbers) writeNumbersToConsole(...

Ich habe mich, auf Vorschlag von Sebastian hin, die letzten Wochen mit einer Implementierung von "Vier gewinnt" in Rust versucht. An Rust gefällt mir das Speicherkonzept, das ohne Garbage Collection, Speicherlecks und Nullpointer-Exceptions zur Compile-Zeit zu verhindern sucht. Auch die Entwicklungsumgebung mit Cargo, der Paketverwaltung und der integrierten Testunterstützung kommt mir sehr entgegen. Aber die Syntax erscheint mir nicht ganz rund und irgendwie inkonsistent. Die Verwendung von traits als Interfaces habe ich noch nicht durchdrungen. Und Marcos hielt ich eigentlich für ausgestorben. Kommen wir aber zur "Vier gewinnt" Implementierung - meiner Nemesis: Ich habe mich wieder an den MinMax-Algorithmus versucht. Nach C++, Java, C# nun also in Rust. Und ich bin wieder gescheitert. Gut, der Algorithmus an sich funktioniert, ist aber entsprechend zu langsam, um ein perfektes Spiel zu spielen. Bis zu 7 Züge kann ich ihn nur voraus rechnen lassen, damit der Spie...

Heute möchte ich eine weitere Möglichkeit zur Vermeidung von bedingten Verzweigungen mittels if vorstellen. Außerdem möchte ich hier an alle Softwareentwickler den Appell richten, doch bitte kleine Funktionen zu schreiben. Meine diesbezügliche Leidensgeschichte* beginnt mit einem Absturz aufgrund eines Timeouts. Eine Routine braucht länger als vorgesehen und wird nach Ablauf der vorgeschriebenen Zeit vom überwachenden Thread abgeschossen. Was ist die Ursache? Eine aufwändige Berechnung? Eine Endlosschleife? Die einzige Debugmöglichkeit ist das Einfügen von printf -Anweisungen, um die Stelle zu finden, an der das Programm zum Stehen kommt. Sehr hilfreich wären hier jetzt kleine Integrationsfunktionen, die keine Logik enthalten und nur andere Funktionen aufrufen. Zwischen die Funktionsaufrufe jeweils ein printf eingefügt, ausführen und sehen, welches printf nicht mehr aufgerufen wird. Daraufhin in die davor ausgeführte Funktion abtauchen, bis man an der Wurzel des Übels angekommen ist...

Das Video trifft so voll, welche Bedeutung die Programmierung für mich hat. Oder einmal hatte? Programmieren des Programmierens wegen. Nicht um ein Problem zu lösen. Nicht um etwas "sinnvolles" zu tun. Einfach des Spaßes wegen. Wozu ist das gut? Was bringt das? Scheiß' drauf! Es funktioniert. Ich hab's gemacht. Das reicht.

Ich arbeite gerade einen Vortrag über TDD aus und möchte hier schon einmal eine erste Version zur Kritik stellen. Vorbemerkung Ich spreche hier von einem Werkzeug, nicht von einem Entwicklungsdogma. Dieses Werkzeug hat Vor- und Nachteile und ist in machen Situationen gut zu gebrauchen und in anderen weniger. Mir geht es darum, dieses Werkzeug vorzustellen und seine Anwendung zu zeigen, damit daraufhin dann jeder Entwickler eine bewusste Entscheidung für oder gegen diese Technologie treffen kann. Test First Was wohl jeder Entwickler über Test Driven Development weiß, ist dass der Test bereits geschrieben und ausgeführt wird, bevor der zugehörige Produktivcode existiert. Man schreibt zuerst einen Test, der fehlschlägt, dann schreibt man soviel Produktivcode wie nötig ist, damit der Test grün wird. Dann refaktorisiert man den Code und beginnt mit dem Zyklus erneut. Entsprechend nennt man diesen Prozess: Red (Test schlägt fehl), Green (Test ist erfolgreich), Refactoring (Programmcode wird ...

Im Sommer letzten Jahres rief der Webcomic  CommitStrip  zu einer Crowdfunding-Aktion auf. Da mir die Comics dort sehr gut gefallen und das Leben eines Entwicklers sehr gut einfangen, habe ich meinen kleinen Beitrag dazu geleistet. Genau einen Tag vor Weihnachten traf dann ein Paket aus Frankreich ein (trotz der Streiks dort?) Neben dem eigendlich finanzierten Buch "Summer of Code" lagen noch bei: das Vorgängerbuch "Rise of the Coder", ein Paar Socken, drei Buttons, Aufkleber und 5 Poster. Ein sehr schönes Weihnachtsgeschenk. Aber wo im Büro soll ich die Poster alle aufhängen?

Gestern war ich bei einem Code Retreat, über den ich eigentlich heute schreiben wollte. Dagegen haben aber die Kinder etwas. Also werde ich den Bericht später nachreichen - hoffentlich. In Kürze: Hat Spaß gemacht. Voll die Nerds. Alle besser als ich. Gerne wieder. Schönen Sonntag Abend noch.

Am 16. November ist der globale Code-Retreat-Tag. Wer sich also einmal mit anderen Entwicklern mittels Pair Programming über Clean Code, TDD und Programmierung im Allgemeinen austauschen möchte, findet vielleicht eine  Veranstaltung  in seiner Nähe. Hier ein entsprechendes Promo-Video:

"Es ist leichter um Vergebung zu bitten, als um Erlaubnis zu fragen" (EAFP) Ich verweise auf dieses bei Python etablierte Prinzip, um damit meiner Liste von If-Alternativen eine weitere Möglichkeit hinzuzufügen. Statt also vor dem Aufruf einer Funktion abzufragen, ob deren Aufruf vielleicht eine Ausnahme auslöst (Erlaubnis), ruft man statt dessen einfach die Funktion auf und reagiert im Nachgang auf eventuelle Ausnahmen (Vergebung). Dieses Vorgehen ist für Entwickler, die aus anderen Sprachen wie Java oder C# kommen zuerst befremdlich, da dort Exceptions als teuer gelten. Wenn man sich jedoch daran gewöhnt hat, stellt sich EAFP als viel sauberer da. Zum einen findet die Überprüfung der möglichen Fehlerursachen in genau der Funktion statt, die am besten weiß, welche Probleme ihre Operationen bewirken können. Das trägt dem Single Responsibility Prinzip Rechnung. Warum sollte jeder Aufrufer immer wieder den selben Code schreiben müssen, der eigentlich gar nicht...

Vor einigen Jahren sollte ich die Dokumentenstruktur unseres Projekts analysieren und visualisieren: Welche Dokumente verwenden wir und wie verweisen diese aufeinander? Das sah nach einer ziemlichen Sisyphusarbeit aus, da sich beim Verfolgen der Links immer mehr Dokumente auftaten, und es absehbar war, dass diese Arbeit regelmäßig wiederholt werden müsste, da sich die Dokumentenlandschaft innerhalb der Projektlaufzeit ständig ändern dürfte. Da ich die für einen Programmierer obligatorische Faulheit mitbringe [*], beschloss ich, diese Sache nicht selbst zu erledigen, sondern den Rechner die Arbeit machen zu lassen. Mit der Hilfe eines Kollegen lagen Dokumente und deren Verweise schnell als Datenstrukturen in einem Programm vor. Wie aber diese Datenstrukturen dem Nutzer darstellen? Kreise, Viereckige und Linien zeichnen wäre kein Problem gewesen. Sehr wohl aber, all diese Elemente vernünftig zu positionieren. Selbst ausgefeilte Layoutalgorithmen zu implementieren, wäre ei...

Wie bereits geschrieben , hatte ich vorletzte Woche meine ISTQB-Schulung. Den Dienstag darauf trat ich zur Prüfung an und diesen Freitag bekam ich die Nachricht, dass ich bestanden hätte. Yippie! Jetzt bin ich also Tester. Wie vorher auch schon. Nur zertifiziert.

Ich habe die ganze Woche  ISTQB  Schulung. Deswegen gibt es heute nur diesen Platzhalter.

Hier meine aktuelle Fachlektüre: "Effektives Arbeiten mit Legacy Code" von Michael C. Feathers Das Buch, welches ich momentan täglich aufschlage. Vor allem als Vorbereitung zu dem kommenden Code Retreat . Für Feathers ist Legacy Code produktiver Code, für den es keine Tests gibt. Entsprechend beschäftigt sich die Hälfte des Buchs mit der Frage, wie man Legacy Code unter Test stellen kann, bevor man ihn verändert. Dabei zeigt Feather pragmatische Auswege aus dem Dilemma, dass man erst refaktorisieren soll, wenn der Code getestet wird; zum Testen der Code aber erst refaktorisiert werden muss. "Clean Code" von Robert C. Martin Das Buch, welches man sich zu Herzen nehmen sollte, damit Feathers Buch in der Schublade bleiben kann. Benutze ich momentan eher als Nachschlagewerk. "Clean Architecture" von Robert C. Martin Das aktuelle Buch von Onkel Bob. Fokussiert nicht mehr (nur) auf den Code, sondern diskutiert die Beziehung der Komponenten de...

Ich bereite gerade wieder einen Code Retreat vor. Diesmal einen "Legacy Code Retreat". Statt "TDD" steht diesmal "Golden Master" und statt "Clean Code" "Refacoring" im Fokus. Mal sehen ob und wie wir vorwärts kommen und ob wir dann auch saubereren Code commiten können. Und vor allem wie sich die Teilnehmer im Nachgang dazu äußern werden.

Fehler sind rot, Warnung' sind blau. Hätt' ich doch nur 'n Test gehabt, wär' mein Haar jetzt nicht grau. Das abgebildete Buch habe ich mir vor drei Jahren aufgrund einer Rezension im Entwickler-Magazin gekauft. Das eine oder andere Gedichte war ganz amüsant, wenn ich mir auch etwas mehr (oder etwas anderes?) versprochen habe. Dennoch kam es mir wieder in den Sinn, als ich nach Themen für Blogartikel suchte. Also einfach mal das eine oder andere IT-Gedicht schreiben und veröffentlichen... ...ist gar nicht so einfach, wie der obige Versuch von mir zeigt. Dennoch seid hiermit darauf vorbereitet in Zukunft mit "Lyrik" von mir erfreut zu werden. Zum Schluss noch einen Verweise auf eine Seite mit Code-Poesie .