Ob in Entwicklung, Test oder Betrieb, jeder technische Fachmann hegt mehr oder weniger den Traum, ein technischer Meister zu werden. Schließlich gilt: „Man muss einen Traum haben, nur für den Fall, dass er wahr wird“! Genau das Streben nach diesem technischen Traum treibt uns dazu an, kontinuierlich hart zu arbeiten und uns zu verbessern.


Allerdings: „Träume sind schön, aber die Realität ist grausam.“ Viele Studenten werden nach der tatsächlichen Arbeit feststellen, dass der Traum darin besteht, ein Meister zu werden, aber das, was sie tun, scheint völlig unabhängig davon zu sein, ein Meister zu werden. Zum Beispiel sagen Programmierer: „Jeden Tag Business-Code schreiben und Überstunden machen, wie kann ich da ein technischer Meister werden?“ Tester sagen: „Es sind jeden Tag endlose Testfälle auszuführen.“ Betriebsmitarbeiter sagen: „Maschinen tragen, Netzwerkkabel verbinden und Shell-Befehle eintippen – das ist nicht das Betriebsleben, das ich wollte.“ ...... Auf Zhihu hat eine ähnliche Frage, „Programmierer, die jeden Tag Business-Code schreiben, wie können sie technische Meister werden und anfangen, technischen Code zu schreiben?“, 6K+ Follower und 120+ Antworten. Damals habe ich auch geantwortet und die meisten Upvotes erhalten. Später, bei der Durchführung von Beurteilungen und Gesprächen zur Beförderung auf Karrierestufen, gewann ich neue Erkenntnisse und Ideen, sodass ich die Idee hatte, einen Artikel systematisch zu verfassen, in der Hoffnung, mehr Studenten zu helfen, Umwege auf dem Weg zum technischen Meister zu vermeiden.


Da ich Programmierer bin, basieren einige der folgenden Beispiele auf der Softwareentwicklung, aber die allgemeinen Prinzipien sind universell, und auch Tester und Betriebsmitarbeiter können davon lernen.


Einige typische Missverständnisse


1. Einen technischen Meister als Lehrer nehmen


Einige Leute auf Zhihu glauben, dass der einfachste, direkteste, schnellste und effektivste Weg, ein technischer Meister zu werden, darin besteht, „den technischen Meister eines Teams als Lehrer zu nehmen“ und sich von ihm zusätzliches Coaching zu holen und sich einige schwierige Aufgaben zuweisen zu lassen.


Ich persönlich bin aus mehreren Hauptgründen gegen diesen Ansatz:


  • Meister sind sehr beschäftigt und es ist unwahrscheinlich, dass sie dir Einzelcoaching geben, geschweige denn jeden Tag eine Stunde Coaching. Wenn außerdem innerhalb eines Teams ein Meister dir häufig spezielles Coaching gibt, wird das zwangsläufig Misstrauen bei anderen Teammitgliedern hervorrufen. Ich persönlich denke, dass, wenn ein Meister sich wirklich kümmert, das Beste ist, dem Team mehr Schulungen zu geben. Wer jedoch schon einmal Schulungen durchgeführt hat, weiß, dass die Vorbereitung einer Schulung sehr zeitaufwendig ist. Kursunterlagen und Materialien beanspruchen mindestens 2 Stunden (und lassen sich nicht in fragmentierter Zeit erledigen), und das Erklären dauert 1 Stunde. Wenn Meister einmal im Monat eine Schulung geben, ist das bereits sehr häufig.
  • Aus dem ersten Grund solltest du, wenn du allgemein einen Meister konsultieren möchtest, mit konkreten Fragen kommen, um Rat zu erbitten oder zu diskutieren. Da das Beantworten oder Diskutieren von Fragen nicht zu viel Zeit erfordert und mehr auf Erfahrung und angesammeltem Wissen beruht, sind Meister normalerweise gern dazu bereit – schließlich ist Einfluss ein wichtiger Indikator für einen Meister. Besondere Aufmerksamkeit ist jedoch erforderlich: Wenn du häufig nach Wissen fragst, das leicht in Büchern oder bei Google zu finden ist, werden Meister ebenfalls ungeduldig, weil Zeit kostbar ist. Oft stellen mir Netznutzer Fragen wie "Wie konfiguriert man den JVM-Parameter -Xmn?" und ich antworte direkt: "Bitte suche einfach bei Google," weil es zu viele solcher Fragen gibt. Wenn du nicht selbst systematisch lernst, verschwendet das einzelne Stellen jeder Frage sowohl deine Zeit als auch die der anderen.
  • Meister sind selten; es ist unwahrscheinlich, dass jedes Team einen technischen Meister hat. Bestenfalls gibt es im Team Personen, die geschickter sind als du. Selbst wenn er dich jeden Tag coacht, kannst du dich höchstens auf sein Niveau verbessern. Wenn der technische Meister aus einem anderen Team kommt, gibt es aufgrund von Arbeitsarrangements und Aufgabenverteilungen relativ wenige Gelegenheiten für direkte Beratung und Mentoring. Allein die Teilnahme an ein paar Schulungen des Meisters wird dich wahrscheinlich nicht zu einem technischen Meister machen.

