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!
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!