Ist der Rat eines erfahrenen Programmierers, immer Bücher zu verwenden, eine gute Idee? [geschlossen]

Ich bin ein Junior-Entwickler und bin erst seit 5 Jahren in der Branche. In meiner jetzigen Firma gibt es einen Senior, nennen wir ihn Infestus. Gelegentlich bekomme ich die Gelegenheit, etwas völlig Neues zu machen.

Eines der jüngsten Beispiele war, dass ich in der Multithread-Anwendung einen Singleton erstellen musste. Ich habe mich für diese Methode entschieden. Sobald Infestus es sah, sprach er mich schnell dumm an und forderte mich auf, diesen Ansatz zu verwenden . Auf die Frage, warum er es einfach abgewischt hat, weil es besser ist, und so sagt dieses und dieses Buch über Java, dass es besser ist.

Und es ist ein weit verbreitetes Muster: Wenn ich die Gelegenheit bekomme, etwas Neues zu machen, werde ich schnell von Infestus niedergeschossen und der einzige Grund, warum seine Methode besser ist, ist, dass diese Bücher von berühmten Programmierern geschrieben wurden. Er versucht immer, mir Bücher zum Lesen zu geben, damit ich "lernen" kann, wie man programmiert.

Ich programmiere erst seit 5 Jahren für Geld, aber ist es immer eine gute Idee, dem Buch einfach blindlings zu folgen, wie man ein Problem am besten löst, oder sollte ich ab und zu versuchen, zu experimentieren? Die ständige Flut von Beschwerden des Infestus veranlasst mich, nie etwas Neues auszuprobieren und Beispielen in Büchern zu folgen.

EDIT : Ich bin total verloren. Ja, ich weiß, dass es eine schlechte Idee ist, etwas blind zu verfolgen. Aber dieser gottähnliche Programmierer Infestus, der anscheinend viel weiß, sagt mir, dass die einzige Möglichkeit, richtig zu programmieren, darin besteht, Bücher zu lesen und alles bis auf ein T genau zu befolgen. Alle Regeln, die er auferlegt, sind die, die in Büchern geschrieben sind, also wundere ich mich nur wenn Bücher der einzig richtige Weg sind.

EDIT2 : Infestus ist nicht mein Chef. Er ist nur einer der leitenden Entwickler, die für die Überprüfung des Codes verantwortlich sind. Und die meisten seiner Kommentare nach Rezensionen bestehen aus Buchnamen, bei denen diese oder jene Methode falsch ist.

Sie werden während Ihrer gesamten Karriere auf solche Programmierer stoßen. Es ist nichts falsch daran, selbst zu experimentieren und zu lernen. Sicher, Bücher sind großartig. Häufig funktionieren die Beispiele in einer sauberen Umgebung, aber wenn Sie Entwickler für ein anderes Unternehmen sind, gibt es keine saubere Umgebung (ohne Beeinträchtigung durch andere).

Es ist immer schön zu wissen, wie man Dinge "richtig" macht, aber die Meinungen ändern sich von Jahr zu Jahr. Also lerne was du kannst. Nehmen Sie dem Senior-Entwickler, was Sie können, und kombinieren Sie es mit Ihrem Wissen, das Sie selbst erlernen. Schließlich werden Sie ein leitender Entwickler sein und diese Erfahrungen nutzen und Junior-Entwickler unterrichten.

Sei einfach kein Idiot.

Hat er dich wirklich als dumm bezeichnet oder den Code nur herabgesetzt? Etwas Dummes zu nennen ist taktlos, aber das macht den Vorschlag nicht ungültig. Ich denke, Infestus hat einen wertvollen Vorschlag gemacht, und in Zukunft sollten Sie seine Vorschläge ernsthaft prüfen. Er scheint viel zu lesen, und zumindest in diesem Fall ist seine Meinung gut informiert. Die Synchronisation ist teuer und schwierig. Seine empfohlene Implementierung ist effizienter und einfacher als Ihre und funktioniert garantiert.