Angesichts der oben genannten Gründe denke ich, dass du, wie die meisten Menschen, um ein technischer Meister zu werden, zuerst das Prinzip verstehen musst, "hauptsächlich auf dich selbst zu verlassen", und nicht erwarten solltest, dass ein Meister wie ein Kampfkunstlehrer dich Schritt für Schritt an die Hand nimmt. Zu geeigneten Zeiten kannst du dich verbessern, indem du Meister konsultierst oder mit ihnen diskutierst, aber die meiste Zeit solltest du dich trotzdem systematisch und gezielt selbst verbessern.


2. Business-Code kann ebenfalls großartig sein


Einige Antworten auf Zhihu argumentieren, dass das Schreiben von Business-Code auch großartig sein kann, weil Business-Code ebenfalls verschiedene Techniken umfassen kann. Zum Beispiel kann man Kapselung und Abstraktion nutzen, um Business-Code erweiterbarer zu machen, man kann mehr mit dem Produktteam kommunizieren, um das Geschäft besser zu verstehen und umzusetzen, und mit gutem Logging kann die Effizienz bei der Problemlokalisierung um das Zehnfache gesteigert werden ... und so weiter.


Es ist sicher, dass Business-Code auch technischen Gehalt hat; die Technik im Business-Code ist die Grundlage für jeden Programmierer. Aber nur diese Techniken zu beherrschen macht einen noch nicht zu einem technischen Meister. Es ist wie das Leveln durch Kämpfen gegen Monster in einem Spiel. Am Anfang bringt das Kämpfen gegen kleine Monster viele Erfahrungspunkte. Je weiter man kommt, desto weniger Erfahrungspunkte bekommt man. Das Kämpfen gegen kleine Monster kann die eigene Erfahrung nicht mehr verbessern, und zu diesem Zeitpunkt muss man gegen einige Monster höherer Stufe kämpfen und einige herausfordernde Dungeons abschließen. Ich habe noch nie ein Spiel gesehen, in dem man die höchste Stufe erreichen kann, indem man nur gegen kleine Monster kämpft. Der Weg, ein technischer Meister zu werden, ist ähnlich. Du musst dein Level kontinuierlich verbessern und dich dann größeren Herausforderungen stellen. Indem du dich diesen Herausforderungen stellst, steigst du auf die nächste Stufe auf und wiederholst dann den Zyklus, bis du schließlich das Reich eines technischen Meisters oder sogar eines Branchenmeisters erreichst. Business-Code zu schreiben ist nur eine Herausforderung auf diesem Weg des Levelns, und ich denke, es ist eine relativ elementare Herausforderung.


