Ich selbst bin Programmierer und konzentriere mich auf das Web, verteiltes Rechnen und Datenverarbeitung.
Ich betrachte das Web als die populärste, von Natur aus plattformübergreifende Präsentations- und Visualisierungstechnologie; verteiltes Rechnen als die am besten geeignete Architektur für Programmzusammenarbeit und kooperative Programme; und Datenverarbeitung als etwas, das Grundlagen, Fähigkeiten, Kognition, Weitblick und Domänenwissen auf einmal erfordert. Also wird die Beschäftigung mit Datenverarbeitung Ihre Grundlagen, Fähigkeiten, Kognition, Ihren Weitblick und Ihr Domänenwissen verbessern.
Das sind alles leere Worte, und dazu noch ziemlich verworren. Aber leere Worte zu verstehen, ist für mich gar nicht so einfach.Ich glaube, dass die Verbesserung von Fähigkeiten aus der Ansammlung kommt, daher sollte man dauerhafte Begeisterung für grundlegende Dinge bewahren.
Ich denke, die Grundlagen sollten unter anderem umfassen, abersind keineswegs darauf beschränkt：
Datenstrukturen und Algorithmen、
algorithms、
Netzwerke (TCP/IP, P2P, HTTP usw.)、
Computerarchitektur und Betriebssysteme (Speicherverwaltung, Hochgeschwindigkeitspuffer und Caches, Threads und Nebenläufigkeit, Ressourcen und Konkurrenz, CPU-Zyklen, Lokalitätsprinzipien usw.)。
Ich glaube, die oben genannten Grundlagen können niemals „gemeistert“ werden, zumindest nicht auf meinem Intelligenzniveau. Wenn du zum Beispiel Yan Weimins Data Structures gelesen hast, ist das gut; wenn du zusätzlich Introduction to Algorithms gelesen hast, ist das besser; wenn du Princetons Algorithms lesen kannst, bist du ziemlich gut; und wenn du außerdem einige Paper gelesen und tatsächlich Code mit vim, emacs, VS, Eclipse oder Sublime getippt hast, dann solltest du auf einen Blick die Schwächen und die Niveaus in den Algorithmusartikeln in Blogs auf der ganzen Welt erkennen können – dann hast du wirklich echtes Können.Wissensstruktur und Projekterfahrung beeinflussen sich in ihrer Bedeutung gegenseitig. Beim selben Projekt und ähnlichen Rollen werden sich aufgrund unterschiedlicher Wissensstrukturen auch die Verbesserung und die Erkenntnisse unterscheiden, und der Nutzen, den diese Verbesserung für das nächste Projekt oder komplexere Projekte bringt, wird sich ebenfalls unterscheiden. Über einen längeren Zeitraum wird dieser Unterschied so enorm wie der zwischen 100K und 1M.
Zehn Jahre Berufserfahrung zu haben oder zehn Jahre lang ein und dieselbe Sache zu wiederholen – der Unterschied könnte genau hier liegen.Ich denke, Aussagen wie „Java meistern“ gibt es durchaus, aber die JVM nicht zu diskutieren, ist schon unredlich. Vertrautheit mit Klassenbibliotheken und Frameworks entsteht durch Engineering und Projekte. Man kann mit einer einfachen API vertraut sein oder sich ein Verständnis von AOP erarbeiten; die Anwendung kann sehr einfach oder sehr komplex sein. Wenn dir Performance-Szenarien wichtig sind, solltest du die JVM bewusst beachten. Aber die JVM ist ein enormer Engineering-Aufwand, daher ist ihr Verständnis ein langfristiger Prozess, was Beherrschung zu einer ziemlich schwierigen Sache macht. In vielen gängigen Szenarien – zum Beispiel können BufferedReader, FileChannel und mmap alle Optionen für I/O sein – hängt die Frage, welche besser geeignet ist, oft davon ab, was die virtuelle Maschine und das Betriebssystem im Hintergrund tun. Erst dann kann mandie Best Practices herausarbeiten.Nebenbei erlangt man auch ein tieferes Verständnis für einfache Konfigurationen wie Xss, Xmx und directMemory. Gleichzeitig hilft es einem, die Grenzen von Sprachen auf Basis virtueller Maschinen zu erkennen. Beispielsweise ist der BlockBuffer von HBase selbst ein Design, das die Leseeffizienz verbessern soll, aber wegen der Heap- und GC-Mechanismen der JVM kann dieses Design HBase ausbremsen.
Dieser Punkt sollte auch für C# & CLR gelten.Menschen, die viele Jahre gearbeitet haben, glauben alle – oder sind stolz darauf –, in irgendeinem Bereich ein Niveau von Meisterschaft erreicht zu haben. Manche haben es tatsächlich erreicht, aber oft geht es mit einer gewissen Affektiertheit, Heuchelei und einer starken Vorliebe dafür einher, Cleverness zur Schau zu stellen; sie werden keine ehrliche Diskussion mit dir führen. Solche Menschen kann es unter Freunden, Mitschülern, Kollegen und Vorgesetzten geben. Ein Programmierer lebt nicht in einem isolierten Container. Neben dem Bewahren von Selbstvertrauen und Bescheidenheit in Bezug auf Fähigkeiten und mehr Einsatz musst du auch an deinen eigenen Prinzipien festhalten und darfst dich nicht von Unternehmenskultur oder der Kultur bestimmter Kreise beeinflussen lassen, die nicht positiv genug sind. Nur wenn du du selbst bist, kannst du Technologie besser behandeln und deinem Arbeitgeber eine bessere Atmosphäre und echten Wert bringen.
Die Welt hat keinen Mangel an Trollen; manche Trolle sind selbst durchaus fähig, sogar weit fähiger als du. Das ist einfach ihre Art zu leben. Emotionale Kontrolle ist keine Technik; je gründlicher du sie verstehst, desto klarer kannst du erkennen, was ein Troll ist und was die Frustration ist, wenn man will, dass Eisen zu Stahl wird (Enttäuschung über mangelnden Fortschritt bei jemandem).Was technischen Pragmatismus betrifft, gibt es immer die Ansicht, dass man, wenn man nicht in den Vereinigten Staaten war, die Stars and Stripes nicht kennen sollte. Zum Beispiel wird nicht jedes Unternehmen und nicht jeder Programmierer mitBig Data in Berührung kommen, doch schon in der Antike, bevor Menschen fliegen konnten, hatten sie bereits begonnen, Zivilisation durch Totems und Wandmalereien zu erkunden und zu deuten. So etwas ist eigentlich die Kraft des Glaubens; grob gesagt, ist es das, woran dein Interesse liegt; noch grober gesagt, begünstigt die Gelegenheit immer den vorbereiteten Geist. Ob du bereit bist, dich vorzubereiten, hängt von Haltung und Verständnis ab; ob die Vorbereitung in Zukunft genutzt werden kann, hängt von der Gelegenheit ab. Stärke und Glück sind beide wichtig, aber Glück ist etwas, das du nicht kontrollieren kannst.
Einige Lehrer an bestimmten Schulen unterrichteten bereits, als Weibo noch in seiner Wachstumsphase war:Social Computing. Wenn du diesen Wissenskanal nicht hast, würdest du wahrscheinlich die Bedeutungen von ETL, Data Mining und invertierten Indizes nicht erkennen; vielleicht bist du bereits versiert im Modifizieren, Hinzufügen und Kompilierenlucene.
Doch so gut das Wissen auch sein mag – ohne Praxis wird es nicht auf ein höheres Niveau gehoben. Ich denke, ein guter Programmierer sollte sich auf Code und Implementierung konzentrieren, aber das einfache Kopierprinzip aufgeben, auch wenn Kopieren in den meisten Fällen ausreicht, um die Arbeit zu erledigen. Im Privaten ist es wirklich albern und ziemlich dumm, ein zentrales Stück Code ein Dutzend Mal zu schreiben. Aber wenn in jeder Schreibweise Gedanke und Verständnis steckt und man es selektiv tut, dann, wenn man sich Design Patterns und Refactoring ansieht – ach, so ist das also wirklich. Den Narren auf Fenchel-Bohnen-Art zu spielen (wie Kong Yiji, der sich mit belanglosen Details aufhält), ist nicht so unerträglich; zumindest versteht man, was falsch ist und was einen Unterschied macht, und es schafft auch Szenarien für Verbesserung außerhalb der Arbeit.Viele Leute vertreten diese Ansicht: Chinesen seien schlecht in Technologie und könnten sowieso kein Hadoop schreiben; Geld zu verdienen sei am wichtigsten – aber sie halten sich selbst trotzdem für ziemlich fähig.
Tatsächlich ist es schon für sich genommen zu begrenzt, „Hadoop schreiben“ und „Geld verdienen“ als Maßstab zu nehmen. In diesem Leben ist Geld natürlich wichtig, aber ob man ein nutzbares Hadoop, ein Mini-Betriebssystem oder eine Mini-Virtualmaschine schreibt – nichts davon muss zu ernst genommen werden. Die Tiefe des Verständnisses, die durch das Lesen von Quellcode entsteht, unterscheidet sich von der durch eigene Implementierung so sehr wie Himmel und Erde. Bei diesem Ansatz des „törichten alten Mannes, der Berge versetzt“ geht es eher darum, einen zu zwingen, mehr, genauer und tiefer zu verstehen. Die meisten Hadoop-Experten haben tatsächlich nur den Quellcode gelesen und sind bereits in der Lage, Bücher zu veröffentlichen. In der Realität führen viele Unternehmen einfach einige sehr einfache, ausgereifte Mining-Algorithmen aus; die Ingenieure von iQiyi betreiben gerade so viel lineare Regression, wie es praktikabel ist; die meisten Unternehmen verarbeiten noch Logs. Manchmal ist der Umstieg auf SSDs wichtiger, als sich einen brillanten Algorithmus auszudenken. Wenn man also diese Umgebung oder diese Bedingungen nicht hat, hört man dann einfach auf zu forschen? Ich denke nicht.
Was das Geldverdienen angeht, denke ich, dass Geld von selbst kommt, solange dein Interesse darin liegt und du die Dinge gut machen kannst. Wenn dein Einkommen nicht steigt, liegt das oft daran, dass das, was du tust, nicht in die High-Income-Kategorie fällt; mit dem Schreiben von Programmen wird man selten reich. Um ehrlich zu sein, könnten die Ausgaben einer Escortdame an einem Tag ein Vielfaches deines Gehalts betragen, ganz zu schweigen vom Einkommen der Escortdame. Wenn du im Nachtclub eine wilde Zeit haben willst und nicht zwei Flaschen Louis XIII bestellst, könnten die Hostessen dich sogar einen Möchtegern-Reichen nennen. Wenn du nicht die roten, blauen oder grünen Blumensträuße schickst, die dir gefallen, wäre es dir zu peinlich, mit ihr zurück in die Wohnanlage oder das Hotel zu gehen, um über genetische Algorithmen zu diskutieren.
Also diejenigen, die mit Escortdamen übergenetische Algorithmendiskutieren – Chef Wang und Ingenieur Li –, ihre Einkommen sind noch weniger mit dem eines Programmierers vergleichbar.
Also sei nicht zu absichtlich dabei, das Schreiben von Programmen mit Geldverdienen zu verknüpfen;es schränktdeine Fähigkeit ein, Geld zu verdienen.
Quelle:http://www.cnblogs.com/foreach-break/p/be_a_real_programmer.html