Er versucht immer, mir Bücher zum Lesen zu geben, damit ich "lernen" kann, wie man programmiert.

Das ist nett von ihm. Er versucht aktiv, dir zu helfen, aber du scheinst dein Ego in die Quere kommen zu lassen. Nehmen Sie die Kritik an Ihrem Code nicht persönlich. Code ist billig zu produzieren und leicht zu ändern. Wenn Ihnen jemand einen einfacheren Weg zeigt, etwas zu tun, danken Sie ihm.

Und ja, das Lesen macht Sie zu einem viel besseren Programmierer. Alle mir bekannten Experten haben ausführlich gelesen. Wenn Sie nicht viel lesen, sind Sie bestenfalls mittelmäßig, und in weiteren fünf Jahren werden Sie möglicherweise feststellen, dass Sie nicht mehr marktfähig sind.

Ein Buch zu lesen sollte nicht blind sein: Der Autor sollte versuchen, Sie von den Vorzügen seiner Herangehensweise zu überzeugen, wenn er es vorstellt. Es ist sinnvoll, dass Ihr Vorgesetzter Sie auf ein Buch verweist, in dem er seinen bevorzugten Ansatz erläutert, anstatt ihn zu bitten, ihn selbst zu erklären: Obwohl er in der Lage sein sollte, die Vorteile seiner Vorlieben zu erläutern, ohne sich auf das Buch zu verlassen, ist dies auch eine Verdoppelung des Aufwandes das hat der buchautor schon gemacht.

Lesen Sie also das Buch, lesen Sie, was der Autor des Buches sagt, und wenn es Sie verwirrt oder Sie Ihr Verständnis bestätigen möchten oder Sie nicht einverstanden sind, sprechen Sie mit Ihrem Vorgesetzten darüber, aber jetzt sind Sie es in der Lage, eine produktivere Diskussion zu haben.

Es gibt drei Schlüsselelemente für eine gesunde Beziehung. Kommunikation, Ehrlichkeit und Vertrauen. Das gilt für alle Beziehungen, auch für Arbeitsbeziehungen. Sie sollten mit Ihrem Vorgesetzten über diese Bedenken sprechen.

Wenn Sie seine Gründe für die Befürwortung eines bestimmten Designs nicht verstehen, sagen Sie ihm das . Sagen Sie ihm, dass Sie das Buch nicht gelesen haben und dass Sie verstehen möchten, warum seine Vorgehensweise besser ist. Der Schlüssel ist , dass Sie sollten seine Art , die Dinge zu verstehen versuchen.

Ich denke, Sie sollten diese Person auch mit mehr Respekt behandeln. In deinem Kopf nennst du ihn abfällige Namen und kritisierst seine Herangehensweise an das, was du als "Lernen" ansiehst. Achten Sie darauf. Andererseits hast du gesagt, dass er dich dumm nennt . Das ist nicht cool und du solltest ihm sagen, dass es nicht cool ist, jemanden dumm zu nennen.

Ideen können dumm sein. Wir alle machen Fehler und vermissen Dinge, auch die älteren Leute. Wenn ein Entwurf einen Fehler aufweist, ist die beste Frage: "Warum machst du das so? Bricht es nicht in der Situation X, Y, Z zusammen? Wird Entwurf B nicht besser sein?"

Denken Sie daran, dass Sie mit anderen Personen an dieser Software arbeiten. Das ist schwer zu lernen. Es spielt keine Rolle, dass Sie nichts von Grund auf neu schreiben. Es gibt immer Raum, um zu glänzen, indem Sie Ihren Code so gut wie möglich machen.

Und "am besten" bedeutet sehr oft lesbar und verständlich . Wir Programmierer verbringen viel Zeit damit, den Code anderer Leute zu lesen. Wenn dieser Code klar und lesbar ist, ist er wirklich wertvoll. Eine der Möglichkeiten, wie wir lernen, großartigen Code zu schreiben, ist das Lesen vieler guter Codes. Sie finden sehr oft sehr guten Code in Büchern. Wenn Sie also ein oder zwei gute Programmierbücher lesen, sind Sie wahrscheinlich ein besserer Programmierer.