Deshalb glaube ich: Ein Programmierer, der Business-Code nicht gut schreiben kann, kann sicherlich kein technischer Meister werden, aber ein Programmierer, der nur Business-Code gut schreibt, ist ebenfalls noch kein technischer Meister.


3. Arbeit ist zu stressig und es bleibt keine Zeit für Selbststudium


Viele Menschen glauben, der Grund, warum sie keine technischen Meister geworden sind, sei nicht, dass sie unintelligent oder nicht fleißig seien, sondern dass in der chinesischen Umgebung technische Mitarbeiter zu viele Überstunden machen, sodass ihnen keine zusätzliche Zeit zum Lernen bleibt.


Dieser Grund ist etwas objektiv. Schließlich arbeiten wir im Vergleich zu Europa und den Vereinigten Staaten tatsächlich mehr Überstunden, aber dieser Faktor ist nur ein Problem, das überwunden werden muss, keine unüberwindbare Kluft. Schließlich gibt es um uns herum noch viele Meister, die in diesem chinesischen Umfeld aufgewachsen sind.


Ich denke, es gibt mehrere Missverständnisse, die zu dieser Ansicht führen:


1) Die Arbeit im Büro ist reine Wiederholung; um sich zu verbessern, muss man außerhalb der Arbeit zusätzlich lernen.


Der Hauptgrund für dieses Missverständnis ist immer noch die Annahme, dass „das Schreiben von Business-Code keinen technischen Inhalt hat“, und da ich bei der Arbeit Business-Code schreibe, kann ich mich bei der Arbeit nicht verbessern.


2) Lernen erfordert lange zusammenhängende Zeitblöcke


Viele Leute denken, dass man zum Lernen einen ganzen Tag Unterricht wie in der Schule braucht. Da wir viele Überstunden machen, sind wir am Wochenende so müde, dass wir einfach ausschlafen wollen oder nur Filme schauen und Spiele spielen, um uns zu entspannen, also bleibt keine Zeit zum Lernen.


Die tatsächliche Vorgehensweise ist genau das Gegenteil: Erstens sollten wir bei der Arbeit lernen und uns verbessern, denn Lernen durch Anwenden oder mit echten Beispielen erzielt die besten Ergebnisse; zweitens erfordert das Lernen nach der Arbeit keine großen Zeitblöcke, sondern vielmehr, Zeit herauszuschinden und Zeitfetzen zum Lernen zu nutzen.


Die richtige Vorgehensweise


1、Mehr tun


Mehr tun – mehr tun als die Aufgaben, die Ihr Vorgesetzter Ihnen zuweist.


Als ich bei HW war, war ich für die Entwicklung einer Version verantwortlich. Der Arbeitsumfang für diese Version betrug etwa 2.000 Zeilen, aber zusätzlich zum Abschluss der Funktion habe ich auch alle zugehörigen Funktionen gründlich verstanden und den gesamten Code gelesen (etwa 10.000 Zeilen). Nach Abschluss dieser Version war ich mit dem gesamten Geschäftsbereich dieser Version vertraut. Nach ein oder zwei Meetings stellte jeder fest, dass ich mich in diesem Bereich am besten auskannte. Dann wurde es interessant: In Produktdiskussionen wurde nach mir gefragt, Tester kamen mit Problemen zu mir, und mein Chef kam für externe Unterstützung zu mir. Später kamen sie sogar bei Funktionen, die nicht in meiner Verantwortung lagen, zu mir. Selbst wenn ich es im Moment nicht wusste, las ich den Code oder suchte Dokumente, um ihnen zu helfen, eine Antwort zu finden... Am Ende wurde ich der „Experte“ für dieses System. Obwohl ich damals noch im Geschäftsbereich arbeitete und Business-Code schrieb, war ich mit dem gesamten Geschäft vertraut.


