Programmieren in zehn Jahren selbst lernen (1998)

 (norvig.com)
3 Punkte von GN⁺ 2024-01-16 | 1 Kommentare | Auf WhatsApp teilen
  • Programmierfähigkeit entsteht kaum durch 24-Stunden- oder 21-Tage-Einführungsbücher; was man durch kurzes Lernen gewinnt, ist meist eher oberflächliche Vertrautheit
  • Forschungen zu Expertise in verschiedenen Bereichen wie Schach, Komposition, Malerei, Schwimmen und Forschung zeigen, dass es bis zu einem hohen Niveau ungefähr 10 Jahre dauert; entscheidend ist nicht bloße Wiederholung, sondern gezieltes Üben
  • Wer ein guter Programmierer werden will, sollte den Spaß daran bewahren, selbst Dinge bauen, Code anderer lesen, mit besseren Leuten zusammenarbeiten und Feedback erhalten
  • Hochschulbildung und Bücher können Qualifikation, Struktur und Tiefe ergänzen, ersetzen aber nicht die Erfahrung, in realen Projekten Fehler zu beheben und Wartung mitzuerleben
  • Die erste Sprache kann man nach Freunden und Community, Einfachheit und interaktiver Ausführungsumgebung auswählen; wichtig ist, eine auszuwählen und konsequent anzufangen

Die Grenzen des Versprechens, Programmieren in kurzer Zeit zu lernen

  • In Buchhandlungen und online gibt es viele Bücher, die versprechen, Java, C, SQL, Ruby, Algorithmen und anderes in wenigen Tagen oder Stunden zu vermitteln
    • Eine erweiterte Suche bei Amazon zeigte für Bücher seit 2000 mit teach yourself hours im Titel 512 Treffer, und 9 der Top 10 waren Programmierbücher
    • Ersetzt man teach yourself durch learn oder hours durch days, ergeben sich ähnliche Resultate
  • Solche Titel erwecken den Eindruck, dass Menschen Programmieren eilig lernen wollen oder dass Programmieren viel leichter zu lernen sei als andere Fachgebiete
  • Felleisen et al. persiflieren diesen Trend in How to Design Programs sinngemäß mit: „Schlechtes Programmieren ist leicht. Selbst Dummköpfe können es in 21 Tagen lernen“

Was „Teach Yourself C++ in 24 Hours“ tatsächlich bedeuten kann

  • Teach Yourself

    • In 24 Stunden bleibt keine Zeit, mehrere sinnvolle Programme zu schreiben, aus Erfolgen und Misserfolgen zu lernen, mit erfahrenen Programmierern zusammenzuarbeiten und zu verstehen, was es heißt, in einer C++-Umgebung zu leben
    • Daher ist eher oberflächliche Vertrautheit möglich als tiefes Verständnis

  • C++

    • Wenn man bereits eine andere Sprache kennt, kann man in 24 Stunden Teile der C++-Syntax lernen
    • Aber es ist schwer zu lernen, wofür C++ gut oder schlecht ist und wie man die Sprache in der Praxis wirklich einsetzen sollte
    • Wie Alan Perlis sagte: „Eine Sprache, die Ihr Denken über Programmierung nicht verändert, ist es nicht wert, gekannt zu werden“

  • 24 Hours

    • Man kann ein wenig C++, JavaScript, Processing oder Ähnliches lernen, um es mit einem bestimmten Tool zu verbinden
    • In diesem Fall lernt man eher, eine bestimmte Aufgabe auszuführen, als Programmierung an sich