In der Firma, in der Sie arbeiten, ist es wahrscheinlich. Das ist es, was sie von dir verlangen.

Dieser Ingenieur Infestus leistet einen sehr schlechten Job bei der Ausbildung von Nachwuchsentwicklern, indem er ihnen mitteilt, "das steht im Buch, und deshalb". Er ist kein Prediger, er ist Ingenieur, und er sollte in der Lage sein, es aufzuschlüsseln und die Konzepte vorzustellen, damit die Junioren aus seinen Erfahrungen lernen können.

Ich würde Sie ermutigen, mit erfahrenen Entwicklern in Ihrem Unternehmen zu sprechen, ihnen Fragen zu den Vor- und Nachteilen verschiedener Programmiertechniken usw. zu stellen. Dazu gehört auch das Lesen von Büchern und Blogs (ich würde Joel für Software empfehlen - nur Google, das ist ein Muss). sollte Ihnen ein besseres Verständnis geben.

Meiner Meinung nach gibt es hier zwei Aspekte, die Sie separat behandeln sollten:

• Die Tatsache, dass der Typ ein Idiot ist, der Ihnen Namen nennt und so einfach, weil er es kann (er ist älter, Sie sind es nicht, wenn einer von Ihnen sich über den anderen beschwert, wird er den Vorteil des Zweifels erhalten), ist einfach Mobbing-ähnliches Verhalten und einfach nur schlecht.

Versuchen Sie, sich damit nicht auf sein Niveau zu beugen. Versuchen Sie nicht, ihn zurückzudrängen oder dem Chef oder irgendetwas davon zu erzählen. Geben Sie Ihr Bestes, um diesen Aspekt seines Verhaltens zu ignorieren, und denken Sie daran, dass es zu extrem wird (dh, wenn es Ihre Produktivität und dergleichen beeinträchtigt), sollten Sie etwas dagegen tun.

• Die Tatsache, dass er Ihnen sagt, dass Ihr Code schlecht ist (und wie man es richtig macht). Ehrlich gesagt, ist dieser Aspekt seines Verhaltens nicht so schlimm, wenn man den Ton des Mannes ignoriert. Sie lernen die Dinge viel schneller und können sie im richtigen Kontext sehen, wenn Sie erfahrener sind, Sie zu korrigieren und Ihnen nicht nur zu sagen, was Sie falsch gemacht haben, sondern auch, wie Sie es richtig machen (im Vergleich dazu, dass Sie alles alleine lernen) aus persönlichen Versuch / Irrtum-Experimenten und dergleichen).

Manchmal hatte ich jemanden, der das korrigierte, was ich anfangs für "meinen perfekten Code" hielt, und war nur verärgert darüber, dass der Typ mir sagte, was ich tun sollte, um später festzustellen, dass er die ganze Zeit Recht hatte. Meine Version war schlecht, seine war es gut, und Gott sei Dank hat er das gesehen! :) Also habe ich gelernt, meine anfänglichen Impulse von "Hey, sag mir nicht, was ich tun soll, Mista!" und stattdessen überprüfe ich jedes Mal, wenn mich jemand korrigiert, zuerst wirklich objektiv meinen Code, dann seinen und stelle sicher, dass er nicht wirklich Recht hat und ich es bin, der den Fehler macht. Wenn es meine Schuld war, danke ich ihm von der Hilfe und stelle sicher, dass ich wirklich verstehe, wie seine Lösung funktioniert (anstatt sie nur zu kopieren / einzufügen).