Das Obige ist nur ein einfaches Beispiel. Tatsächlich zeigt es, dass man, um Chancen zu haben, zuerst aus der Masse herausstechen muss. Um herauszustechen, muss man anders sein. Um anders zu sein, muss man mehr tun!


Wie kann man mehr tun? Man kann mit den folgenden Aspekten beginnen:


1) Sei mit mehr Geschäftsbereichen vertraut, ob sie zu deinem gehören oder nicht; sei mit mehr Code vertraut, ob du ihn geschrieben hast oder nicht.


Das hat viele Vorteile. Hier sind ein paar einfache Beispiele:


  • Die Anforderungsanalyse wird präziser, und Risiken, Auswirkungen und Schwierigkeiten können bereits in der Anforderungsphase erkannt werden.
  • Die Problembehandlung wird schneller, weil du mit dem zugehörigen Geschäft und Code vertraut bist und mögliche Ursachen schnell bestimmen sowie Probleme eingrenzen und beheben kannst.
  • Das Lösungsdesign wird umfassender; mit einem Verständnis des Gesamtgeschäfts kannst du bessere Lösungen entwerfen.

2) Sei mit dem End-to-End-Prozess vertraut


Zum Beispiel: Wenn Sie für die Web-Backend-Entwicklung verantwortlich sind, durchläuft eine HTTP-Anfrage eines Nutzers in der Realität viele Zwischenschritte, bevor sie Ihren Server erreicht (z. B. Browser-Cache, DNS, nginx usw.). Der Server durchläuft im Allgemeinen viele Verarbeitungsschritte, bevor er den Teil des Codes erreicht, den Sie geschrieben haben (Routing, Berechtigungen usw.). An vielen Systemen oder Schritten in diesem gesamten Prozess kann die überwiegende Mehrheit der Menschen nicht am Schreiben des Codes beteiligt sein, aber die Beherrschung dieses Wissens hat einen großen Einfluss auf Ihr Gesamtniveau. Beispielsweise erfordern technische Arbeiten mit höherem Wert wie Lösungsdesign und Behandlung von Online-Fehlern ein umfassendes technisches Niveau.


Wörter wie „systematisch“, „global“ und „umfassend“ mögen vage klingen, aber sie sind tatsächlich wesentliche Eigenschaften eines technischen Meisters. Um ein solches Niveau zu erreichen, müssen Sie sich mit mehr Systemen, Geschäftsbereichen und Code vertraut machen.


3) Selbststudium


Normalerweise ist in einem relativ ausgereiften Team die Technologie, die zum Schreiben von Geschäftscode verwendet wird, tatsächlich begrenzt, da Frameworks oder Komponenten stark gekapselt wurden. Aber wir müssen verstehen, dass „die einzige Konstante der Wandel ist“. Das Framework muss möglicherweise verbessert werden, Komponenten müssen möglicherweise ersetzt werden, oder Sie wechseln zu einem Unternehmen, in dem weder Komponenten noch Frameworks existieren und Sie von Grund auf neu beginnen müssen. Das sind sowohl Chancen als auch Herausforderungen, und Chancen und Herausforderungen werden nur denjenigen gegeben, die vorbereitet sind. Daher müssen wir in diesem Fall noch mehr Selbststudium betreiben, denn wenn Sie es tatsächlich brauchen, ist es zu spät, es zu lernen.


Nehmen wir Java als Beispiel. Der meiste Business-Code ist nur if-else plus eine Datenbankoperation, aber wir können auf jeden Fall mehr Java-Wissen eigenständig lernen, wie Garbage Collection, Tuning, Netzwerkprogrammierung usw. Das mag vorerst nutzlos sein, aber wenn man es wirklich braucht, reicht es nicht, einfach Google zu fragen. Zu diesem Zeitpunkt wird derjenige, der die relevanten Kenntnisse und Fähigkeiten bereits beherrscht, die Chance bekommen.


