Coders At Work, geschrieben von Peter Seibel und veröffentlicht am 16. September 2009, ist eine Sammlung von Interviews mit einigen der bedeutendsten Programmierer dieser Generation. Die Gespräche sind lang und tiefgründig, einschließlich Debugging und Testen, und drehen sich alle um das Handwerk des Programmierens. Das Buch wäre eine gute Podcast-Serie oder ein Hörbuch, aber ich lese lieber.
WIE DIESES BUCH UNS GEHOLFEN HAT?
Coders at work hat unser technisches Wissen erweitert. Das Buch liefert Informationen, die uns neue Möglichkeiten für unsere Karriere eröffnen. Außerdem hat das Buch uns geholfen, Problemlöser zu werden. Coders at work vermittelte uns Einblicke, die uns halfen zu verstehen, wie wir Probleme angehen und die uns zur Verfügung stehenden Werkzeuge nutzen können, um überlegene Lösungen zu entwickeln.
DAS BUCH ERKLÄRT IN 60 SEKUNDEN
Das Buch enthält Interviews mit einigen sehr erfolgreichen Programmierern. Die wichtigsten Teile dieser Interviews beinhalten, wie die Befragten zum Programmieren gekommen sind, ihre bevorzugten Programmiersprachen und ersten Programme, Meinungen zu den aktuellen Programmiertrends und Informationen zu ihrer Karriere.
DIE DREI BESTEN ZITATE
- „Die Lesbarkeit des Codes ist jetzt meine Priorität. Sie ist wichtiger als schnell zu sein, fast so wichtig wie korrekt zu sein. Dennoch ist die Lesbarkeit der wahrscheinlichste Weg, um ihn korrekt zu machen.“
- „Er kam herein und pinkelte in mein Hotelbadezimmer, ohne die Tür zu schließen, als ich genau dort stand. Ich sagte: „In Ordnung. Du hast es bequem.“ Wir kannten uns seit vier oder fünf Jahren, obwohl wir uns nie getroffen hatten.“
- „Aber ich denke, wenn ein Programm gut geschrieben ist, wird es etwas in seiner Struktur geben, das mich zu den verschiedenen Teilen in einer Reihenfolge führt, die einen gewissen Sinn ergibt.
BUCHZUSAMMENFASSUNGEN UND NOTIZEN
Kapitel eins: Jamie Zawinski
Der Nachtclubbesitzer, Lisp-Hacker und frühe Netscape-Entwickler Jamie Zawinski gehört zu einer Gruppe von Hackern, die mit ihren Initialen aus drei Buchstaben als vollständigen Namen bekannt sind. Im Jahr 1998 leistete er einen bemerkenswerten Beitrag zur Entwicklung von mozilla.org und XEmacs. Auf die Frage, wie er das Programmieren gelernt hat, antwortete Zawinski, dass er in der achten Klasse zum ersten Mal einen Computer unter Programmierbedingungen benutzt hat. Es gab keine Möglichkeit, Programme zu speichern, also tippten wir sie aus Zeitschriften ein. Außerdem habe ich eine Menge Bücher über verschiedene Sprachen gelesen, so dass ich keine Möglichkeit hatte, Programme für Sprachen zu schreiben, die ich nur studiert hatte. Die Arbeit bei Lucid, einem Unternehmen, das Lisp-Software implementiert und eine Entwicklungsumgebung erstellt, hat dazu beigetragen, dass Zawinski ein besserer Programmierer geworden ist. Er plädiert dafür, dass Entwickler sich des Syndroms des zweiten Systems bewusst sein sollten. Es sei für ihn nie eine perfekte Idee gewesen, ein System neu zu entwerfen. Zawinski rät jungen Programmierern, klein anzufangen und sich mehr auf den Prozess als auf die Ergebnisse zu konzentrieren. So hat auch Fitzpatrick mit LiveJournal begonnen.
Lieblingszitat des Kapitels: „Manchmal. Am Ende mache ich den ganzen Sysadmin-Mist, den ich nicht ausstehen kann – das hat mir noch nie gefallen. Es hat mir Spaß gemacht, an XScreenSaver zu arbeiten, denn in gewisser Weise sind Bildschirmschoner – die eigentlichen Anzeigemodi und nicht das XScreenSaver-Framework – das perfekte Programm, weil sie fast immer bei Null anfangen und etwas Hübsches machen und es nie eine Version 2.0 gibt. Es gibt sehr selten einen Fehler in einem Bildschirmschoner. Er stürzt ab – oh, da ist ein Teiler durch Null, und Sie beheben das.“
Kapitel zwei: Brad Fitzpatrick
Brad Fitzpatrick ist der jüngste unter den Befragten und die einzige Person. Er kann nicht ohne das Internet oder den Computer leben. Nachdem er seinem Vater dabei zugesehen hatte, wie er einen Apple II von Grund auf baute, wurde Brad zum Programmierer, spielte mit den Hardwareteilen und las Bücher. Wie Zawinski hat auch Brad mit BASIC angefangen. Er konnte weder mit einer Maus noch mit höheren Grafikmodi und Farben etwas anfangen. Es dauerte, bis einer von Brads Familienfreunden ihn in C einführte und ihm Turbo C gab. Brad spielte auch mit Assembler-Programmierung auf Rechnern wie dem Z80 auf dem IT-Rechner herum. Brads Interesse an Perl begann, als er sich mit CGIs beschäftigte und ein oder zwei Zeilen in den Netscape Navigator-Browser eingab. Brad besuchte keine Kurse zum Thema Programmierung. Es ging nur um ein oder zwei Bücher aus der Bibliothek. Sein College war eine Kombination aus Laufen und LiveJournal, was die Schule erträglich machte.
Lieblingszitat des Kapitels: „Damals, als ich mich mit Perl beschäftigte – selbst für Leute, die Perl wirklich gut kannten – würde ich MJDs Higher-Order Per! empfehlen. Das Buch ist insofern unterhaltsam, als es recht einfach anfängt und Sie denken: Ja, ja, ich weiß, was ein Abschluss ist. Und dann geht es weiter, um Ihnen den Kopf zu verdrehen. Am Ende des Buches sind Sie einfach nur noch hin und weg.“
Kapitel drei: Douglas Crockford
Douglas Crockford war früher ein leitender Javascript-Architekt bei Yahoo. Zuvor arbeitete er für Lucasfilm, Atari und Electric Communities. Crockford besuchte die Universität von San Francisco und belegte einen Fortran-Kurs in der mathematischen Abteilung, wo er das Programmieren lernte. Crockford ist der Meinung, dass mit den Verbesserungen bei CPU und Speicher bzw. bei der Hardware im Allgemeinen die Effizienz für die Entwickler nicht mehr so wichtig ist wie in der Vergangenheit. Dem Interviewpartner zufolge liegt ein Teil dessen, was das Programmieren schwer macht, darin, dass die Programmierer die meiste Zeit Dinge tun, die sie früher nicht getan haben. Er spricht über seine Lieblingsmethode bei Vorstellungsgesprächen mit Bewerbern. Er fordert den Kandidaten auf, ein Stück Code mitzubringen, das er gemacht hat, und es uns vorzuführen. Crockford ist auch der Meinung, dass die einzige Möglichkeit, Javascript zu verbessern, darin bestünde, es zu verkleinern, wenn wir alle Funktionen entfernen könnten, die keinen Wert haben, und nur das beibehalten, was wichtig ist. Er sagt, dass dieser Ansatz auch bei HTML, HTTP und CSS angewendet werden kann. Die Entwickler sollten herausfinden, was die Sprachen am besten können und sich darauf konzentrieren, anstatt immer wieder neue Updates einzubauen. Auf die Frage nach Ratschlägen für angehende Programmierer antwortete Crockford, dass sie sich mehr auf die Kommunikation konzentrieren sollten. Sie sollten lernen, wie man liest und schreibt.
Lieblingszitat des Kapitels: „Im Großen und Ganzen haben wir uns ganz gut geschlagen. Ich denke, die Welt ist ein besserer Ort, auch wenn sie sich nicht immer vorwärts bewegt. Wenn ich mir die internationale Politik der letzten zehn Jahre anschaue, die Konsolidierung der großen Medien und die korrumpierenden Auswirkungen, die nicht durch das offene Netz kompensiert wurden. Das ist eine große Enttäuschung. Hunderttausende von Menschen sind als direkte Folge davon gestorben.“
Kapitel vier: Brendan Eich
Brendan Eich, CTO der Mozilla Corporation, einer Tochtergesellschaft der Mozilla Foundation, ist verantwortlich für die kontinuierliche Entwicklung des Firefox-Browsers und Schöpfer von Javascript, der meistgenutzten Programmiersprache im Web. Brendan studierte Physik in Santa Clara, wo er das Programmieren erlernte. Brendan sagt, dass er sich für Unix und C interessierte, aber sie fingen gerade erst mit dem alten DEC Iron an. Er hatte einen Portable C Compiler und begann, Code zu erstellen und mit der Portierung von Unix-Dienstprogrammen herumzuspielen. Nach Brendans Beobachtung schrieben mehr Leute Code mit mehr High-Level-Abstraktionen als zuvor. Wenn Sie Anwendungen betreiben, die auf Servern weltweit verteilt sind, funktioniert der alte Ansatz nicht mehr. Brendan spricht auch darüber, wie er bei SCI an Kernel- und Netzwerkcode gearbeitet hat. Der Umfang des Sprachhintergrunds, den er verwendete, wuchs mit der Zeit, weil er seine Netzwerkverwaltungs- und Paketschnüffelschicht schrieb. Eich liest nicht nur Code, sondern auch Bücher über Programmierung. Er sagt, dass er die Bücher von Brian Kernighan sehr mochte und sie für sehr gut hielt. Eich liebte auch Knuths Art of Computer Programming, Band 1 – 3.
Lieblingszitat des Kapitels: „[Assenbly level programming] trennt irgendwie immer noch die Brusthaar-geschlechtsunabhängigen Programmierer von denen, die es nicht ganz haben.“
Kapitel fünf: Joshua Bloch
Joshua Bloch ist der derzeitige Java-Chefarchitekt bei Google und ein ehemaliger Ingenieur bei Sun Microsystems. Er war federführend bei der Entwicklung und Implementierung des Java Collections Framework, das in Java 2 eingeführt wurde. Joshua lernte das Programmieren, insbesondere Fortran, von seinem Vater, als er um 1971 einen Programmierkurs besuchte. Im Jahr 1977 schrieb Joshua eine Version des Spiels „Zwanzig Fragen“, das unter dem Namen „Animals“ bekannt ist. Dies war das erste spannende Programm, das er schrieb. Joshua betont, dass Entwickler häufig Bücher wie Design Patterns lesen sollten, die ein gemeinsames Vokabular, gute Ideen und ein Sammelsurium von Stilen und Sprachen enthalten. Ein weiteres Buch ist Elements of Style, das zwar kein Programmierbuch ist, aber Sie sollten es aus zwei Gründen lesen. Erstens verbessert es Ihren Prosastil und zweitens lassen sich alle Konzepte des Buches auf Programme anwenden. Joshua argumentiert, dass die Notwendigkeit für Mathematik in einer Gemeinschaft, die Compiler, Bibliotheken und Frameworks schreibt, viel größer ist. Wenn Sie Webanwendungen auf der Grundlage von Frameworks schreiben, müssen Sie die visuelle und verbale Kommunikation verstehen. Joshua ist der Meinung, dass intelligente Programmierer in der Regel den schlechtesten Code schreiben. Intelligente Programmierer können sich das Ganze in den Kopf setzen und es verstehen. Und weil sie es verstehen, denken sie, dass es für die Nutzung geeignet ist.
Lieblingszitat aus dem Kapitel: „Wir sind alle Optimisten in unserem Beruf, sonst wären wir gezwungen, uns zu erschießen.“
Kapitel sechs: Joe Armstrong
Joe ist der Schöpfer von Erlang und der Open Telecom Platform, einem Framework für die Entwicklung von Erlang-Anwendungen. Joe hat Physik studiert und in einigen Kursen mussten Programme erstellt werden, was er liebte. Er wurde sehr gut im Debuggen, und die übliche Bezahlung für das Debuggen war zu diesem Zeitpunkt ein Bier. Joe verbringt normalerweise viel Zeit mit Nachdenken, bevor er mit dem Programmieren beginnt. Während dieser Zeit macht er sich aber auch Notizen. Joe Armstrong ist der Meinung, dass aktuelle Widgets Sie nicht produktiver machen. Werfen Sie einen Blick auf Hierarchische Dateisysteme. Wie steigern sie Ihre Produktivität? Gar nicht, denn fast die gesamte Softwareentwicklung findet in Ihrem Kopf statt. Die Arbeit mit einem mühelosen System zwingt Sie zu einer gewissen disziplinierten Denkweise. Sie brauchen Disziplin, wenn Sie kein Verzeichnissystem haben und alle Dateien in einem einzigen Verzeichnis ablegen müssen. Wenn Sie das gleiche Feld auf das anwenden können, was Sie tun, besteht keine Notwendigkeit für hierarchische Dateisysteme. Hierarchische Dateisysteme, zehn zu eins, machen es für Gruppen mühelos, zusammenzuarbeiten. Armstrong ist der Meinung, dass die Wahl der Probleme einen guten Programmierer ausmacht. Sind sie von den Lösungen oder von den Antworten angetrieben? Außerdem rät er jungen Programmierern, verschiedene Sprachen zu erlernen, da dies ihre Fähigkeiten, ihre Flexibilität und ihr Wissen über andere Sprachen verbessert.
Lieblingszitat des Kapitels: „Ich denke, der Mangel an Wiederverwendbarkeit kommt bei objektorientierten Sprachen vor, nicht bei funktionalen Sprachen. Denn das Problem mit objektorientierten Sprachen ist, dass sie diese ganze implizite Umgebung mit sich herumtragen. Sie wollten eine Banane, bekamen aber einen Gorilla, der die Banane und den ganzen Dschungel in der Hand hielt.“
Kapitel sieben: Simon Peyton Jones
Im Jahr 1987 war er einer der Architekten eines Projekts, das den Weg zur Lösung der Programmiersprache Haskell ebnete. Simon Peyton ist leitender Forscher im Microsoft Research Labor in Cambridge. Auf die Frage nach dem Zusammenhang zwischen Programmierung und Forschung antwortete Simon, dass diese Aspekte in hohem Maße miteinander interagieren. Programmiersprachen machen das Programmieren mühelos. Sie dienen als Benutzeroberfläche für die Programmierung. Daher sind die Erforschung von Programmiersprachen und das Programmieren untrennbar miteinander verbunden. Simon sprach über das Testen von APIs bei Microsoft. Sie leisten großartige Arbeit beim Testen von APIs. Bei einer neuen API versuchen Steven Clarke und sein Team, die Programmierer dabei zu beobachten, wie sie darüber sprechen, was sie zu tun versuchen. Und die Leute, die die API erstellt haben, dazu zu bringen, von einer Glasscheibe aus zuzusehen. Peyton genießt das Programmieren, wenn er versucht, ein Programm mit intellektueller Integrität zu schreiben. Er fügt hinzu, dass man ein Programm auch mit Schlamm beschmieren kann, und es wird eine ganze Weile funktionieren, aber nicht zufriedenstellend sein. Daher ist eine der guten Eigenschaften eines guten Programmierers, dass er immer versuchen sollte, auch in technischen Situationen bewegende Lösungen zu finden.
Lieblingszitat des Kapitels: „Manchmal bedeutet die Aussage, dass es offensichtlich richtig ist, nicht, dass Sie ohne geistiges Gerüst erkennen können, dass es richtig ist. Es kann sein, dass man Ihnen eine Einsicht vermitteln muss, um herauszufinden, warum es richtig ist.“
Kapitel acht: Peter Norvig
Peter Norvig ist ein umfassender Denker und Hacker im Herzen. Einmal hat er ein Programm entwickelt, um eine Serie von drei Suchanfragen desselben Benutzers in den Suchprotokollen von Google zu erkennen. Peter lernte das Programmieren in der High School, die Schule hatte eine Ph.D.-8, und er nahm einen Kurs, der mit BASIC-Programmierung begann. Peters erster interessanter Code, den er schrieb, war das Spiel des Lebens. Er sagt, es war eine Klassenübung, die er schnell erledigte. Peter arbeitete für ein Softwareunternehmen in Cambridge. Ihr Produkt war ein Software-Design-Toolset und verschiedene Arten von Software-Beratung. Eines der Projekte des Unternehmens bestand darin, einen Flussdiagrammzeichner zu entwickeln, der Ihr Programm analysierte und ein Flussdiagramm dafür erstellte. Peter betonte, dass Entwickler neben dem Schreiben von Code auch andere Fähigkeiten haben sollten. Fähigkeiten wie das Verstehen der Bedürfnisse der Kunden, Kommunikation und Problemlösung. Laut Peter ist das Programmieren heute mehr eine soziale Aktivität als früher. Früher waren die Computer stärker voneinander getrennt, und es handelte sich eher um Stapelverarbeitung, so dass die Schnittstelle etwas einfacher war. Peter Norvig hält nichts von Googles Ansatz, in Interviews Rätselfragen zu stellen. Er zieht es vor, die Interviewpartner in eine technische Situation zu versetzen, anstatt nur zu plaudern, damit Sie ein Gefühl dafür bekommen, dass sie der richtige Mann sind.
Lieblingszitat des Kapitels: „Ich glaube, eines der wichtigsten Dinge ist, dass man alles gleichzeitig im Kopf behalten kann. Sie haben eine viel bessere Chance auf Erfolg, wenn Sie das können. Das macht ein kleines Programm einfacher. Für ein umfangreicheres Programm brauchen Sie zusätzliche Tools, um das zu bewältigen.“
Kapitel neun: Guy Steele
Auf die Frage, welche Sprachen Guy Steele verwendet hat, war Guy Steele, eigentlich ein polyglotter Programmierer, tatsächlich polyglott programmiert. Er hat diese Liste erstellt: Fortran, COBOL, IBM, PDP-10 Maschinensprache, APL, C, C++, BLISS, Haskell, FOCAL, TEGO und TeX. „Das sind die wichtigsten, denke ich“, fügt er hinzu. Zum Programmieren kam Guy durch einen Schulfreund, der ihn mit ein paar Zeilen des Fortran-Programms faszinierte. Nachdem er Fortran gelernt hatte, machte Guy weiter und lernte die IBM 1130 Assemblersprache. Sein erstes spannendes Programm sollte Schlüsselwort-in-Kontext-Indizes erstellen. Und IBM bot Schnellindizes für ihre Handbücher an, in denen Sie, wenn Sie eine Tastatur eingeben, in den Indizes nachschlagen konnten. Es war alphabetisch nach der Tastatur geordnet, aber auf beiden Seiten der Tastatur wurden verschiedene Wörter aus dem Kontext angezeigt, in dem das Wort stand. Steele hatte mit verschiedenen Maschinen auf dem Campus zu tun, wie der DEC PDP-10. Zu dieser Zeit besaß Harvard eine PDP-10 für die Arbeit der Graduierten. Die Studenten benutzten nur die Fernschreibterminals eines kommerziellen Systems, das die Schule gemietet hatte. Steele nannte auch einige der wichtigsten Bücher, die er gelesen hatte und die seine Programmierkenntnisse förderten, darunter Knuth und The Art of Computer Programming. Außerdem behauptet Guy Steele, dass junge Programmierer ihre Daumen nicht benutzen, wenn sie versuchen, zu zählen. Auf der anderen Seite hat sich der Kampf gegen die Inkompatibilität der Zehnerbasis mit zwei Potenzen deutlich verbessert.
Lieblingszitat des Kapitels: „Ich denke, es gibt also Lektionen – die Lektion, die ich hätte ziehen sollen, ist, dass es hier mehr als einen Fehler geben kann und ich beim ersten Mal besser hätte suchen sollen. Eine andere Lektion ist, dass, wenn ein Fehler als selten angesehen wird, die Suche nach selten ausgeführten Pfaden fruchtbar sein kann. Und drittens war es einfach unglaublich, eine gute Dokumentation darüber zu haben, was der Algorithmus zu tun versucht, nämlich einen Verweis auf Knuth.“
Kapitel zehn: Dan Ingalls
Dan Ingalls, einer der Mitbegründer von Smalltalk. Er begann mit der ersten Version von Smalltalk, geschrieben in BASIC. Er war an der Implementierung von sieben Generationen von Smalltalk beteiligt, vom Prototyp bis zur aktuellen Open-Source-Implementierung, Squeak. Dan ist als Erfinder aufgewachsen und hat am College Physik studiert. Er belegte einen Programmierkurs in Fortran in Harvard. Ingalls startete ein Programm, nachdem er ein Unternehmen gegründet hatte. Es diente dazu, Programme auszuwerten und ihr dynamisches Verhalten zu beobachten, einfach ausgedrückt: Profiling. Es gab ein Programm, das ein Fortran-Programm durchforstete und an jedem Verzweigungspunkt Zähler platzierte. Dan erstellte eine bessere Version des Programms, die über einen Timer-Interrupt-Prozess verfügte, um zu verfolgen, wie viel Echtzeit für verschiedene Teile des Programms aufgewendet wurde. Dan hat immer noch so viel Spaß am Programmieren wie in seinen Anfängen. Er sagt, dass die letzten zwei Jahre sehr interessant waren, da er von einer vertrauten Umgebung – Smalltalk – zu Squeak wechselte, wo die Werkzeuge großartig waren. Dan rät Nachwuchsentwicklern, verschiedene Sprachen mit unterschiedlichen Stärken zu lernen. Er fügt hinzu, dass es sich für Entwickler lohnt, mehrere verschiedene Computerumgebungen zu nehmen und ein Problem zu lösen.
Lieblingszitat des Kapitels: „Verschiedene Menschen haben verschiedene Stufen, die sie erreichen müssen, um ein gutes Gefühl bei dem zu haben, womit sie arbeiten. Ich denke also, dass jemand eine Bibliothek mit Sammlungen durchaus selbstbewusst nutzen kann, ohne sie selbst programmiert zu haben.“
WIE DIESES BUCH SOFTWAREENTWICKLERN HELFEN KANN
„Coders at Work“ ist eine Sammlung von Interviews, die Peter Seibel mit einigen der erfolgreichsten und erfahrensten Programmierer unserer Zeit geführt hat. Diese Programmierer teilen in diesem Buch ihre Einsichten, Erfahrungen und Weisheiten über Softwareentwicklung. Die Lektüre dieses Buches kann Softwareentwicklern helfen, die Branche besser zu verstehen, von den Erfahrungen erfolgreicher Programmierer zu lernen und ihre Fähigkeiten und Perspektiven zu entwickeln. Das Buch kann Entwickler dazu inspirieren, kreativ zu denken und sich selbst herauszufordern, um bessere Programmierer zu werden.
