Bücherregal lädt …
Einträge mit dem Tag computers.

Interessant und unterhaltsam geschrieben, habe ich gerne gelesen. Es ist gar nicht so technisch wie ich vermutet hätte, sondern vielmehr eine gut aufbereitete Reise durch schlaue, einfallsreiche, innovative Frauen, die mit Computern zu tun hatten. Kann ich empfehlen!

Fand ich eine gute, lesbar geschriebene Sammlung von Anekdoten, Anleitungen, Tipps, Tricks und Fun Facts. Nicht super konkret, aber das werte ich positiv. Es scheint Marianne Bellotti vor allem darum zu gehen, die Leser ins richtige Mindset zu bringen, so dass man einen eigenen Weg finden kann.

Ein weiteres Buch von Dave Copeland, diesmal ein Framework für Senior Softwareentwickler. Ich fand es wieder sehr gut und realistisch. Copeland ist nicht so hand-wavey, wie andere Leute schnell werden, sondern sagt auch mal „Und wenn du deine Vorgesetzten mit diesem Argument auch nicht überzeugen kannst, dann stell dich auf eine lange Diskussion ein, oder poliere schon mal deinen Lebenslauf.“

Viele im Buch angesprochenen Sachen habe ich mir in meiner Laufbahn bereits angeeignet, aber einige auch noch nicht. Es war in jedem Fall gut, alles so gesammelt zu lesen.

↑ 2024
2023 ↓

Ein kurzes, lustiges Buch über die sogenannten „SOLID Principles“ und Softwareentwicklung. Viele gute Stellen, hier ein paar Beispiele:

I also promise that if this book sells well, the follow up, “XP: The Way to Motivate Little Children To Close JIRA Tickets At A Big Horrible Technology Company Run By People Who Do Not Understand Technology”, will be dedicated to Kent Beck.

Und:

Maybe we could call this a “responsibility”, but I like to use words in the right way, since words have, you know, meaning and stuff.

Und:

If Uncle Bob had used the canonical domain of professional wrestling, he would’ve seen that such a leap of abstraction would be difficult without more than one use case.

In diesem Buch geht Avdi Grimm sehr detailliert darauf ein, wie man selbstsicheren Code schreibt. Im Buch geht es (wie der Name andeutet) vor allem um Ruby, aber auch allgemein sind sehr viele gute Refactoring-Tipps enthalten, die Code cooler machen. Ich fand es lesenswert und schaue bestimmt ab und zu noch mal rein!

Manche Stellen waren ein bisschen zu lang, manche ein bisschen zu kurz, aber insgesamt habe ich mir einiges angestrichen für später. Besonders gut fand ich es, wenn es um weichere, menschliche Themen ging oder um pragmatisches Abwiegen von Alternativen. Man merkt, dass Copeland viel Erfahrung mitbringt, die er hier auch gut transportiert.

↑ 2023
2022 ↓

Ich hatte noch nie von David Farley gehört, bis er neulich in irgendeinem Podcast zu Gast war, den ich gehört habe. Dort hat er erwähnt, dass er dieses Buch veröffentlicht hat, und ich habe es direkt bestellt.

Insgesamt fand ich es ziemlich gut und überzeugend! Besonders die erste Hälfte hat mich sehr zu nachdenken angeregt. Die zweite Hälfte wiederholt viele der Themen noch mal und beleuchtet sie aus einer etwas anderen Richtung – das war dann etwas weniger spannend zu lesen.

Trotzdem würde ich sagen, dass es sich hier um eine gute Zusammenfassung von Farleys Philosophie handelt, und dass ich hoffentlich noch lange über einige der hier besprochenen Aspekte nachdenken werde.

Richtig gut! Seit letztem Sommer bin ich ja endlich Rubyentwickler, darum ist jedes Buch, in dem es um Object-Oriented Design geht, direkt eine gute Investition. (Dieses Buch hier gibt es praktischerweise auch in JavaScript- und PHP-Editionen, darum ist vielleicht für jeden was dabei! Ich habe aber lediglich die Ruby/Milch-Variante gelesen.)

