Weniger schlecht programmieren: Das realistischste Programmierbuch im Regal

Die meisten Programmierbücher leiden an derselben Fantasie: Der Leser hat unendlich Zeit, arbeitet in perfekten Teams und möchte sein Leben kompromisslos der Softwareentwicklung widmen. Die Realität sieht anders aus. Projekte haben Deadlines, Anforderungen ändern sich ständig und manchmal schreibt man Code, von dem man schon während des Tippens weiß, dass man ihn später bereuen wird.

Weniger schlecht programmieren ist eines der wenigen Bücher, das diese Realität akzeptiert. Gerade deshalb ist es auch mehr als zehn Jahre nach seinem Erscheinen noch bemerkenswert lesenswert.

Es gibt Programmierratgeber, die vom Leser implizit verlangen, sofort ein besserer Mensch, ein disziplinierterer Entwickler und am besten gleich ein kleiner Softwaremönch zu werden. Weniger schlecht programmieren schlägt einen anderen Weg ein. Schon der Titel macht klar, dass es hier nicht um Reinheitsgebote geht, sondern um einen realistischen Fortschritt: weniger unnötige Fehler, weniger peinliche Gewohnheiten, weniger selbstverursachte Wartungshölle. Dass die Autoren ihr Buch im Vorwort ausdrücklich gegen Ehrgeizliteratur positionieren, die kompromisslose Exzellenz erwartet, ist keine hübsche Randnote, sondern der Kern des Programms.

Gerade deshalb ist der Titel stark. Er klingt zunächst wie Understatement, tatsächlich ist er ein präzises Leistungsversprechen. Dieses Buch verspricht nicht, aus Freizeitcodern in drei Wochen Softwarearchitekten zu machen. Es verspricht, dass man seltener über die immer gleichen Dinge stolpert. Und dieser bescheidenere Anspruch wirkt in den vorhandenen Rezensionen fast überall überzeugender als die großen Sauberkeitsideale, mit denen ähnliche Literatur oft operiert.

Für wen das Buch geschrieben ist

Die Antwort gibt das Buch selbst ziemlich offen: für Menschen, die programmieren, aber andere Prioritäten im Leben haben; für Leute, die mindestens eine Sprache irgendwie beherrschen, aber ahnen, dass ihre Lösungen robuster, verständlicher und wartbarer sein könnten; für Hobby- und Gelegenheitsprogrammierer, die nicht den „schwarzen Gürtel“ anstreben. Diese Selbstbeschreibung wird von fast allen deutschsprachigen Besprechungen bestätigt. Linux-Magazin spricht vom Gelegenheitsprogrammierer. deesaster/Ikhaya sieht Einsteiger und Hobbyprogrammierer im Zentrum. Forenstimmen betonen, dass das Buch gerade ohne klassische Informatikausbildung besonders hilfreich sei.

Wer eher nicht die Hauptzielgruppe ist, lässt sich daraus ebenfalls ableiten. Wer ein enges Sprachlehrbuch, ein tiefes Nachschlagewerk zu einem einzigen Thema oder ein streng aufgebautes Übungsbuch erwartet, wird hier nicht ideal bedient. Das Buch ist breiter, essayistischer und in seiner besten Form eher ein Denk- und Praxisbuch als ein Trainingsheft. Für erfahrene Entwickler kann das trotzdem reizvoll sein, aber der Gewinn liegt dann eher in der Selbstkorrektur und im Wiedererkennen schlechter Gewohnheiten als in völlig neuen fachlichen Tiefen. Das ist eine Schlussfolgerung aus Zielgruppenbeschreibung und Rezeptionslage, nicht aus einem gegensätzlichen Urteil gegen das Buch. Man kann es besonders gut beim Baden, im Zug oder einfach zum Überbrücken von Wartezeiten lesen.

Aufbau und Themen

Der Aufbau ist beeindruckend breit. Vier Teile und 27 Kapitel führen von Selbstdiagnose und Selbsteinschätzung über Konventionen, Namensgebung, Kommentare, Code-Lesen und Hilfe-Kultur bis zu Debugging, Refactoring, Testing, Werkzeugkasten, Versionskontrolle, Kommandozeile, OOP, Datenhaltung, Sicherheit und einem Sammelkapitel zu nützlichen Konzepten wie CRUD, REST, Namespaces oder Hashes. Diese Breite ist zunächst ein großer Pluspunkt, weil sie Programmieren als echte Arbeitspraxis versteht und nicht bloß als Syntaxbeherrschung.

Besonders stark ist, dass Kommunikation hier nicht als Soft Skill neben dem Eigentlichen läuft, sondern das Eigentliche mitprägt. Kapitel zu „Hilfe suchen“ und „Lizenz zum Helfen“, zu Konventionen im Team oder zu der Frage, wie man fremden Code liest, sind in vielen anderen Büchern Randbemerkungen. Genau das erklären mehrere Rezensenten zu den besten Seiten des Buchs.

Was das Buch stark macht

Seine größte Stärke ist die Mischung aus Nüchternheit und Freundlichkeit. Das Buch scheint nicht daran interessiert zu sein, Leser für ihre schlechten Gewohnheiten zu beschämen. Es interessiert sich dafür, warum sie entstehen und wie man mit ihnen umgeht. Selbst die Regelwelt der Konventionen wird nicht dogmatisch, sondern realitätsnah begründet. Der Rat „Erst mal gucken, wie es die anderen machen. Dann alles genauso machen.“ ist dafür ein gutes Beispiel: nicht elegant um der Eleganz willen, sondern praktisch um der Zusammenarbeit willen.