Nehmen wir die Garbage Collection als Beispiel: Ich habe mir persönlich die Zeit genommen, dieses Wissen in meiner Freizeit zu lernen, und habe es ein Jahr lang nicht genutzt. Später habe ich es jedoch mehrmals eingesetzt, und jedes Mal hat es große Probleme mit Systemeinfrieren gelöst. Gleichzeitig wissen manche Studenten, die seit mehreren Jahren Java-Code schreiben, nicht einmal, was das Konzept Stop-the-World ist, geschweige denn, wie man es optimiert.


2、Besser werden


Wisse, dass nichts auf dieser Welt perfekt ist. Die Systeme und Geschäftsbereiche, für die du verantwortlich bist, haben immer unvernünftige Aspekte und Bereiche mit Verbesserungspotenzial. Diese "unvernünftigen" und "verbesserungsfähigen" Stellen sind alle Monster auf höherer Ebene – besiegt man sie, bekommt man mehr Erfahrungspunkte. Identifiziere diese Bereiche, entwickle Lösungen und schlage sie deinem Vorgesetzten vor. Wenn es beim ersten Mal nicht funktioniert, schlage es erneut vor. Solange ein Vorschlag umgesetzt wird, ist das deine Chance.


Zum Beispiel:


  • Es gibt zu viel doppelten Code – können wir Entwurfsmuster einführen?
  • Die Systemleistung ist durchschnittlich – kann sie optimiert werden?
  • Derzeit ist es ein Einzelmaschinen-Setup – wäre ein Dual-Maschinen-Setup besser?
  • Die Qualität der Versionsentwicklung ist nicht hoch – können wir effiziente Lösungen für Unit- und Integrationstests einführen?
  • Das aktuelle System ist zu groß – können wir es refaktorisieren und in drei Systeme entkoppeln?
  • Einige Alibaba-Middleware-Systeme wirken so, als könnten wir sie ebenfalls gebrauchen – können wir sie einführen?
  • 。。。。。。。。。。。。。。。。。。。

Solange du darüber nachdenkst, kannst du immer Bereiche zur Verbesserung finden. Wenn du das Gefühl hast, dass es in deinem System keinen Platz gibt, der verbessert werden kann, bedeutet das, dass dein Fähigkeitsniveau noch nicht ausreicht. Lerne mehr über verwandte Technologien und schau, wie andere Unternehmen in der Branche Dinge tun – wie BAT-Unternehmen Dinge tun.


Im Jahr 2013 wurde ich zu Jiuyou versetzt. Anfangs übernahm ich ein einfaches Backend-System. Jeden Tag führte ich nur Daten-CRUD-Operationen für das Frontend durch. Es schien völlig uninteressant, oder? Wenn du nur diese Dinge tust, ist es wirklich langweilig. Aber nachdem wir es übernommen hatten, haben wir viele Dinge getan:


  • Entkopplung: Ein Backend in zwei Backends aufteilen, um Skalierbarkeit und Stabilität zu verbessern;
  • Dual-Machine: Das Single-Machine-Setup in ein Dual-Machine-System ändern, um die Zuverlässigkeit zu verbessern;
  • Optimierung: Eine Schnittstelle, die ursprünglich 5 Stunden zur Fertigstellung benötigte, auf 5 Minuten optimiert;

Es gab auch viele andere Optimierungen. Später übernahm unsere Gruppe weitere Systeme. Am Ende war dieses kleine Team aus 5 Personen für 6 Systeme verantwortlich.


3、Übung machen


Während Karrierelevel-Gesprächen stellte ich fest, dass viele Leute tatsächlich versuchten, mehr zu tun und es besser zu machen, aber im Ausführungsprozess stießen fast alle auf dasselbe Problem: Nur zu lesen, ohne es anzuwenden, bringt schlechte Ergebnisse – was sollen wir tun?