Im ganzen Buch geht es um das gleiche Codebeispiel: Das Lied „99 Bottles of Beer/Milk“. Anfangs ist der Code noch extrem simpel gehalten (das Buch nennt es „Shameless Green“, das werde ich mir auf jeden Fall merken), aber durch „Neue Anforderungen“ müssen immer mehr Features hinzugefügt werden. Damit die Komplexität nicht explodiert, wird man darum auf eine Reise durch Refactorings genommen, die den Code immer modularer werden lassen. Jeder Schritt ist ausführlich und nachvollziehbar erklärt, auf jedes Detail wird eingegangen und Alternativen werden abgewogen.

Da juckt es einen direkt in den Fingern – Ich kann es kaum erwarten, meine nächste Klasse zu schreiben!

↑ 2022
2021 ↓

Dieses Buch hätte ich lieber schon vor ein paar Jahren lesen sollen. Ich fand richtig gut, wie Sandi Metz sehr feine Unterschiede zwischen verschiedenen Designs herausgearbeitet hat. Sie hat nicht einfach „richtige“ Designs vorgesetzt, sondern ein Beispiel vorgestellt, die Probleme erklärt und dann Schritt für Schritt verbessert, um die Aspekte von Object Oriented Design zu erklären.

Immer wieder gingen mir kleine Lichter auf, durch die ich mich an vergangene Projekte erinnert habe, bei denen genau das besprochene Designproblem aufgetreten war. Ich wünschte, ich hätte damals schon dieses Buch in meinem Werkzeugkoffer gehabt, das hätte bestimmt geholfen!

↑ 2021
2020 ↓

Eines schönen Tages dachte ich mir: „Moment mal! Ich muss manchmal mit Legacy Systemen arbeiten! Vielleicht sollte ich mich mal etwas fortbilden, wie ich das möglichst effektiv tun kann!“ Darum bestellte ich dieses Buch. Leider kann ich es nicht empfehlen. Direkt auf einer der ersten Seiten definiert Feathers „Legacy Code“ als „Code, der keine Tests hat,“ und im ganzen Rest des Buches geht es nur darum, wie man Klassen so auftrennen kann, dass man Teile von ihnen Testen kann. Ich finde, das ist eine zu starke Vereinfachung und überhaupt nicht, was ich mir erwartet hatte. Die Codebeispiele sind alle in Java und C++ (das könnte ich vielleicht noch verzeihen), aber sie sind auch viel zu ausführlich und zu langweilig – eigentlich geht es immer um Accounting oder Reservierungen oder Payrolls. Die verschiedenen beschriebenen Methoden sind einander zu ähnlich, als dass ich jetzt (Minuten, nachdem ich das Buch beendet habe) noch mehr als drei nennen könnte. Insgesamt habe ich nicht das Gefühl, besonders viel aus diesem Buch in meinen Alltag mitnehmen zu können. Sehr schade!

Abgesehen von dem Inhalt, den Feathers absichtlich geschrieben hatte, war meine (relativ neue, definitiv nicht erste) Ausgabe dieses Buchs voller Rechtschreibfehler im Prosa und im Code, mitten im Satz aufhörender und anfangender Seiten und teilweise haarsträubenden Layoutfehlern. Für ein so teures Buch finde ich das fast schon unverschämt.

↑ 2020
2019 ↓

Das Buch war einigermaßen interessant, aber auch sehr frustrierend. Es geht meistens darum, wie Manager von großen Computerspielherstellern (mehrere dutzend bis wenige hundert Mitarbeiter) fragwürdige Entscheidungen treffen und dann alle normalen Angestellten hundert Stunden pro Woche arbeiten müssen. Aber ohne das so richtig zu thematisieren. Das Kritischste, was gegen das allgegenwärtige „Crunchen“ gesagt wird, ist ungefähr „Ist es wirklich nötig, den Geburtstag seines Kindes zu verpassen? Alle sagen ‚Ja!‘“. Da hätte ich mir schon eine kritischere Auseinandersetzung mit dem Thema gewünscht.

Matt Parker mag ich, seit mir eines schönen Tages der YouTube-Algorithmus ein Video von seinem Kanal vorgeschlagen hat.

In diesem Buch sind eine große Menge an Fehlern versammelt, die Menschen (und Computern – aber wer programmiert Computer? Eben.) passiert sind. Einige sind mit Todesfällen verbunden, aber viele sind harmlos und witzig – glücklicherweise gelingt Matt Parker hier eine gute Balance, so dass man sich nicht zu sehr runtergezogen fühlt. Die Beispiele sind vielseitig und gut ausgewählt, lustig erklärt, und ein paar Mal musste ich laut lachen.