Und hey, manchmal stelle ich fest, dass die angebotene Korrektur tatsächlich schlimmer war als das, was ich anfangs getan habe. Zu diesem Zeitpunkt versuche ich, das alles mit dem anderen zu besprechen. Ehrlich gesagt habe ich bemerkt, dass nichts den Respekt der anderen für Sie schneller gewinnt als wenn sie sehen, dass Sie es akzeptieren können, korrigiert zu werden, wenn Sie einen Fehler gemacht haben, aber gleichzeitig keine Angst haben zu sagen, dass Sie der Richtige sind Wer hat Recht, wenn Sie denken, dass es so ist, vorausgesetzt, Sie können sofort beweisen, dass Sie Ihre Behauptung auf tatsächlichen Nachforschungen gründen und nicht nur auf dem Ego.

In diesem Punkt sollten Sie wirklich versuchen, mit dem Mann darüber zu sprechen, was er vorschlägt und was Sie vorschlagen und so weiter. Zeigen Sie ihm, was Sie denken, wie Sie zu einer bestimmten Lösung gekommen sind und warum Sie denken, dass sie besser ist als seine (wenn Sie ehrlich und objektiv denken, dass es die ist). Oder wenn Sie herausfinden, dass sein Vorschlag besser ist als Ihr Vorschlag, sagen Sie es ihm, und drücken Sie Ihre Wertschätzung für die Hilfe aus. Dies kann zum Wiederaufbau einiger verbrannter Brücken führen.

Experimentieren Sie selbst und lernen Sie alles, was Sie können. Wenn Sie genug Bücher gelesen haben, werden Sie feststellen, dass es mehrere Bücher zu bestimmten Themen gibt, die sich möglicherweise widersprechen. Probieren Sie die aus, die Sie für die beste halten, und probieren Sie beide aus, wenn Sie Zeit haben oder vergleichen / kontrastieren möchten.

Der Umgang mit Ihrem Chef ist ein völlig anderes Thema und eine andere Herangehensweise. Wenn ich wollte, dass jemand etwas genau so macht, wie es in einem Buch steht, würde ich es ihm sagen. Das bin nur ich, weil ich nicht mit Gedankenlesern in Verbindung stehe. Ihr Chef macht es sich zur Gewohnheit, fragen Sie einfach, ob er Bücher oder Referenzen empfiehlt, wenn Sie ein neues Projekt erhalten.

Was auch immer Sie tun, hören Sie nicht auf, an neuen Projekten zu arbeiten. Ich weiß, dass es für uns alle leicht ist, Tipps zum Umgang mit dieser Situation zu geben, und sie können oder können nicht funktionieren, aber Sie sind derjenige, der damit leben und unter der Negativität leiden muss. Du wirst besser werden, aber das kommt normalerweise davon, dass du mehr Code für neue Dinge schreibst und aus den Erfolgen und Misserfolgen lernst.

Es ist eine schlechte Idee, Büchern blind zu folgen, aber es gibt einen Unterschied, ob man einem Buch genau folgt oder es blind befolgt .

Wenn Sie versuchen , Sachen in einem Buch zu verstehen, ist es im Allgemeinen ist angebracht , sie genau auf dem ersten zu folgen, während Sie ein Gefühl dafür bekommen , was es versucht , Sie zu lehren. Es besteht die Möglichkeit, dass Sie immer noch nicht alles verstehen, wenn Sie fertig sind - so laufen solche Dinge normalerweise ab -, aber wenn Sie das Buch genau befolgen, können Sie zunächst mit etwas experimentieren, während Sie versuchen, Ihre Fragen zu verstehen. Die Chancen stehen wieder gut, dass Sie Wege finden, mit denen Sie nicht einverstanden sind, was in dem Buch steht, aber Sie werden ein Verständnis für die Probleme haben, die in dem Buch angesprochen wurden, damit Sie, wenn es an der Zeit ist, Ihren eigenen Code zu schreiben, dies tun können Gehen Sie sie auf Ihre eigene Weise an (oder zumindest teilweise auf ihre Weise), anstatt diese Probleme Ihnen später zu überlassen.