Expertise braucht Zeit

  • Studien von Bloom, Bryan & Harter, Hayes, Simon & Chase und anderen zeigten, dass der Aufbau von Expertise in verschiedenen Bereichen ungefähr 10 Jahre dauert
    • Zu den Beispielbereichen zählen Schach, Komposition, Telegrafie, Malerei, Klavier, Schwimmen, Tennis sowie Forschung in Neuropsychologie und Topologie
  • Entscheidend ist nicht bloße Wiederholung, sondern gezieltes Üben (deliberative practice)
    • Man wählt Aufgaben, die etwas über dem aktuellen Können liegen
    • Man analysiert die Ergebnisse während und nach der Ausführung
    • Man korrigiert Fehler und wiederholt erneut
  • Mozart war mit 4 Jahren ein musikalisches Wunderkind, brauchte aber weitere 13 Jahre, bis er Musik von Weltniveau schuf
  • Die Beatles wurden 1964 durch die Ed Sullivan Show und Nummer-eins-Hits bekannt, spielten aber seit 1957 in kleinen Clubs in Liverpool und Hamburg; ihr von der Kritik stark gefeiertes Sgt. Pepper’s erschien 1967
  • Malcolm Gladwell popularisierte den Ausdruck 10.000 Stunden, doch wichtiger als die genaue Zahl ist kontinuierliches Üben über Jahre hinweg
  • Für K. Anders Ericsson sind 10.000 Stunden eine Zahl, die verdeutlicht, dass selbst talentierte Menschen über viele Jahre 10 bis 20 Stunden pro Woche benötigen, um Spitzenleistungen zu erreichen
  • Eine einzelne Zahl kann nicht die ganze Antwort sein
    • Es ist schwer anzunehmen, dass Programmierung, Schach, Dame und Musik exakt dieselbe Zeit erfordern
    • Ebenso ist schwer anzunehmen, dass alle Menschen im selben Tempo lernen

Praktiken, um Programmierer zu werden

  • Man sollte Interesse am Programmieren haben und aus Spaß beginnen
    • Der Spaß muss lange genug anhalten, um 10 Jahre oder 10.000 Stunden zu investieren
  • Man muss selbst programmieren
    • Das beste Lernen ist Lernen durch Ausführen
    • Wirksames Lernen braucht klar definierte Aufgaben mit individuell passendem Schwierigkeitsgrad, hilfreiches Feedback sowie Gelegenheiten zur Wiederholung und Fehlerkorrektur
  • Man sollte mit anderen Programmierern sprechen und Programme lesen, die andere geschrieben haben
    • Das ist wichtiger als jedes Buch oder jeder Kurs
  • Wenn man möchte, kann man vier Jahre an einer Hochschule verbringen oder in der Graduate School weiterstudieren
    • Ein Abschluss kann den Zugang zu Berufen eröffnen, die formale Qualifikation verlangen, und ein tiefes Verständnis des Fachs vermitteln
    • Wenn einem die Schule keinen Spaß macht, kann man durch Hingabe auch selbstständig oder in der Praxis ähnliche Erfahrungen sammeln
    • Allein aus Büchern zu lernen, reicht nicht aus
  • Man sollte gemeinsame Projekte mit anderen Programmierern durchführen
    • In manchen Projekten kann man der beste Programmierer sein und Führungsfähigkeit sowie Vision testen
    • In anderen Projekten kann man die schwächste Person sein und lernen, was Könner tun und was sie nicht tun wollen
  • Man sollte sich mit bestehenden Projekten befassen, nachdem andere Programmierer gegangen sind
    • Man lernt, was nötig ist, um Programme anderer zu verstehen und zu korrigieren
    • Man denkt auch darüber nach, wie man so entwirft, dass spätere Wartende damit zurechtkommen

Breite Erfahrung mit Sprachen und Systemen

  • Man sollte mindestens sechs Programmiersprachen lernen
    • Eine Sprache, die Klassenabstraktion betont: Java, C++
    • Eine Sprache, die funktionale Abstraktion betont: Lisp, ML, Haskell
    • Eine Sprache, die syntaktische Abstraktion unterstützt: Lisp
    • Eine Sprache, die deklarative Spezifikation unterstützt: Prolog, C++ templates
    • Eine Sprache, die Parallelität betont: Clojure, Go
  • Man sollte daran denken, dass in „computer science“ das Wort computer steckt
    • Man sollte wissen, wie lange Befehlsausführung, das Holen eines Words aus dem Speicher, Cache Misses, sequenzielles Lesen von der Festplatte, Disk-Seeks und Ähnliches dauern
  • Es kann auch helfen, sich an der Standardisierung von Sprachen zu beteiligen
    • Das kann eine große Aktivität wie das ANSI-C++-Komitee sein oder nur die Festlegung im lokalen Coding Style, ob Einrückungen 2 oder 4 Leerzeichen haben sollen
    • Man kann lernen, was andere Menschen an Sprachen mögen und warum sie dabei starke Gefühle entwickeln
  • Bei Standardisierungsaktivitäten braucht man auch die Urteilskraft, so schnell wie möglich wieder auszusteigen