Wenn man sich im weitesten Sinne für Mathematik, oder Computer, oder Fun Facts interessiert (und wer mag bitte keine Fun Facts?), dem kann ich das Buch sehr empfehlen.

Was mir übrigens an der Gestaltung des Buchs extrem gut gefallen hat: Die Seiten sind absteigend nummeriert! Die Seitenzahlen beginnen bei 312 und gehen dann langsam runter bis 1. Genial! Erst dachte ich, das wäre so ein halbwitziger Versuch, besonders neckisch zu sein aber inzwischen bin ich komplett überzeugt und hätte das gerne in allen Büchern. So gut!

Obwohl ich kein Spieleentwickler bin, habe ich mir dieses Buch gekauft, weil es von Dan Abramov empfohlen wurde (der ja auch kein Spieleentwickler ist). Es gibt einen guten Überblick über einen Haufen Design Patterns, die man auch allgemein mal anwenden kann, wenn man Lust drauf hat!

Der Beispielcode war (beinahe) komplett in C++, was mir natürlich nicht so viel bringt, und einige der Patterns sind vermutlich auch am nützlichsten, wenn man es mit einem sehr starren Object Oriented Type System zu tun hat, so dass man ständig Objekte in Objekte stecken muss, oder wenn es wirklich um jedes Milligramm Performance geht, so dass man ständig Linked Lists braucht und Memory Management machen muss.

Dieses Buch wurde mal von Gary Bernhardt empfohlen, und weil ich großes Vertrauen in ihn habe, habe ich es schließlich gekauft.

Es ist ein recht kurzes Buch, das sich mit einem Thema beschäftigt, das mir sehr am Herzen liegt: Wie schreibt man Software, die dauerhaft einfach und verständlich bleibt, obwohl man neue Features hinzufügt.

Im Prinzip habe ich dadurch wenig komplett Neues erfahren, weil es großteils Ideen sind, die ich schon mal gehört habe. Aber es ist auch mal schön, sie alle so gesammelt auf einem Haufen zu haben, zusammen mit guten Argumentationen für jede davon.

Irgendwann wurde dieses Buch irgendwo empfohlen. Ich habe es angeschafft und eigentlich ein paar amüsante Essays über Fehleinschätzungen bei Programmierprojekten erwartet. Mir war dabei nicht klar, dass dieses Buch aus dem Jahr 1975 ist.

Ich habe immerhin die erweiterte 20 Jahre Jubiläumsausgabe von 1995, die um ein paar Kapitel erweitert wurde, aber alle alten Kapitel wurden unverändert gedruckt. Die meiste Erfahrung von Brooks kommt von seiner leitenden Rolle bei der Entwicklung des IBM OS/360 (vorgestellt noch früher, nämlich 1964), und darum geht es auch hauptsächlich im Buch.

Und Leute, es war vielleicht noch nicht klar, aber 1975 ist so lange her, wenn es um Computer geht! 1975 gab es quasi keine Personal Computers, keine E-Mails (im Buch wird immer wieder empfohlen, man solle mit seinen Kollegen telefonieren!), keine Webseiten (im Buch gibt es eine Stelle, wo er beschreibt, dass das Handbuch während der Entwicklung des OS/360 mehrere Fuß breit war und sie irgendwann auf Mikrofilm umgestiegen sind, weil sonst jemand jeden Tag 150 neue Seiten Dokumentation einheften musste!), strukturiertes Programmieren mit Loops statt GOTO war noch umstritten, C war gerade brandneu (wurde aber im Buch nicht erwähnt). An einer Stelle erzählt er, wie sie durch schlechte Nutzung von Systemressourcen einen Compiler hatten, der fünf FORTRAN-Statements pro Minute kompiliert hat. ALTER.

Irgendwann habe ich mich damit abgefunden, dass das Buch eher ein historisches Dokument ist als etwas, das ich in meinem täglichen Leben anwenden kann – und von da an ging es eigentlich. Klar, ein paar Sachen kann man bestimmt mitnehmen oder hat man schon irgendwoanders gehört, aber als „modernen“ Überblick über Softwareentwicklung würde ich es nicht empfehlen.