Eine andere Sache, die nicht spezifisch für Java ist, aber dennoch in dieser Community besonders häufig vorkommt. Ich glaube, ich kann mir vorstellen, über welche Bücher Sie sprechen, und sie sind ein wichtiger Bestandteil des Lexikons der Java-Community. Das Verständnis und die Art und Weise, wie sie die Dinge beschreiben, hilft immens, wenn Sie anderen Java-Code verstehen müssen, den Sie finden. Das ist eine wertvolle Fähigkeit für sich.

Das Lesen von Büchern und Blogeinträgen ist beim Programmieren sehr hilfreich. Es gibt einige Bücher, die alle Entwickler lesen sollten.

Bücher sind jedoch nicht die einzige Quelle, um verschiedene Programmierkonzepte und -technologien kennenzulernen. Heutzutage wird On-Demand-Training auf Videobasis immer beliebter. Sie können Pluralsight überprüfen , das Fachleuten qualitativ hochwertige Schulungen bietet.

In der Tat, wenn Sie nur Bücher lesen, wird das auch nicht helfen. Neben dem Lesen gibt es noch andere Dinge, die wir ebenfalls tun müssen. Weitere Details finden Sie hier .

Sie sollten ihn fragen, was genau an Ihrer Methode falsch ist. Wenn er es nicht klar beantworten kann, können Sie sich ziemlich sicher sein, dass es nur ein gewöhnlicher Typ ist, der sich gerne überlegen fühlt.

Die Sache mit Büchern ist, dass sie - meistens - Revisionen durchlaufen, die eine bessere Chance haben, schlechte Praktiken und Missverständnisse zu entdecken. Außerdem sind die "großen Namen" erfahrene Leute, die darauf vertrauen, dass sie gut sind, um zusätzliches Geld für den Verkauf von Büchern zu verdienen. Daher gibt es einige minimale Qualitätssicherungen für das, was sie sagen.

Das Lesen von Büchern, Zeitungen und anderen Quellen ist natürlich eine gute Möglichkeit, sich als Profi weiterzuentwickeln, wenn dies durch die Praxis bestätigt wird. Es ist also gut für Sie, diese Bücher zu lesen (auch die von Infestus empfohlenen). Die Bücher müssen jedoch hauptsächlich Ihr Verständnis zu diesem Thema erweitern, da es fast immer andere Möglichkeiten gibt, das gleiche Problem zu lösen.

In Bezug auf Ihren "Go by myself" -Ansatz lautet der Punkt: Können Sie Ihre Sichtweise aufrechterhalten? Wie beweisen Sie, dass Ihre Lösung besser ist als jede andere? Manchmal können Sie sich selbst leuchtende Lösungen ausdenken, aber im Vergleich zu anderen bekannten Lösungen müssen Sie in der Lage sein, den Grund für die Besserung Ihrer zu argumentieren, da die anderen zumindest die Anwendungsfälle zu ihren Gunsten haben. Seien Sie dann kreativ und nachdenklich, aber vor allem effektiv.

Wenn ich wäre, würdest du diese Bücher lesen. Das wird Ihnen helfen, indem Sie mehr Argumente vorbringen, und gleichzeitig werden Sie feststellen, dass Infestus - vielleicht - diese Bücher fälschlicherweise als Argumente auffasst, und er wurde noch nicht entdeckt, weil niemand den Inhalt dieser Bücher kennt. Oder Sie können feststellen, dass er tatsächlich k

Ich habe die Erfahrung gemacht, dass die Qualität und Präsentation von Informationen mit angemessenen Erklärungen in Büchern bei der Programmierung von Themen wesentlich besser ist als bei der Suche nach denselben Themeninformationen im Internet. Internet fehlt oft die richtige Erklärung, Kontext und Qualität.

Die Menge dieser Informationen im Internet ist höher.