Zum Beispiel:


  • Ich habe etwas über JVM-Garbage-Collection gelernt, aber in der Produktion gibt es selten Verzögerungsprobleme, die durch FGC verursacht werden. Selbst wenn sie auftreten, hat die Wiederherstellung des Geschäfts oberste Priorität. Es ist unwahrscheinlich, dass ein Produktionsproblem auftritt und alle daran üben lässt. Wie kann ich also dieses JVM-Wissen und diese Fähigkeit üben?
  • Ich habe auch über Netty gelesen und verstehe die Reactor-Prinzipien, aber ich kann nicht an der Netty-Entwicklung teilnehmen. Wie kann ich das asynchrone Reactor-Muster wirklich beherrschen?
  • Ich habe „High Performance MySQL“ gelesen, aber die Produktionsdatenbanken werden von DBAs verwaltet, und die Datenbanken der Testumgebung scheinen einfach willkürlich konfiguriert zu sein. Wie kann ich diese Techniken verifizieren?
  • Das Framework kapselt die DAL-Schicht, daher müssen wir uns keine Gedanken über den Datenbankzugriff machen. Wie lernen wir etwas über die Implementierungen von Sharding und Tabellenpartitionierung?
  • 。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

Es gibt viele solcher Fragen. Ich möchte hier meine persönliche Erfahrung teilen. Es läuft auf drei Worte hinaus: Lernen, Ausprobieren, Lehren!


1）Lernen


Dies ist die erste Phase. Bücher lesen, googeln, Videos ansehen und Blogs anderer Leute lesen – all das funktioniert, aber eines ist zu beachten: die „Systematisierung“, insbesondere bei grundlegenden Themen wie JVM-Prinzipien, Java-Programmierung, Netzwerkprogrammierung und dem HTTP-Protokoll ... und so weiter. Diese grundlegenden Technologien kann man nicht nur durch Google oder Blogs lernen. Mein Ansatz ist normalerweise, zuerst ein vollständiges Buch zu lesen, um ein umfassendes Verständnis zu erlangen, und dann Google, Videos und Blogs zu nutzen, um gezielt nach bestimmten Unklarheiten oder einigen Tipps und Kniffen zu suchen.


2）Ausprobieren


Dieser Schritt ist der Schlüssel, um die zuvor von vielen Leuten erwähnten Zweifel zu beantworten. Bildlich gesprochen heißt es „mach es selbst, dann hast du reichlich“ – das heißt, richte deine eigenen simulierten Umgebungen ein und schreibe deine eigenen Testprogramme. Zum Beispiel:


  • JVM-Garbage-Collection: Du kannst ein einfaches Testprogramm schreiben, das Speicher belegt, ohne ihn freizugeben, dann verschiedene JVM-Startparameter anpassen und während der Ausführung Befehle wie jstack und jstat verwenden, um die JVM-Heap-Speicherverteilung und den Status der Garbage Collection zu untersuchen. So ein Programm ist sehr einfach zu schreiben – ein einfaches umfasst nur wenige Zeilen, und ein komplexeres nur ein paar Dutzend Zeilen.
  • Reactor-Prinzipien: Versuche tatsächlich, selbst eine Demo des Reactor-Musters zu schreiben. Denke nicht, dass das zu schwierig ist – die einfachste Implementierung des Reactor-Musters, einschließlich Kommentaren, umfasst nicht mehr als 200 Zeilen. Du kannst Doug Leas PPT heranziehen. Nachdem du es selbst geschrieben hast, schau dir an, wie Netty es implementiert. Durch den Vergleich der beiden wird dein Verständnis viel tiefer.
  • MySQL: Da es eine Produktionskonfiguration als Referenz gibt, kannst du den DBA direkt bitten, uns die Produktionskonfiguration zu schicken (denke daran, sensible Informationen zu entfernen), und direkt daraus lernen. Richte dann deine eigene MySQL-Umgebung ein und starte sie mit der Produktionskonfiguration. Du solltest wissen, dass viele Leute MySQL seit Jahren benutzen, aber nicht einmal eine einfache MySQL-Umgebung einrichten können.
  • Das Framework kapselt die DAL-Schicht: Du kannst versuchen, mit JDBC eine einfache Implementierung für Datenbank-/Tabellen-Sharding zu schreiben, und sie dann mit der Implementierung des Frameworks vergleichen, um zu sehen, wo die Unterschiede liegen.
  • Verwende Browser-Tools, um HTTP-Cache-Implementierungen zu untersuchen und zu sehen, wie verschiedene Arten von Websites und verschiedene Arten von Ressourcen das Caching steuern. Du kannst auch einen einfachen HTTP-Server in Python schreiben, der verschiedene HTTP-Header zurückgibt, um das Verhalten des Browsers zu beobachten.
  • 。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