Dazu kommt die sprachliche Form. Ich muss hervorheben, wie gut sich das Buch liest. Es hat eine gute sprachliche Qualität und ist an vielen Stellen Unterhaltsam geschrieben. Diese Kombination ist selten: ein Softwarebuch, das nicht nur vernünftig denkt, sondern offenbar auch literarisch sauber genug gebaut ist, dass man es gern weiterliest.

Ebenfalls überzeugend ist der Pragmatismus. Die vorgeschlagenen Prinzipien und Regeln werden weniger dogmatisch betrachet als man es aus anderen Büchern annehmen würde. Es anerkennt, dass man manchmal nicht umhinkommt, schlechten Code zu schreiben, insistiert aber auf den Folgekosten, wenn daraus Dauerzustand wird. Hier predigen keine Reinheitspriester, sondern Autoren, die offenbar verstanden haben, dass Softwareentwicklung oft aus Zeitdruck, Altlasten, Missverständnissen und halbguten Entscheidungen besteht.

Wo das Buch schwächer wird

Kurzggesagt: Es hätte kürzer sein dürfen. Gegen Ende nimmt das Buch sehr viele Themen auf, die zwar relevant sind, aber nicht immer die Tiefe tragen, die ein eigenes Kapitel verspricht. Dadurch entsteht stellenweise ein Sammelband-Eindruck. Genau das kann man schon am späten Inhaltsverzeichnis sehen: Sicherheit, Datenhaltung, OOP, nützliche Konzepte, Kommandozeile und Werkzeuge stehen dicht nebeneinander.

Ein zweiter Schwachpunkt ist die zeitliche Verankerung einzelner Kapitel. Wer 2026 zu einem Buch aus dem Jahr 2013 greift, wird zwangsläufig auf Beispiele, Werkzeuge und Arbeitsweisen stoßen, die heute anders aussehen. Das zeigt sich etwa bei den Ausführungen zur Versionskontrolle, in denen Subversion noch selbstverständlich neben Git steht. Solche Passagen sind deshalb nicht falsch, wirken aber erkennbar wie ein Produkt ihrer Entstehungszeit.

Gleichzeitig zeigt sich hier auch eine Grenze des Buches aus heutiger Perspektive. Moderne Entwicklungen wie KI-gestützte Programmierung, Large Language Models oder die zunehmende Verbreitung agentischer Entwicklungssysteme tauchen logischerweise nicht auf. Fragen, die heute viele Entwickler beschäftigen, etwa wie man KI-generierten Code überprüft, welche Verantwortung beim Delegieren von Aufgaben an Agenten entsteht oder welche Prinzipien auch in einer KI-unterstützten Entwicklungsumgebung gelten sollten, werden nicht behandelt.

Schließlich ist das Buch weniger für Leser gemacht, die viel geordnetes Üben wollen. Wer viele Codebeispiele suche, ist hier falsch. Das muss kein Mangel sein, ist aber eine klare Erwartungsgrenze: Dieses Buch macht eher aufmerksam, klärt Begriffe, schärft Routinen und verbessert Urteilsfähigkeit, als dass es Schritt für Schritt eine Sprache einpaukt.

Einordnung neben Clean Code und ähnlichen Titeln

Neben Clean Code, Code Craft und ähnlichen Büchern scheint Weniger schlecht programmieren vor allem durch seine Haltung interessant zu sein. Es ist realistischer im Anspruch, weniger stilreligiös und stärker auf das alltägliche Funktionieren in echten, nicht idealen Umgebungen ausgerichtet. Genau diesen Punkt treffen sowohl das Vorwort als auch spätere Forenkommentare bemerkenswert gut: Das Buch ist „ganzheitlich“, nicht auf einen Code-Style fixiert und im Titel bereits realistischer.

Für deutschsprachige Leser kommt ein weiterer Vorteil hinzu. Das Buch ist eine besonders passende Alternative oder Ergänzung zu englischsprachigen Klassikern, weil es dieselben Grundprobleme in einer vertrauten Sprache beschreibt.

Fazit

Wenn man Weniger schlecht programmieren fair beurteilt, ist es weniger ein Codierhandbuch als eine Gebrauchsanleitung für vernünftige Programmiergewohnheiten. Seine Stärken liegen in Ton, Haltung, Breite und in der Einsicht, dass gute Softwareentwicklung immer auch Verständigung, Fehlerkultur und Selbstbegrenzung ist. Seine Schwächen liegen dort, wo die große Spannweite etwas zu viel wird und wo einzelne Werkzeugthemen erkennbar den Stand von 2013 mit sich herumtragen.

Für Hobbyentwickler, Informatik Studenten und viele fortgeschrittene Anfänger dürfte das Buch nach der gesammelten Quellenlage weiterhin eine der interessantesten deutschsprachigen Empfehlungen sein. Für hochspezialisierte Profis ist es wahrscheinlich weniger Offenbarung als Spiegel. Aber auch das ist ein Kompliment: Ein Buch, das einem zehn Jahre nach Erscheinen immer noch die eigenen schlechten Gewohnheiten zeigt, hat offenkundig mehr richtig gemacht als sein ironischer Titel zunächst verspricht.