Bücher und Ausbildung allein reichen nicht aus

  • Auch wenn man viele Bücher über Kindererziehung liest, kann man sich beim ersten Kind wie ein Anfänger fühlen; beim zweiten Kind stützt man sich eher auf persönliche Erfahrung, statt wieder zu den Büchern zurückzukehren
  • Fred Brooks’ No Silver Bullet schlägt einen dreiteiligen Plan vor, um hervorragende Software-Designer zu finden
    • Herausragende Designer so früh wie möglich systematisch identifizieren
    • Einen Karriere-Mentor zuweisen, der die Entwicklung verantwortet und die Karriereakte verwaltet
    • Wachsenden Designern Möglichkeiten geben, miteinander zu interagieren und sich gegenseitig anzuregen
  • Alan Perlis sagte: „Jeder kann lernen, Bildhauerei zu betreiben, aber Michelangelo hätte man wohl beibringen müssen, nicht zu bildhauern“
  • Hervorragende Programmierer können innere Eigenschaften besitzen, die über Training hinausgehen; ob diese angeboren sind oder durch Fleiß entwickelt werden, wird jedoch nicht festgelegt
  • Bücher über Java, Ruby, JavaScript und PHP können nützlich sein, verändern aber weder das Leben noch die gesamte Expertise in 24 Stunden oder 21 Tagen
  • 24 Monate lang hart daran zu arbeiten, sich weiter zu verbessern, ist ein sinnvoller Ausgangspunkt

Zeitgefühl für Computeroperationen

  • Auf einem typischen PC dauern verschiedene Operationen ungefähr wie folgt
    • Ausführung einer normalen Instruktion: 1 Nanosekunde
    • Holen aus dem L1-Cache-Speicher: 0,5 Nanosekunden
    • Fehlgeschlagene Branch Prediction: 5 Nanosekunden
    • Holen aus dem L2-Cache-Speicher: 7 Nanosekunden
    • Mutex sperren/entsperren: 25 Nanosekunden
    • Holen aus dem Hauptspeicher: 100 Nanosekunden
    • 2 KB über ein 1-Gbps-Netzwerk senden: 20.000 Nanosekunden
    • 1 MB sequenziell aus dem Speicher lesen: 250.000 Nanosekunden
    • Seek zu einer neuen Position auf der Festplatte: 8.000.000 Nanosekunden
    • 1 MB sequenziell von der Festplatte lesen: 20.000.000 Nanosekunden
    • Paket-Roundtrip zwischen den USA und Europa: 150 Millisekunden, also 150.000.000 Nanosekunden

Kriterien für die Wahl der ersten Programmiersprache

  • Auf die Frage nach der ersten Sprache gibt es keine einzige richtige Antwort
  • Freunde und Community können ein Kriterium sein
    • Das ähnelt der Antwort, beim Betriebssystem das zu verwenden, was die Freunde verwenden
    • Der Vorteil, von Freunden lernen zu können, kann Unterschiede zwischen Betriebssystemen oder Sprachen ausgleichen
    • Man sollte auch berücksichtigen, ob es für die gewählte Sprache eine wachsende Community, Bücher, Websites und Online-Foren gibt
  • Einfachheit ist wichtig
    • C++ und Java wurden dafür entworfen, dass erfahrene Programmierer in großen Teams professionelle Entwicklung betreiben, und enthalten komplexe Teile, die auf Ausführungseffizienz Rücksicht nehmen
    • Anfänger brauchen diese Komplexität nicht
  • Eine interaktive Ausführungsumgebung erleichtert das Lernen
    • Es ist wie beim Klavierspielen: Es ist leichter zu lernen, wenn man sofort nach dem Drücken einer Taste den Ton hört, statt erst nach Abschluss des ganzen Stücks im Batch-Verfahren zuzuhören
    • Auch beim Programmieren sind Sprachen im Vorteil, die einen interaktiven Modus bieten
  • Nach diesen Kriterien werden Python oder Scheme als erste Sprache empfohlen
  • JavaScript kann eine Option sein, nicht weil es perfekt für Anfänger entworfen wurde, sondern weil es viele Online-Tutorials gibt
  • Lernende im einstelligen Alter bevorzugen möglicherweise Alice, Squeak oder Blockly; auch ältere Lernende können daran Freude haben
  • Wichtig ist, eine auszuwählen und anzufangen