Es gibt noch viele weitere Methoden, und ich werde sie hier nicht alle einzeln auflisten. Kurz gesagt, du musst das Gelernte wirklich ausprobieren, um es tiefer zu verstehen. Es gibt ein Sprichwort der amerikanischen Ureinwohner: "Ich höre und ich vergesse. Ich sehe und ich erinnere mich. Ich tue und ich verstehe." Außerdem kann "Ausprobieren" tatsächlich recht einfach sein – in vielen Fällen können wir es selbst tun.


Natürlich ist der Effekt noch besser, wenn du es in der tatsächlichen Arbeit einsetzen kannst. Schließlich lassen sich die echte Produktionsumgebung und die geschäftliche Komplexität nicht durch ein Simulationsprogramm nachbilden. Aber solche Gelegenheiten sind selten, und in den meisten Fällen können wir uns wirklich nur auf selbst gebaute Simulationen verlassen. Wenn das tatsächliche Geschäft es dann braucht, können wir es mühelos einsetzen.


3）Unterricht


Allgemein gesagt: Nach Lernen und Ausprobieren kann man etwa 70% beherrschen. Aber um etwas wirklich zu beherrschen, muss man es meiner Meinung nach anderen klar erklären können. Beim Erklären müssen wir einen Wissenspunkt nicht nur systematisieren, sondern auch verschiedene Details berücksichtigen, was uns dazu bringt, weiterzudenken und weiterzulernen. Gleichzeitig können die Zuhörenden nach dem Erklären unterschiedliche Interpretationen oder neue Ergänzungen haben, was das gesamte Wissens- und Fähigkeitssystem wirksam weiter verbessert.


Es gibt viele solcher Beispiele, auch beim Schreiben meines Blogs – das begegnet mir oft. Anfangs denke ich, ich hätte etwas umfassend beherrscht, aber sobald ich anfange zu schreiben, entdecke ich viele Punkte, die ich nicht bedacht hatte. Ich sehe es auch oft in internen Team-Schulungen: Manche Leute schreiben eine PPT, aber beim Präsentieren, sobald alle Fragen stellen oder diskutieren, stellen sie fest, dass viele Punkte nicht klar erklärt wurden oder einige Punkte missverstanden werden. Wenn man den gesamten Prozess vom Schreiben einer PPT über das Präsentieren bis zur Diskussion durchläuft, erhält man im Grunde ein ziemlich umfassendes Verständnis eines Wissenspunkts.


Nachwort


Der Traum, ein technischer Experte zu werden, ist schön, aber er erfordert viel Anstrengung. Ob es nun „Mehr tun“, „Besser machen“ oder „Üben“ ist – alles erfordert Zeit und Energie. Dieser Prozess kann schmerzhaft oder langweilig sein. Hier möchte ich betonen: Was ich oben geteilt habe, sind Methoden, aber was wirklich die entscheidende Rolle spielt, ist tatsächlich unsere Leidenschaft und unser Interesse an Technologie!