Sidebar: Ja, ich weiß, es handelt sich hier literally um einen alten weißen Mann, aber ich schwöre, in diesem Buch kommt keine einzige Frau vor, außer, in der Widmung, seine Ehefrau Nancy. Alle Teams bestehen aus Männern, alle Chefs sind Männer, die Architekten sind Männer, einfach alle Arbeitskräfte sind Männer, die Mann-Tage und Mann-Monate und Mann-Jahre an Arbeit in etwas reinstecken.

Es fällt mir ein bisschen schwierig, dieses Buch zu bewerten.

Grundsätzlich handelt es davon, welche Eigenschaften und Gewohnheiten die beiden Autoren in sich selbst und anderen Softwareentwickler/innen sehen, die „Pragmatische Programmierer“ ausmachen. Ich halte mich selbst auch für pragmatisch, darum dachte ich, ich schaue mir dieses Buch mal an!

Mein Problem ist, dass das Buch halt, da kann man nicht drumherum reden, aus dem Jahr 2000 ist. An den Stellen, an denen es um allgemeine, übergreifende oder zwischenmenschliche (will sagen: zeitlose) Themen ging, war es interessant und gut.

Aber an den Stellen, an denen es darum ging, wie man Software, die vor 20 Jahren populär war, dazu benutzt, eine vor 20 Jahren populäre Programmiersprache besser zu benutzen, zog es sich ein bisschen. Wenn plötzlich empfohlen wird, dass man eine Makefile nutzen soll, um ein Perl-Script auszuführen, um damit wiederum eine Java-Klasse zu erstellen, dann muss ich mich doch fragen, ob es sich nicht langsam lohnen würde, eine aktualisierte Version dieses Buchs rauszubringen. (Außerdem haben sich die Best Practices in den letzten 20 Jahren hoffentlich etwas gebessert. (Das sage ich so einfach, aber wie oft arbeite ich auch heute noch in Teams, in denen es kein Testing und/oder keine Dokumentation gibt? Ständig. Also Nevermind.))

Und das ist es, was ich so schade finde: So viele der angesprochenen Themen sind auch heute noch gut und wichtig und Leute sollten von ihnen hören und sie anwenden: Orthoginality, Prototypes, Tracer Bullets, The Power of Plain Text, Refactoring, Testing, Automatisierung. Fuck yes! Aber ich weiß nicht, ob ich dieses Buch heute einfach so, ohne viele Fußnoten, einem Anfänger in die Hand geben würde – Ich müsste immer in Angst leben, morgen eine Makefile in meinem Node-Projekt zu haben oder dass sie plötzlich anfangen, die Programmiersprache Eiffel zu lernen – was im Buch mehrmals empfohlen wird!

Kann man ruhig immer mal wieder lesen, wenn man hin und wieder Webapps baut. (Oder, wenn man, wie ich, eigentlich nie was anderes macht.)

Teilweise merkt man dem Buch an, dass es von 2006 ist („Vergesst nicht, einen RSS-Feed einzubauen!“, „Bietet euren Nutzern ein Forum an, in dem sie sich austauschen können!“), aber die meisten Ratschläge sind zeitlos. Gefühlt setze ich auch die meisten Sachen bei meinen Projekten schon so um, wie sie im Buch empfohlen werden und bin damit auch sehr glücklich.

Manchmal war ich darum nicht sicher, ob sich aus den Tipps jetzt direkt eine Handlungsempfehlung für mich ableiten lässt, oder ob ich die schon umgesetzt habe. Wenn es zum Beispiel heißt, dass man darauf achten soll, Software zu schreiben, die weniger kann und einfacher geschrieben sein soll, frage ich mich: Kann ich meine Software reduzieren und vereinfachen, oder sind die Tipps an Leute gerichtet, die sonst Java Enterprise Applications schreiben, und mal probieren sollen, einen Server-Endpoint ohne fünf Factories zu bauen? Denn zum einen habe ich manchmal schon das Gefühl, vom Umfang meiner Projekte etwas überwältigt zu werden, auf der anderen Seite müssen auch Webapps ja irgendwas machen, und dafür muss halt häufig Code existieren?

Naja, ich melde mich wieder, wenn ich das Buch in einem Jahr oder so noch mal lese.