Empfohlene Bücher und Materialien

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-16
Meinungen auf Hacker News

  • 1999 kaufte ich bei CompUSA „Sams Teach Yourself C++ in 24 Hours“. Der Kassierer sah es, lachte und machte mich auf diesen Artikel aufmerksam.
    Als ich mit 16 bei Borders Programmierbücher ansah, drückte mir jemand „The C Programming Language“ in die Hand, und das hat mein Leben verändert.
    Ein beträchtlicher Teil meiner Laufbahn wurde dadurch geprägt, dass ich in der realen Welt zufällig Entwickler oder Menschen traf, die sich für Programmierung interessierten.

    • Einige dieser Bücher waren wirklich lächerlich schlecht, aber damals fühlte sich ein einziges Buch wie der Startschlüssel an, mit dem man die seltsamen Programmideen im Kopf tatsächlich bauen konnte.
      Das letzte Mal hatte ich dieses Gefühl, als ich mit einem neuen MacBook und einem iPod Touch aus dem Microcenter kam und mich bereit fühlte, das nächste Angry Birds zu entwickeln.
    • Das Buch, das mein Leben verändert hat, war das BASIC-Handbuch, das dem C64 beilag.
      Auch als ich etwa acht Jahre später Turbo Pascal kaufte, war alles Nötige an Material enthalten, sodass ich es schnell lernen konnte. Und als ich 1995 mit Linux anfing, konnte ich allein mit man-Pages und info-Dokumentation fast alles lernen, was ich brauchte, um auf diesem System Programme zu schreiben.
      Ich erinnere mich auch daran, Ende der 90er das EGCS-Handbuch von vorne bis hinten gelesen zu haben.
      Ich vermisse die Zeiten, in denen Software alle nötigen Informationen mitlieferte, und finde es schade, dass man heute Google durchforsten muss, um Produktseiten oder Handbücher zu finden.
      In etwa fünf Jahren werden wir wahrscheinlich sogar die Google-Suche vermissen, die wir statt Handbüchern genutzt haben, weil die relevanten Informationen nur noch auf Discord stehen und nicht indexiert werden.
      Socket-Programmierung unter Linux und FreeBSD Anfang der 2000er habe ich ebenfalls nur über man-Pages gelernt; als ich später Stevens’ Buch las, konnte ich es dank der man-Pages und der Erfahrung aus ein paar geschriebenen Programmen schon sehr schnell durcharbeiten.
    • „Visual Basic Professional 3.0 Programming by Thomas W. Torgerson“, das ich 1997 bei Barnes and Noble kaufte, war mein Ausgangspunkt.
      Ich hatte Visual Basic 3.0 über 100 E-Mail-Anhänge bei AOL heruntergeladen und wollte lernen, wie man Punter/Progs baut.
      Ich kopierte den Code aus dem Buch, um beim Programmstart eine Sounddatei abzuspielen, und war wirklich erstaunt, als es tatsächlich funktionierte.
      Dass ich danach eine Karriere in der Softwareentwicklung aufbauen konnte, war ein großes Privileg.
    • Man sollte nicht über ein kleines Mädchen lachen, das am Programmierregal steht.
      In den 90ern bekam man statt Ratschlägen ziemlich oft nur ungläubige Reaktionen zurück.
    • Ich kann bis zum Schluss behaupten, dass „The C Programming Language“ das beste Buch über eine Programmiersprache ist, das ich je gelesen habe.
      Jeder Entwickler sollte mindestens einmal C und K&R lesen und lernen, selbst wenn er C kurz darauf wieder vergisst.

  • Dieser Artikel hat für mich eine besondere Bedeutung, weil ich ihn zum ersten Mal als Teenager gelesen habe, als ich gerade anfing, Programmieren zu lernen.
    Beim erneuten Lesen war ich überrascht, Malcolm Gladwell darin zu sehen, weil ich in Erinnerung hatte, dass Outliers erst viel später ein Thema wurde.
    Erst der Hinweis auf Ratatouille machte mir klar, dass der Artikel seit seiner Veröffentlichung 1998 aktualisiert worden war; das Original ist im Archiv erhalten und deutlich kürzer: https://web.archive.org/web/19980206223800/https://norvig.co...
    Es verdient Respekt, dass Peter Norvig seinen eigenen Text über Jahre hinweg immer weiter überarbeitet hat.

    • Vielleicht, weil ich Gladwell in der Highschool als Pflichtlektüre lesen musste, mag ich ihn bis heute nicht besonders.
      Er wird viel zu oft zitiert, und die 10.000-Stunden-Regel fühlt sich inzwischen einfach wie ein Meme an.
    • Ich erinnere mich daran, wie ich diesen Artikel vor zehn Jahren im Computerraum der Universitätsbibliothek las.
      Heute habe ich mir Programmieren im Selbststudium beigebracht, aber der Weg war viel schwieriger und verschlungener, als ich es mir damals vorgestellt hatte.
    • Vor „Outliers“ gab es bereits „The Tipping Point“ und „Blink“.

  • Ich lerne zwar auch gern aus Büchern, aber diese Haltung passt oft besser zu nicht-informatischen Bereichen wie Mathematik oder Physik, in denen sich die Dinge langsamer verändern.
    Ein jüngeres Negativbeispiel war das Quantum-Programming-Buch von O’Reilly: Es behandelte Quantenschaltungen nicht ausführlich genug, damit ich wirklich verstanden hätte, was ich da tue.
    Allerdings könnte das auch am Hype um Quantencomputing selbst liegen; Nielsen/Chuang, das ich gerade lese, ist zwar sehr theoretisch, erklärt aber sehr klar, sodass ich später vielleicht noch einmal darauf zurückkomme.
    Bücher sind nur ein Lernwerkzeug, und Hobbyprojekte können sogar ein effektiveres Lernwerkzeug sein, weil man dabei Erfahrung sammelt.
    Trotzdem ist Wissen Macht, und Bücher sind hervorragend darin, einem die richtige Richtung zu weisen – vorausgesetzt, man hat ein Buch gefunden, das zu den eigenen Bedürfnissen passt.
    Ich kenne Leute, die ein Buch gar nicht erst aufschlagen, wenn sie nicht sicher sind, dass sie es bis zum Ende lesen können; diese Haltung finde ich absurd.
    Ich habe gerade O’Reillys Buch Generative Deep Learning bestellt, und wenn ich daraus nur ein paar Dinge mitnehme, die ich in meiner Karriere nutzen kann, hat es sich schon gelohnt.
    Zumindest wird es im Bücherregal gut aussehen.

    • Grundprinzipien ändern sich nicht.
      Jede Woche erscheint ein neues Frontend-Framework, aber am Ende erzeugen sie alle HTML.

  • Das sind Threads aus 16 Jahren
    Reposts sind nach etwa einem Jahr in Ordnung, und die Links zu früheren Threads sind für Leser gedacht, die mehr wissen möchten
    Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=33287618 - Oktober 2022, 112 Kommentare
    Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=27411276 - Juni 2021, 115 Kommentare
    Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=20543495 - Juli 2019, 87 Kommentare
    Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=16574248 - März 2018, 51 Kommentare
    Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=9395284 - April 2015, 61 Kommentare
    Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=5519158 - April 2013, 86 Kommentare
    Teach Yourself Programming in Ten Years by Peter Norvig (2001) - https://news.ycombinator.com/item?id=3439772 - Januar 2012, 29 Kommentare
    Teach Yourself Programming in 10 Years. - https://news.ycombinator.com/item?id=1060176 - Januar 2010, 32 Kommentare
    Teach Yourself Programming in Ten Years - https://news.ycombinator.com/item?id=191235 - Mai 2008, 19 Kommentare
    Norvig: Teach Yourself Programming in Ten Years - https://news.ycombinator.com/item?id=43243 - August 2007, 7 Kommentare

    • Ich frage mich, ob die Leute, die 2007–2013 kommentiert haben, teilen könnten, was sie in den letzten 10 Jahren gelernt haben
    • Ich wünschte, es gäbe eine Möglichkeit, vor dem Posten auf frühere Threads hinzuweisen
    • Ich bin mir nicht sicher, ob das eine Kritik daran ist, dass es zu viele Reposts gibt, oder ob gemeint ist, dass eine Wiederholung etwa einmal pro Jahr eine gesunde Duplizierung ist

  • Beeindruckend ist, dass der alte Amazon.com-Link auf der Seite trotz ziemlich komplexer Query-Parameter noch immer relevante Ergebnisse liefert
    Ein gutes Beispiel für „Cool URIs don't change“
    [0] http://www.amazon.com/gp/search/ref=sr_adv_b/?search-alias=s...
    [1] https://www.w3.org/Provider/Style/URI

    • Interessanterweise gibt dieser Amazon-Link bei mir einen Fehler zurück

  • Ich habe ziemlich viele Leute getroffen, die gefragt haben, wie man im Job oder anderswo an eine Programmierstelle kommt.
    Wenn ich meinen Weg schildere — dass ich schon als Kind angefangen habe zu lernen, es zu einem großen Hobby gemacht habe und dann ein Informatikstudium samt Praktika durchlaufen habe — sind sie überrascht und enttäuscht, dass es keinen schnellen Weg gibt.
    Oder gibt es vielleicht doch einen schnellen Weg? Ich frage mich, ob es Leute gibt, die ein Bootcamp von 0 auf 1 erfolgreich abgeschlossen haben.

    • Ich komme aus einem Bootcamp und programmiere seit acht Jahren professionell.
      In der Highschool und an der Uni habe ich aus Spaß ein paar Programmierkurse belegt, aber mein Wissen war sehr begrenzt.
      Das Bootcamp hat seinem Namen alle Ehre gemacht: Die regulären Zeiten waren 9 bis 17 Uhr, aber viele kamen um 7 Uhr morgens und gingen um 22 Uhr.
      Wir waren auch am Wochenende dort; manchmal war nur der Sonntag frei.
      Ich habe absichtlich ein Bootcamp in einer anderen Stadt gewählt, damit mich mein Sozialleben nicht ablenkt.
      Der Schwerpunkt lag auf Ruby und JavaScript, und ein paar Monate nach dem Abschluss bekam ich eine Stelle als C#/.NET-Praktikant.
      Eine direkte Junior-Developer-Stelle schien schwer zu vermitteln, also entschied ich mich für ein Praktikum und wurde nach zwei Wochen zum Junior Developer befördert.
      Die Schule wurde später von Kaplan übernommen und verschwand danach.
    • Die Leute, die mit Bootcamps Erfolg hatten, waren entweder ohnehin sehr intelligent oder kamen aus einem technischen bzw. höheren Mathematik-Hintergrund.
    • Ich habe Informatik nach drei Monaten abgebrochen und davor nie programmiert.
      Im Keller im Haus meiner Mutter habe ich mir acht Monate lang die JavaScript-Grundlagen selbst beigebracht und konnte dann einen Job finden.
      Danach habe ich enorm viel Zeit ins Programmieren gesteckt und komme inzwischen auf Zehntausende Stunden.
      Ich habe mit Compilern, 3D-Grafik, Halbleitern und Game Engines gearbeitet.
      Meine Erfahrung scheint beide Seiten zu stützen.
      Um 2012 herum konnte man mit wenig Erfahrung noch relativ leicht in die Branche einsteigen, aber danach erforderte es enorme Anstrengung, ein guter Engineer zu werden, den Leute mit interessanten Projekten einstellen wollen.
    • Ich habe schon Bootcamp-Absolventen eingestellt, aber selbst keines gemacht.
      Nach meinen begrenzten Daten ist es wie bei traditionell ausgebildeten Entwicklern ein Glücksspiel.
      Die besten Ergebnisse gab es bei Leuten mit klassischer Ausbildung in Bereichen wie Physik, Chemie oder Ingenieurwesen, die einen Karrierewechsel wollten; sie waren eher fortgeschrittene Juniors mit steiler Lernkurve.
      Wenn man motivierte Einsteiger in Softwarebereiche bringen will, in denen reines Programmieren weniger wichtig ist, können das hervorragende Einstellungen sein.
      Die Standardabweichung ist groß, aber ob sie größer ist als bei Absolventen zweijähriger Programme, weiß ich nicht.
    • Ich habe ein Graduate Program bei einer Consulting-Firma durchlaufen, die einen drei Monate ausbildet und dann mit einem Zweijahresvertrag arbeiten lässt.
      An der Uni habe ich Geisteswissenschaften studiert und vorher nie gecodet.
      Die ersten zwei Jahre waren wirklich hart, und weil mir die Grundlagen fehlten, fühlte es sich die ganze Zeit an, als würde ich gegen die Strömung schwimmen.
      Erst gegen Ende des zweijährigen Programms hatte ich das Gefühl, eigenständig Wert liefern zu können.
      Mein Wissen ist ziemlich anwendungsorientiert, und weil mir Informatikgrundlagen fehlen, muss ich zwischendurch immer wieder Basics nachholen, was es manchmal schwieriger macht.
      Allerdings bin ich in meiner aktuellen Rolle Data Engineer, daher werden klassische Informatikbereiche wie Datenstrukturen und Algorithmen vergleichsweise weniger verlangt.

  • Der Kern ist gezieltes Üben.
    Nicht einfach nur Wiederholung, sondern Aufgaben angehen, die etwas über dem aktuellen Können liegen, sie versuchen, währenddessen und danach analysieren, Fehler korrigieren und dann wiederholen.
    Um weiter zu lernen, muss man sich selbst herausfordern und die Komfortzone verlassen.

    • Ich frage mich, wie AI-Tools wie GitHub Copilot die Lerngewohnheiten der Leute verändern werden.
      Ich habe es ein paar Monate genutzt und wurde dann zufällig ausgeloggt; die kleine Unbequemlichkeit, offizielle Dokumentation nachzuschlagen, empfinde ich inzwischen eher als wertvoll.
      In der ersten Woche war ich überrascht, wie viel langsamer ich mich fühlte.
      Zusätzliche Schritte zu gehen, um aus Primärquellen zu lernen, und gelegentlich Unbequemlichkeit wertzuschätzen, ist wichtig, um als Programmierer zu wachsen.
    • Aus der Sicht eines Softwareentwicklers mit Erfahrung als Tutor/Teaching Assistant mache ich mir Sorgen, ob die nächste Generation von Entwicklern wirklich coden können wird.
      Besonders wenn Aufgaben auf dem Niveau des ersten oder zweiten Studienjahrs nur mit Copilot erledigt wurden, könnte man damit die eigene Nützlichkeit wegautomatisieren.
      Andererseits haben wir Ähnliches über „iPad-Kids“ gesagt.
      Auch das iPad hat ein Dateisystem, und Apps werden innerhalb der von Apple genehmigten Wege immer funktionsreicher, sodass ich es nicht für eine schlechte Annäherung an einen Laptop halte.
      Ich nutze Copilot auch, aber vor allem als intelligente Autovervollständigung für das Setzen von Variablen oder kleine repetitive Arbeiten.
      Es soll Zeit sparen, die man sonst für das Kontextualisieren von Problemlösungen und die Interaktion mit Teammitgliedern bräuchte; es ist kein Ding, das Engineers ersetzt.
    • Das stimmt, aber besser formuliert ist der Kern, aus Hobby zu bauen.
      Professionalität kommt aus Erfahrung, und Erfahrung entsteht nur, wenn man immer wieder zurückkommt.
      Manche Menschen können sich dazu antreiben, endlos zu leiden, aber für normale Menschen ist es klug, mit einem Teil von Software anzufangen, den sie aufrichtig lieben können, und ihn wachsen zu lassen.
    • Man muss es mögen, herausgefordert zu werden.
      Ich habe gesehen, wie Leute, die im Coding deutlich klüger waren als ich, ausgestiegen sind, weil sie zu klug waren.
      Entweder fühlte es sich für sie nicht mehr herausfordernd an, oder sie waren von der falschen Art Herausforderung erschöpft, etwa „darauf zu warten, dass die anderen nachkommen“.
      Das waren meist Leute, die an Spitzentechnologien arbeiteten, die ein paar Jahre später zum Standard wurden.
      Wenn Faszination die Motivation ist, kann man sich vielleicht glücklich schätzen, nicht allzu klug zu sein.
    • In der Bildungstheorie nennt man das die Zone der nächsten Entwicklung.

  • Obwohl der Text als Artikel von 1998 gekennzeichnet ist, enthält er Erwähnungen wie Clojure und Go, daher scheint er später aktualisiert worden zu sein.

    • Am Ende der Seite steht Peter Norvig (Copyright 2001—2014).

  • Guter Text.
    Bei 8 Stunden pro Tag und 40 Stunden pro Woche dauert es 250 Wochen, um 10.000 Stunden zu erreichen.
    Selbst wenn man fast ohne Pause programmiert, sind das etwa 5 Jahre; realistisch liegt man eher näher bei 10 Jahren, bis man das Ziel erreicht.

    • Realistisch hängt es davon ab, wie sehr man Programmieren genießt.
      Wenn man viel programmiert, kommt man leicht auf 3.000 Stunden im Jahr.
      Ich programmiere an den meisten Tagen 12 Stunden am Tag, in den meisten Wochen 6 bis 7 Tage pro Woche.
      An Tagen mit sehr hoher Motivation auch 18 Stunden.
      Das mache ich seit fast 10 Jahren so; gelegentlich nehme ich etwa einen Monat frei oder reduziere auf 3 bis 4 Tage pro Woche mit langen Arbeitszeiten.
      Selbst konservativ gerechnet sind das etwa 3.500 Stunden pro Jahr.
      Ich arbeite so viel, weil ich Programmieren wirklich liebe und es abgesehen vom Surfen am Morgen nichts gibt, was ich lieber tun würde.
    • Die 10.000-Stunden-Heuristik ist nicht besonders präzise, sondern einfach nur berühmt.
      Trotzdem scheinen etwa 10 Jahre Berufserfahrung im Großen und Ganzen zu passen, um ein solider Entwickler zu werden.
      Ich habe noch niemanden gesehen, der dieses Niveau wirklich nach 5 Jahren erreicht hat.
      Wer schon als Teenager obsessiv damit angefangen hat, kann ein paar Jahre abziehen, aber ab einem gewissen Punkt überschneidet sich diese Zeit ebenfalls.
      Natürlich gibt es auch den alten Spruch, dass das Problem darin besteht, „1 Jahr Erfahrung 10-mal zu wiederholen“.
      Ich habe auch viele Entwickler mit über 10 Jahren Erfahrung gesehen, die nicht solide waren.
    • Sind 40 Stunden pro Woche über 5 Jahre nicht im Grunde ein Software-Job?
      Es sieht so aus, als könne man in einer Junior-Rolle einsteigen und sich über 5 Jahre Arbeit hocharbeiten.
    • Das ist in jedem Beruf so.
      Intuition baut sich auf, indem man immer schwierigere Aufgaben angeht.
      Irgendwann kann man Wissen aus einem Bereich mit einem anderen verbinden und dort anwenden, und dann beginnt Kreativität zu wirken.

  • Ich finde die Quelle des Videos nicht mehr, das ich vor 5–6 Jahren gesehen habe, aber die Kernaussage war, dass mit der wachsenden Zahl an Programmierern die Mehrheit weniger als 5 Jahre Berufserfahrung hat.
    Im Kontext dessen, dass IT und Web immer stärker in unser Leben eingreifen, ergab das Sinn.
    [0] https://youtu.be/ecIWPzGEbFc?si=A4qBR2YdX-0CV2bM dank des Kommentars von wild_egg gefunden.
    Nach 20 Jahren merke ich, dass es inzwischen ziemlich viele Informationen gibt, die ich nicht mehr wissen muss, und vieles, was Leute mit weniger als 5 Jahren Erfahrung wahrscheinlich überhaupt nicht brauchen.
    Andererseits ist Erfahrung eben Erfahrung, und es hilft immer, die Struktur der Dinge und den Grund ihrer Existenz zu kennen.
    Es gibt auch viele Programmierer mit weniger Erfahrung als ich, die vieles tun können, was ich mir nicht einmal vorstellen kann.
    Ehrlich gesagt ist dieses Feld mit Turing-Vollständigkeit ziemlich groß.

    • Ich programmiere seit 40 Jahren, davon 33 Jahre beruflich, aber abgesehen von Scrum fällt mir nichts ein, bei dem ich denke, dass es verschwendet war, es zu lernen.
      Syntax habe ich nie separat auswendig gelernt; ich habe immer mit geöffneten man-Pages und Handbüchern programmiert.
      Aber jede Sprache und jede Technik, die ich gelernt habe, hat mir etwas Nützliches über die grundlegenden Probleme von Computing und Systemen beigebracht.
      Die Art, mit Problemen umzugehen, trägt andere Kleidung, aber die Probleme selbst bleiben dieselben.
      Es gibt keine Abkürzung, und ich weiß mit Sicherheit, dass ich als Programmierer heute um Größenordnungen kompetenter bin als ich es im 5. Jahr war.
      Der Grund, warum ich mich mehr denn je darauf freue, Neues zu lernen und neue Dinge zu tun, ist, dass sie mir weitere Teile dieser Technik erschließen werden.
      Was mir Sorgen macht, ist nur, dass Körper und Geist eines Tages nicht mehr mitmachen, nicht dass mir der Lernstoff ausgeht oder ich von Jüngeren überholt werde.
    • Das dürfte aus Bob Martins Vortrag „The Future of Programming“ stammen.
      https://youtu.be/ecIWPzGEbFc?si=A4qBR2YdX-0CV2bM
    • Weil dieses Feld jung ist, entwickelt es sich schnell, und deshalb ist es natürlich, dass sich viel vorübergehendes Wissen ansammelt.
      Es fühlt sich noch an wie die Zeit der Alchemisten.
      Irgendwann werden Chemiker auftauchen, die provisorischen Beobachtungen systematisieren und vieles verwerfen.
      Bis dahin … Newton war auch Alchemist, hat aber trotzdem ziemlich große Beiträge geleistet.