Meine allgemeine Strategie ist es also, aus Büchern zu lernen, um ein tieferes Verständnis zu erlangen, und danach aus dem Internet zu lernen, um verschiedenen Implementierungen ausgesetzt zu werden und meine Erfahrung zu erweitern (und oft zu sehen, wie man Dinge nicht macht).

Ich würde die Vorzüge jedes Ansatzes untersuchen und zu Ihrem eigenen Urteil kommen. Wenn Sie der Meinung sind, dass Ihr Ansatz besser ist, besprechen Sie ihn mit Infestus, bis einer von Ihnen den anderen überzeugt. Wenn Sie keine Einigung erzielen können, können Sie entweder eine zweite Meinung einholen oder einfach den Ansatz von Infestus akzeptieren, je nachdem, wie sehr Sie sich damit einverstanden fühlen.

Im Fall von Singletons könnten Sie gegen den Enum-Ansatz argumentieren, dass Enums Klassen nicht erweitern können. Ich schreibe oft Code wie folgt:

public class DateSerializer extends AbstractSerializer<Date> {
  public static final DateSerializer SINGLETON = new DateSerializer();

  private DateSerializer() {}

  public byte[] serialize(Date date) { ... }
}

Dies kann nicht mit Aufzählungen durchgeführt werden. Da der Enum-Ansatz nicht in allen Fällen funktioniert, sollte er aus Gründen der Konsistenz vermieden werden, auch wenn keine extendsKlausel erforderlich ist.

Einige andere Argumente, die gegen die Verwendung von Aufzählungen vorgebracht werden könnten:

• Es ist ein Hack - es verwendet Aufzählungen für etwas, für das sie nicht gedacht waren
• Es ist verwirrend für Leser, die es noch nicht gesehen haben

Ich verlasse mich stark auf Bücher als Wissensquelle - dies sind hervorragende Grundlagen, und ich denke, Infestus hat Recht, dass Sie in Ihrer Freizeit erhebliche Mengen an Büchern verbrauchen sollten, da diese Ihre Fähigkeiten wirklich beschleunigen. Bücher sind jedoch nicht die einzige Informationsquelle, die Sie meines Erachtens konsumieren sollten - besuchen Sie Ihre lokale Benutzergruppe, lassen Sie sich die relevanten Technologie-Newsletter in Ihren Posteingang senden und lesen Sie Blogs.

Ich widerspreche jedoch der Behauptung, dass es die Art und Weise ist, wie es getan werden muss , weil es in einem Buch auf eine bestimmte Weise geschrieben ist . Ja, Bücher bieten großartige Ratschläge, und sie werden von Experten verfasst und von Experten begutachtet. Da ich jedoch an einem vergleichsweise einfachen Buch mitgewirkt habe, kann ich Ihnen sagen, dass es in der Regel mindestens zwei Jahre dauert, bis ein Buch fertig geschrieben, bearbeitet und veröffentlicht ist . Der technologische Wandel vollzieht sich rasant und die Ratschläge von vor zwei Jahren sind möglicherweise nicht mehr die richtigen Ratschläge für heute. Generische Principals haben sich oft bewährt, aber die Optimierung einer bestimmten Aktivität kann durch eine neue Hardware- oder Softwareversion ungültig gemacht werden.

Der Vorschlag, Infestus zu bitten, Vorschläge mit Ihnen durchzugehen, ist ausgezeichnet - gehen Sie weg, lesen Sie alles und kommen Sie mit einer Reihe von nachdenklichen Fragen zurück, die Sie bereits zu beantworten / selbst zu lösen versucht haben, zusammen mit Ihren unterstützenden Beweisen für Ihre Methode.

Es gab Fragen, ob Sie nach 5 Jahren noch ein Junior waren. Für mich ist das wichtigste Kriterium dafür, ob jemand ein Junior ist, nicht die jahrelange Erfahrung, sondern die Notwendigkeit der Löffelfütterung. Ich erwarte, dass ein Entwickler auf mittlerer Ebene relativ autark ist, ein aufmerksamer Konsument von Wissensquellen, der darauf reagieren und es auf seine Situation ausweiten kann. Sie sollten auch in der Phase sein, in der sie mit dem Unterrichten von Junioren beginnen können, da sie ein festes Verständnis für ihr Thema haben, so dass sie die Dinge klar erklären können. Die andere Kernkompetenz ist das Vertrauen - wenn Sie die Arbeit erledigt, das Zeug gelesen und etwas Anständiges produziert haben, haben Sie keine Angst davor, sich in einem Debattengericht dafür einzusetzen, da ein Junior eine Validierung benötigt. Ein Entwickler bittet um Konsens.

Arbeitsplatzmanieren beiseite legen, die Realität einer Mentorenrolle, die Senior-Entwickler haben, beiseite legen, Ihren eigenen Wunsch zu erforschen, beleidigendes Verhalten beiseite legen und Fetische für Bücher beiseite legen ...

Der Zweck einer Codeüberprüfung in einem Team besteht darin, 1) Code zu validieren und 2) sicherzustellen, dass die Person, die den Code schreibt, die Bedeutung der Code-Verbesserung versteht. Es ist nicht der richtige Ort, um zu sagen "Ändere das, weil Martin Fowler es im GoF-Buch gesagt hat". Es ist jedoch der richtige Ort, um zu sagen: "Ändere dies, weil [kurze Erklärung]; das wird im GoF-Buch ausführlicher besprochen."

Wenn Ihr leitender Entwickler nicht zumindest schlicht und subtil eine Erklärung für eine Änderung liefert und darauf besteht, die Redewendung "wegen [Buch]" zu verwenden, ist er ein bisschen schlau und ein Idiot. Wie gehst du damit um? Erwähnen Sie es mündlich in einer Teambesprechung und bitten Sie Ihre Teamkollegen, ein oder zwei Erklärungen abzugeben, die den Vorteil oder die Notwendigkeit der Änderung zusammen mit dieser hilfreichen Buchreferenz erläutern. Vergessen Sie nicht, ihm für die Referenz zu danken.

Seien Sie ehrlich, Ihr Ziel ist es, den Änderungsvorschlag zu schätzen und nicht für Ihre Aufgabe oder Ihren Job demotiviert zu werden. Sag ihm das. "Ich würde den Änderungsvorschlag mehr begrüßen, wenn Sie den Vorteil oder die Notwendigkeit der Änderung kurz beschreiben könnten, wenn Sie meinen Code überprüfen. Ich finde, dass Ihre Buchreferenzen allein ein bisschen demotivierend sind."

Wenn er es weiterhin ablehnt, eine einfache Erklärung mit seinen Buchreferenzen zu liefern, wenn Sie ein anderes Buch oder eine Ressource von gleicher oder größerer Bekanntheit in der Branche mit einer anderen Meinung liefern können und es Ihrem Szenario entspricht, können Sie möglicherweise Ihr eigenes Buch hinzufügen Hinweis in Ihrem Bewertungskommentar unter Berücksichtigung der Beibehaltung des Originalcodes. Tun Sie dies oft genug, er könnte zurückweichen. Seien Sie sehr vorsichtig, dass das Gegenargument richtig und bedeutend wichtiger ist. Es ist in Ordnung, einen leitenden Entwickler irren zu lassen und trotzdem seinen Willen zu behalten. Das habe ich gelernt und muss es immer wieder lernen.

Ich würde sagen, dass es unmöglich ist, Programmieren nur aus Büchern zu lernen, aber die guten Bücher werden Ihnen einen enormen Schub geben. Es ist wie Karate - Sie werden keinen schwarzen Gürtel bekommen, der nur darüber liest;) Ich glaube, dass sich Mr. Infestus in diesem speziellen Fall auf "Effective Java" von Joshua Bloch bezog. Es ist wirklich ein großartiges Buch über Java-Entwicklung und Sie sollten es auf jeden Fall lesen, wenn Sie es noch nicht getan haben.