Wie können Sie feststellen, ob der Rat eines erfahrenen Entwicklers schlecht ist? [geschlossen]

Vor kurzem habe ich meine erste Stelle als Junior-Entwickler angefangen und ich habe einen Senior-Entwickler, der mich in diesem kleinen Unternehmen betreut. Es gibt jedoch einige Male, in denen er mir Ratschläge zu Dingen gibt, mit denen ich einfach nicht einverstanden bin (das widerspricht dem, was ich in mehreren guten Büchern über das von Experten geschriebene Thema gelernt habe, und auch Fragen, die ich auf einigen Q & A-Sites gestellt habe, stimmen überein Angesichts unseres vollen Terminkalenders haben wir wahrscheinlich keine Zeit für lange Debatten.

Bisher habe ich versucht, das Problem zu umgehen, indem ich ihm zuhörte und einen Kontrapunkt ansprach, der auf dem basiert, was ich als aktuelle bewährte Praktiken gelernt habe. Er hebt seinen ursprünglichen Punkt noch einmal an (die meiste Zeit sagt er Best Practice, ist wartbarer, aber ging einfach nicht weiter). Ich mache mir eine Notiz (da er keinen neuen Punkt angehoben hat, um meinem Kontrapunkt entgegenzuwirken), und denke darüber nach es und Forschung zu Hause, aber keine Änderungen vornehmen (ich bin immer noch nicht überzeugt). Aber vor kurzem hat er mich noch einmal angesprochen, meinen Code gesehen und mich gefragt, warum ich ihn nicht auf seinen Vorschlag abgeändert habe. Dies ist das 3. Mal in 2-3 Wochen.

Als Nachwuchsentwickler weiß ich, dass ich ihn respektieren sollte, aber gleichzeitig kann ich einigen seiner Ratschläge einfach nicht zustimmen. Dennoch werde ich unter Druck gesetzt, Änderungen vorzunehmen, von denen ich denke, dass sie das Projekt verschlimmern werden. Natürlich könnte ich mich als unerfahrener Entwickler irren und sein Weg könnte besser sein, es könnte einer dieser Ausnahmefälle sein.

Meine Frage lautet: Was kann ich tun, um besser beurteilen zu können, ob der Rat eines Senior-Entwicklers gut, schlecht oder vielleicht gut, aber im heutigen Kontext veraltet ist? Und wenn es schlecht / veraltet ist, welche Taktik kann ich anwenden, um es trotz seines 'Drucks' nicht auf seine Weise umzusetzen und gleichzeitig die Tatsache beizubehalten, dass ich ihn als Senior respektiere?

Erstens erwarte ich als Senior Developer von den Junioren, die ich für Projekte leite, dass sie ihre Anliegen direkt und direkt an mich richten. Wenn sie nicht einverstanden sind, ist das in Ordnung mit mir. In einigen Fällen werde ich auf ihre Bedenken eingehen. In den meisten Fällen werden ihre Bedenken mit einer kurzen Begründung beiseite geworfen , nicht aus Respektlosigkeit für den Entwickler selbst, sondern aus einem anderen Grund wie:

1. Der Junior hat nicht alle Informationen zur Hand, um die getroffene Entscheidung zu verstehen. In einigen Fällen kann eine kleine Erklärung dem Entwickler helfen, das Problem zu überwinden und mit einer unidealen Situation umzugehen.
2. Der Junior hat schlechte Informationen. Vergiss nicht, dass du tatsächlich ein Junior bist. Das ist das Äquivalent zu einem Teenager in Bezug auf Software. Ich bin sicher, Sie haben viele großartige Ideen, aber es ist möglich, dass Sie nicht alles wissen. Ich finde, die widerstandsfähigsten Nachwuchsentwickler sind diejenigen, die fest davon überzeugt sind, dass sie wissen, was für den Code, das Unternehmen und die Welt am besten ist. Diese Entwickler sind besser bedient, wenn sie Demut erwerben.
3. Die Entscheidung, etwas Besonderes zu tun, wurde über dem Kopf des Senioren getroffen. Der Senior arbeitet am Ende immer noch für einen anderen. Möglicherweise gibt es tatsächlich einen besseren Weg, um etwas zu tun, einen effizienteren Weg, um etwas zu schreiben, oder eine bessere Software / Hardware, um die Arbeit zu erleichtern. Das Geschäft bestimmt jedoch nach wie vor die Entscheidungen. Geschäftsführer, Direktoren, Vizepräsidenten usw. treffen häufig Entscheidungen, die sich auf den Entwicklungsprozess auswirken. Dies liegt außerhalb der Kontrolle des Senioren, und wenn sich die Junioren darüber beschweren, erhöhen sie lediglich den Stress des Senioren.
4. Der Senior hat keine Zeit, dies zu berücksichtigen. Es gibt Fristen, und manchmal ist das Ändern von Mustern, Praktiken und Verhaltensweisen in der Zwischenzeit kostspielig. Da es sein Hals am Hackklotz ist, ist es oft wichtiger, das Produkt funktionsfähig und pünktlich zu machen, als "perfekt geschrieben".

Dies sind nur die Dinge, an die ich auf Anhieb denken kann. Es gibt unzählige Gründe, warum eine Idee, eine Praxis oder ein Konzept von jemand höherem als Ihnen verworfen oder verworfen wird. Viele von ihnen sind unangenehm, aber sie alle beruhen auf der Tatsache, dass wir alle Menschen sind und wir alle Meinungen haben. Seine Meinung ist gerade Ihrer zahlenmäßig überlegen.

Unter Berücksichtigung dieser Konzepte sollten Sie weiterhin Ihre Bedenken an den leitenden Entwickler richten. Finden Sie einen anderen erfahrenen Entwickler, der möglicherweise in der Lage ist, die Lücken zu füllen. Viele leitende Entwickler sind dort, wo sie sind, weil sie mit Software besser sind als mit Menschen. Einige sind dort, wo sie sind, weil sie wussten, wessen Hintern sie küssen sollten, als sie Praktikanten waren. Finden Sie jemanden, der wirklich versteht, was es bedeutet, jemanden zu betreuen und seine ehrliche Meinung einzuholen. Sie stimmen möglicherweise nicht mit Ihnen überein und füllen die Lücken aus, die Sie nicht haben. Sie können Ihnen zustimmen und helfen, Ihre Sache zu sammeln oder Ihre Situation zu verbessern.

Zu keinem Zeitpunkt sollten Sie irgendeine Art von Aufstand erheben. Selbst wenn Sie in Ihrem Herzen glauben, dass Ihr Weg richtig ist, wurde Ihnen eine Anweisung gegeben, dieser zu folgen, und Sie sollten dieser Anweisung folgen (es sei denn, dies ist offensichtlich illegal). Wenn Sie Probleme haben, diese Anweisungen zu befolgen, sollten Sie versuchen, den Grund dafür herauszufinden, weil Sie feststellen werden, dass dieses Verhaltensmuster in sehr vielen Unternehmen, die jede Art von Software herstellen, weit verbreitet ist.

Ihre beste Option ist es, Ihre Arbeit weiterhin ethisch und professionell zu erledigen. Holen Sie sich die Software, von der Sie aufgefordert werden, auf vorbildliche Weise zu vervollständigen, und entkommen Sie der Situation, indem Sie sie herausstufen. Wenn keine Werbeaktionen verfügbar sind, verfügen Sie über zahlreiche Referenzen und Erfahrungen, um in anderen Abteilungen oder Unternehmen nach Möglichkeiten zu suchen.

Respektieren Sie den leitenden Entwickler. Er ist mehr für den Erfolg des Projekts als Sie. Da er die Verantwortung hat, erhält er auch die Autorität. Wenn er sagt, ändern Sie etwas, dann tun Sie es.

Zögern Sie jedoch nicht, Ihre Bedenken vorzutragen, wenn Sie auf ein Problem stoßen, wie Sie es bereits haben.

Setzen Sie sich schließlich zu ihm und erklären Sie ihm die Frage, die Sie hier gestellt haben. Vielleicht fehlt Ihnen etwas Großes, vielleicht öffnet er sich Ihren Vorschlägen in beiden Fällen mehr, lassen Sie ihn nicht im Dunkeln, wenn Sie glauben, dass sein Rat schlecht ist.

In diesem Fall müssen Sie sich mit dem Senior-Entwickler unterhalten . Vielleicht weiß er etwas, das Sie nicht über den Code oder die technischen / geschäftlichen Anforderungen wissen. Wenn ja, sollten Sie es lernen.

Mach das privat. Es könnte als herausfordernde Autorität angesehen werden, und solche Dinge werden am besten einzeln ausgeführt. Zeigen Sie die Bereitschaft, Kompromisse einzugehen und zusammenzuarbeiten, indem Sie sein Dienstalter anerkennen und respektieren, aber beharrlich darauf sein, Ihre Fragen zu beantworten. Gehen Sie die Situation aus einem kollaborativen Rahmen an, nicht aus einem kämpferischen. Sie könnten ihn bitten, Sie zu betreuen.

Am Ende des Tages müssen Sie Ihre eigenen Ideen (die, um fair zu sein, relativ neu und ungetestet sind) mit seinen abwägen. Vielleicht haben Sie ja recht, aber Sie sollten Ihr Bestes tun, um von erfahreneren Leuten zu lernen, damit Sie eine fundiertere Entscheidung treffen können. Ein guter Senior-Entwickler begrüßt die Möglichkeit, selbst mit Junior-Entwicklern zusammenzuarbeiten, zu beraten und zu lernen, und begrüßt es, wenn ihre Ideen auf konstruktive Weise hinterfragt werden, weil auch sie wissen, dass sie manchmal falsch liegen.

Die Art und Weise, wie Sie oft sagen, ist durch einen gesunden Menschenverstand Ansatz. Denken Sie daran, dass der leitende Entwickler möglicherweise mehr über das Projekt weiß, aber möglicherweise nicht mehr über die richtige Vorgehensweise. Sie müssen abschätzen, was er Ihnen sagt - er gibt Ihnen schlechte Ratschläge, wenn das, was er sagt, im Widerspruch zu dem steht, was seine Befürworter behaupten (dh Leute, die älter sind als er; nicht unbedingt in Ihrer Firma ... Ich spreche davon bekannte "Promi" -Entwickler, die häufig Bücher über die richtige Art der Softwareentwicklung oder zumindest branchenweit anerkannte Best Practices veröffentlichen oder schreiben.

Hier ist ein Beispiel für einen "schlechten Rat" eines leitenden Entwicklers (oder eines beliebigen Entwicklers): Wenn er nicht weiß, was eine lose Kopplung ist und warum dies eine gute Sache ist, wird Ihnen empfohlen, den gesamten Code in den Code zu schreiben -Nach einer ASPX-Datei ist es offensichtlich, dass der leitende Entwickler keine Ahnung hat und auf seine Ratschläge nicht zu hören ist.

Wenn er Ihnen andererseits sagt, wie ein bestimmtes Modul im System funktioniert, ist es oft am besten, solange zuzuhören, was er Ihnen sagt, spuckt nicht gegen die richtigen Entwicklungsprinzipien.

Hier ist meine Faustregel: Ein leitender Entwickler in einem Unternehmen ist möglicherweise einfach der Entwickler mit der längsten Amtszeit. er könnte keine wirklichen Fähigkeiten haben. Sagt er Dinge, die gegen das verstoßen, was einige der angesehensten Entwickler auf Ihrem Gebiet sagen (Leute mit viel mehr Erfahrung als er und die viel kompetenter und respektierter sind)? Wenn dies der Fall ist, ist sein Rat wahrscheinlich schlecht, es sei denn, es liegen sehr extreme Umstände vor.

Volle Erwartung von Abstimmungen / Meinungsverschiedenheiten für extrem voreingenommene Sichtweisen.

Es mag schwierig sein, den Standpunkt des Senior-Entwicklers zu verstehen, und ja, er könnte die Dinge auf den falschen Weg führen. Bei großen Projekten ist jedoch die Konsistenz wichtiger.

Es wäre ein völliges Chaos, wenn einige Entwickler ihren eigenen Codierungsstilen, Standards, Methoden und Entwurfsmustern folgen würden. Wenn Dinge falsch gemacht werden, ist es immer besser, durchweg falsch zu sein als viele verschiedene Arten von Fehlern und einige Dinge, die richtig gemacht wurden.

Wenn es darum geht, Wartungen durchzuführen, Funktionen hinzuzufügen oder Fehler zu beheben, ist es viel einfacher, wenn die Probleme mit dem vorhandenen Design im Voraus bekannt sind.

Es ist gut, respektvoll anderer Meinung zu sein, aber am Ende ist es am besten, wenn Sie sich anstellen. Jeder in einem Team, der Schurke wird, wird nicht als Teamplayer gesehen.

Wenn der Senior Ihnen keine guten Gründe nennen kann, warum er die branchenüblichen Best Practices ignoriert, dann verschwenden Sie Ihre Zeit dort nicht. Sie werden nie weiterkommen, weil Sie zu bedrohlich sind, und möchten Sie trotzdem Zeit damit verbringen, einen Stapel fehlerhaften Codes zu pflegen?

Die meisten Entwickler hören auf zu lesen, wenn sie das College verlassen. Sie haben nicht, also sind Sie bereits in den Top 10%. Heutzutage gibt es viele Möglichkeiten. Wenn es in Ihrer Stadt keinen Arbeitsmarkt gibt, suchen Sie nach einer besseren Stadt.

Wow, das ist eine wunderbare Gelegenheit für dich, zu glänzen und deine Fähigkeiten zu demonstrieren. Zu Beginn meiner Karriere hatte ich jemanden, der mein Vorgesetzter war, der keine Entscheidung treffen konnte, also nutzte ich diese Gelegenheit, um zu lernen, wie man die Arbeit der nächsthöheren Ebene macht. Es hat mich befördert. Do solltest das auch machen.

Als leitender Entwickler würde mich diese Art von passiv aggressivem Nitsammeln verrückt machen und nach der Konfrontation würden Sie mich dazu bringen, Ihnen eine schlechte Bewertung zu geben. Die perfekte Lösung ist die, mit der das Team zusammenleben kann.

Was den Stil betrifft, sollte dies von Ihrem Styleguide und den Best Practices bestimmt werden, die von Ihrer Herkunft abhängen. Wenn Sie leidenschaftlich dafür argumentieren, aber einmal eine Entscheidung getroffen haben, leben Sie damit und arbeiten Sie mit im Rahmen des Teams, in dem Sie sich befinden.

Sie befinden sich in einer nicht so guten Situation, aber wie HLGEM hervorhob, können Sie diese Positionen in verdeckte Segnungen verwandeln. Ihre Frage ist facettenreich, daher werde ich sie in Teilen behandeln.

Ich vermute, er weiß es nicht. Gleichzeitig versucht er, mir zu zeigen, dass Arroganz dazu führen kann, dass ich bei Fragen nicht oft zu ihm komme.

Dies könnte sehr gut wahr sein. Es gibt eine Vielzahl von Entwicklern, die seit Jahrzehnten in der Branche tätig sind und keine fähigen Softwareleads haben - von einem Entwicklungs- oder Mentoring-Standpunkt aus (da gibt es einen Unterschied). Die Erfahrung stammt aus der Bewältigung neuer Herausforderungen, dem Ausprobieren neuer Ideen und dem Erlernen neuer Fähigkeiten. Die Mehrheit der Programmierer verbringt jedoch ihr Leben in einem Flügel des Corporate Office und arbeitet mit ihren zuverlässigen Visual Basic- und Java-Tools an der Payroll-Anwendung von ihrem kalten, grauen Büro.

Daran ist nichts auszusetzen . Für viele Entwickler ist dies alles, was sie jemals wollten und sie sind vollkommen zufrieden mit der Situation - es ist jedoch keine ideale Situation, um eine zukünftige Generation von Programmierern zu fördern, geschweige denn Entwickler zu führen.

Bravado und Arroganz können ein Verteidigungsmechanismus sein, der versucht, Unzulänglichkeiten zu decken. Wie gehst du damit um? Konfrontieren Sie es nicht direkt - wenn Ihre Führung inkompetent ist und der Chef nicht bereit ist, die Situation zu korrigieren, müssen Sie damit leben . Das bedeutet nicht, dass man sich überschlagen und sterben muss, aber man kann niemanden zwingen , eine gute Führung zu übernehmen.

Er überprüft jedoch nur meinen Code und die meisten seiner Kommentare beziehen sich auf Codierungsrichtlinien

Das ist es, was mich denken lässt, dass Sie Recht haben, weil er vielleicht kein guter Programmierer ist. Das soll nicht heißen, dass er im Moment kein besserer Programmierer ist als Sie (zumindest wird er mehr Erfahrung und Erfahrung haben, wenn er so lange in der Branche ist), aber das bedeutet auch nicht, dass er ein Programmierer ist wirksames Blei. Richtlinien sind alle gut und schön, aber sie sind nach der Funktion, Wirksamkeit und Effizienz des Codes an zweiter Stelle.

Was soll ich in einer solchen Situation tun?

Ich habe meinen Manager über diese Situation informiert, und ich habe ihn gebeten, meine Führung zu ändern, obwohl er jedes Mal "Ja" sagt, aber keine ernsthaften Maßnahmen ergreift.

Haben Sie alle diese spezifischen Punkte für den Manager aufgelistet und Beispiele angegeben, um sie zu sichern? Wenn Sie einfach zu ihm gegangen sind und gesagt haben: "Ich brauche eine neue Spur", wird er Sie nicht ernst nehmen und es eher als "zwischenmenschliches Problem" als als technisches Problem wahrnehmen. Die Reaktion vieler Chefs in dieser Situation besteht darin, sie in der Hoffnung zu ignorieren, dass sie sich "von selbst" erarbeitet.

Hier sind einige Vorschläge.

1. Scheuern Sie nicht an Ihrer Situation - versuchen Sie es mit Feuer, obwohl es Ihnen keinen Spaß macht, und bringen Sie Ihnen einige wichtige Forschungsfähigkeiten für später in Ihrer Karriere bei.
2. Schieben Sie Ihren Vorsprung, um mehr involviert zu sein. Tun Sie dies vorsichtig und respektvoll . Schieben Sie weiter und bleiben Sie hartnäckig, bis er nachgibt (dies funktioniert tatsächlich in vielen Situationen im Leben).
3. Wenn sich Ihr Lead nicht einmischt, prüfen Sie, ob Ihnen andere helfen können. Solange Sie nicht in einem Sweat-Shop arbeiten, in dem es nur um das Melken von Stunden geht, macht es Ihrem Unternehmen nichts aus, wenn ein anderer Entwickler mehr Erfahrung damit hat, Ihnen einige Seile zu zeigen und Ihren Code zu überprüfen.
4. Halten Sie nach einem neuen Job Ausschau. Ich würde nicht sagen, dass Sie sich in einer "Muss-Situation" befinden, aber es würde Ihrer Karriere nicht schaden, wenn Sie sich an einem Ort befinden, der Ihre Entwicklung als Programmierer ernst nimmt.

Wenn Sie einen besseren Weg, um ein bestimmtes Problem zu lösen, nur DO IT .

Lassen Sie Ihren Code / Ihre Lösung Ihr bestes Argument sein. Ansonsten halte dich an das, was dir gesagt wurde.

Ein typisches Beispiel

Als ich ein Junior war, hatte ich eine Situation, in der ein bestimmter Codeabschnitt nicht das Beste war, was er sein konnte. Anstatt nur darüber zu diskutieren, habe ich es einfach verbessert, DANN habe ich meinem Senior die Ergebnisse gezeigt. Er akzeptierte es, weil der Code immer König ist.

Als unerfahrener Entwickler könnte ich mich natürlich irren und sein Weg könnte besser sein. Daher frage ich mich, wie ich besser beurteilen kann, ob ein Rat eines erfahrenen Entwicklers gut oder schlecht / veraltet ist.

Sie können ein erfahrener Entwickler werden. Bis Sie das tun, sind Sie nicht in der Lage zu beurteilen, ob Ihre Intuition als Junior richtig war oder nicht, und bis dahin spielt es keine Rolle.

Lesen Sie in der Zwischenzeit die Antwort von Joel Etherton.

Ich würde dringend empfehlen, nicht zu versuchen, "es nicht auf seine Weise umzusetzen".

Bisher klingt es so, als hätten Sie das Richtige getan. Sie waren demütig und haben einen Kontrapunkt angesprochen. Ich konnte anhand Ihrer Frage nicht sagen, ob Sie mit seiner Methode einfach nicht einverstanden waren oder ob Sie nicht einverstanden waren und eine Alternative vorstellten. Fazit: Bieten Sie immer eine klare und durchdachte Alternative an, wenn Sie versuchen, die Annäherung eines anderen abzuschießen . Wie er es vielleicht sieht, haben Sie eine gute Idee, die funktionieren könnte, und er hat eine Idee, die funktioniert.

In jeder Position sind wir gezwungen, die ganze Zeit suboptimale Dinge zu tun. Wenn Sie es wirklich nicht mögen, können Sie tun, was Sie getan haben, und es ansprechen. Danach ist es der Weg des Chefs oder die Autobahn. Auf der helleren Seite sind Sie als Junior vor einem Großteil des Risikos von Fehlentscheidungen geschützt.

Such dir Schlachten aus. Wenn Sie von einer Stunde Arbeit sprechen, müssen Sie Ihren Code manchmal ändern, bis Sie sich hocharbeiten. Wenn Sie das nächste Mal ein großes Projekt erhalten, fragen Sie vorab nach einer Gelegenheit, Ihre Ideen vorzustellen, bevor Sie beginnen. Nehmen Sie sich etwas Zeit und erstellen Sie eine großartige Demo oder einen Prototyp.

Erschreckenderweise habe ich einfach aufgehört zu fragen. Wenn ich eine andere Option habe, schweife ich einfach ab und tue es auf seine Weise, aber füge mein eigenes Flair hinzu. Verwenden Sie es als Lernerfahrung, um Ihre Fähigkeiten zu verbessern und dennoch sein Bedürfnis zu stillen, die alte Schule zu behalten.

Am Ende achtet nicht jeder Senior-Entwickler auf neue Methoden. Sie haben zuweilen altmodische Methoden, die für die Sprache, mit der sie vor 20 Jahren angefangen haben, großartig waren, gelten aber in der heutigen Welt als hacky oder "schlecht riechend".

Das klingt vielleicht nach einem schrecklichen Weg, weiterzumachen, und das ist es auch. Aber ich habe auch viel von der Arbeitsweise meiner Senioren gelernt. Aber das ist wirklich nur meine Meinung. Am Ende muss man bei seiner Arbeit glücklich sein und Ablenkungen und Spannungen auf einem niedrigen Niveau halten. Und wenn Sie nichts dagegen haben, werden Sie feststellen, dass der Stress stark nachlässt.

Traue keinen älteren Leuten, weil sie älter sind. Fordern Sie die Behörde so oft wie möglich heraus. Eine zuständige Behörde sollte in der Lage sein, jede Frage überzeugend zu beantworten. Das macht ihn zu einer Autorität, nicht wahr?

Weil jemand für sein ganzes Leben abergläubische Überzeugungen hat, heißt das nicht, dass er Recht hat. Denken Sie daran, im Mittelalter glaubten die Menschen, die Erde sei flach und einige dieser selbstgerechten Esel fühlten sich sogar berechtigt, die Zweifler zu töten. Es stellte sich heraus, dass die Zweifler Recht hatten. Soviel zu schlechten Kritiken.

Fürchte niemals eine schlechte Bewertung. Würdest du einem Blinden vertrauen, der die Farbe beurteilt?

Gute Antworten oben würden hinzufügen, dass eine Antwort wie "Best Practices" oder "besser wartbar" eine Gelegenheit ist , etwas zu lernen . Sie sagen: "Können Sie mir ein Beispiel geben, warum dieser Weg der beste ist, damit ich den Unterschied verstehen kann?" oder "In welchen Situationen wäre dieser Weg besser zu pflegen als auf andere Weise, damit ich lernen kann, so vorauszuplanen?"

Wenn der Senior Recht hat, ist es einfach, Ihnen ein Beispiel zu geben. Wenn er ein Papagei ist ... gib ihm einen Cracker, um die Kürbis zu stoppen, und tu, was du für am besten hältst. Bis anders bestellt.

Wenn der Senior als Mentor fungiert, erklärt er auf Nachfrage, warum.

Wie HLGEM und Jarrod zuvor sagten, ist dies wirklich ein Segen in der Verkleidung. Beide Antworten sind großartig und ich möchte einige Punkte hinzufügen.

Da sich Ihr Lead nicht in Ihrer Domäne befindet, können Sie einige wichtige Entscheidungen für Ihren Teil der Anwendung treffen, da Ihr Lead nicht viel über Middleware weiß. Sie können mit Ihrem Vorgesetzten auch abschließen, wie die Anwendung ablaufen soll, was die Produktbenutzer möchten und wie Ihr Vorgesetzter eine Situation angehen möchte, die ihm vom Produktteam präsentiert wird. Sagen Sie mir, wie viele Leute diese Art von Wissen in einer Anwendung erhalten.

Wenn Sie sich in einem großen Team befinden, werden Sie sicher Hilfe von Ihren Teamkollegen und / oder Ihrem Lead erhalten, aber Sie werden nicht wissen, wie Ihr Manager oder das Produktteam denkt, weil solche Dinge in der Regel Ihren Lead durchlaufen und sein können Einige ältere Entwickler in einem Team. Ich bin damit einverstanden, dass Projekte von einer Person schwer zu realisieren sind, aber wenn die andere Seite der Medaille so großartig ist, warum sollte man dann eine Chance verpassen? Lernen Sie, was Sie lernen können, genießen Sie, solange Sie können, und überzeugen Sie Ihren Manager, wenn es zu schwierig wird, wie Jarrod sagte, oder finden Sie je nach Situation einen neuen Job / ein neues Projekt.

Du wirst es während deiner gesamten Karriere mit solchen Leuten zu tun haben. Und es wird viele geben, mit denen Sie sich nicht einig sind, wie ein Codierungsproblem am besten gelöst werden kann. Das Beste, was meiner Meinung nach im Laufe der Jahre für mich funktioniert hat, ist, dass sie, wenn sie ein Problem weiter angehen, mit ihnen in Kontakt treten und ihnen mitteilen, dass Sie ihre Lösung unter den verschiedenen möglichen Lösungen in Betracht gezogen haben und dass Sie das Gefühl hatten, die Lösung zu sein Sie waren der Meinung, dass dies der beste Ansatz in dieser Situation war.

Nun, wenn Sie sich jedes Mal gegen ihren Rat entscheiden, müssen Sie gelegentlich nachgeben und ihren "Rat" von Zeit zu Zeit anwenden, um nur ein paar gekräuselte Federn zu glätten. Solange sie nicht das Gefühl haben, dass Sie ihre Eingaben jedes Mal ablehnen, trägt dies erheblich dazu bei, den Frieden zwischen Ihnen zu wahren.

Bedenken Sie auch, dass sie ein leitender Entwickler sind und länger in dieser Umgebung gearbeitet haben als Sie. Die Codierung im realen Leben entspricht häufig nicht den Best Practices oder den von der Community akzeptierten Standards. Es kann einen Grund dafür geben, dass sie empfohlen haben, etwas auf eine bestimmte Art und Weise zu tun, die sie nicht in der Lage sind, vollständig zu artikulieren. Selbst wenn Sie mit ihnen nicht einverstanden sind, stellen Sie sicher, dass Sie deren Ratschläge nicht allein aufgrund der Tatsache ablehnen, dass Sie der Meinung sind, dass Ihre Lösung besser ist.

Es geht nur um Balance. Und nicht nur das Gleichgewicht, sondern auch das Gleichgewicht der Teams. Viele Projekte sind gescheitert, nicht weil die Entwickler dazu nicht in der Lage waren, sondern weil sie keine Möglichkeit fanden, freundschaftlich zusammenzuarbeiten.

Ich möchte einige Dinge aus meiner persönlichen Erfahrung zur Verfügung stellen, die als ergänzende Antwort auf eine hier von jzd gepostete Frage betrachtet werden sollten ...

1. Fragen Sie einen anderen Senior-Entwickler,
2. Recherchiere alleine.

In einem Berufstermin sollte ich von einem Senior betreut werden. Er wusste einiges, aber ehrlich gesagt nicht viel, leider wusste er es nicht, also war er bei seinen Antworten äußerst zuversichtlich. Ich hatte irgendwie das Gefühl, dass das, was er sagte, falsch war. Ich hatte Beweise dafür, dass Dinge, die er tat, gegen die Best Practices verstießen, die in meiner MS-Zertifizierung erwähnt wurden :-). Danach fing ich an, andere Leute zu fragen, die in anderen Unternehmen arbeiteten (Stackexchange war damals noch nicht in Betrieb), und fing an, Blogs zu lesen, um Antworten zu vergleichen.

Es wäre toll, wenn ich mich irre, denn ich würde nur mein Verhalten ändern, aber das war ich nicht.

In den letzten Jahren ist mir etwas aufgefallen, fast jedes Unternehmen, in dem ich tätig bin, bei fast jedem Projekt, an dem ich arbeite, bei fast jeder neuen Anstellung (unabhängig von Können / Erfahrung) möchte ich etwas "anderes" machen.

Dies können die Codierungsstandards oder die Gesamtarchitektur oder die Sprache oder die Methodik sein. Aber es ist immer etwas. Häufig heißt es nur: "Sollte nicht für unsere Endbenutzer alles besser dokumentiert werden?"

Mein Rat an Sie ist , nicht dieser Typ zu sein .

Eines Tages wirst du ein hochrangiger Typ sein, der eingestellt und bezahlt wird, um diese Entscheidungen zu treffen. Wenn dieser Tag kommt, gehe dorthin! Erkennen Sie bis zu diesem Tag Ihre Position. Ich habe einen Chef. Mein gesamtes Anliegen ist es, meinen Chef glücklich zu machen. Es geht nicht darum, Entscheidungen zu treffen, die außerhalb meiner Gehaltsklasse getroffen wurden. Wenn Sie sich nicht sicher sind, sprechen Sie mit Ihrem Chef / Vorgesetzten und finden Sie es heraus.

Im Allgemeinen ist es jedoch weitaus besser, alle mit einem veralteten Ansatz an Bord zu haben, als die Hälfte des Teams, das dem veralteten Ansatz folgt, 1/4 des Teams, das einem neuen Ansatz folgt, und 1/4 des Teams, das versucht, einen innovativen Ansatz zu entwickeln , brandneuer Ansatz.

Es gibt eine Unterströmung bei all diesen Dingen, die meiner Meinung nach klar herausgestellt werden sollten: Sei nicht kämpferisch . Behalte deine Beziehung zu ihm bei. Es ist großartig, seinen Rat mit einem Körnchen Salz zu nehmen und ihn in Büchern und auf Websites wie diesen zu bestätigen, aber greifen Sie ihn nicht an. Wenn er ein leitender Entwickler ist und viele Projekte durchlaufen hat, ist er kein Idiot und es gibt viel von ihm zu lernen. Wie es scheint, haben Sie es bereits getan, drücken Sie Ihren Wunsch aus, seinen Standpunkt zu verstehen. Auch wenn Sie sich sicher sind, dass er Unrecht hat und Sie Recht haben, akzeptieren Sie die Möglichkeit des Gegenteils (anscheinend haben Sie dies bereits verstanden). Machen Sie deutlich, dass Sie argumentieren, weil Sie seinen Standpunkt besser verstehen wollen, und nicht, weil Sie versuchen, ihm das Gegenteil zu beweisen.

Wenn er sich nicht sofort bei Ihnen meldet, wenn Sie ihm eine Frage stellen, oder wenn seine Antwort vage und / oder nicht hilfreich ist, gehen Sie nicht davon aus, dass er Sie umgehauen hat. Wie bereits erwähnt, ist er möglicherweise beschäftigt und / oder gestresst.

Es ist auch toll, Geduld zu haben. Behalten Sie eine Liste von Dingen in Ihrem Kopf, von denen Sie denken, dass sie anders gemacht werden sollten, und präsentieren Sie sie zum richtigen Zeitpunkt. Stellen Sie sicher, dass Sie eine Begründung für den Vorschlag neben "Es ist die beste Vorgehensweise" haben. Und seien Sie vorsichtig, um die Dinge richtig zu machen und um keine Fehler zu machen, damit Sie Glaubwürdigkeit haben, wenn Sie später Ihre Argumente vorbringen.

Bisher habe ich versucht, das Problem zu umgehen, indem ich ihm zuhöre, einen Kontrapunkt anspreche und seinen ursprünglichen Punkt erneut anspreche (die meiste Zeit wird er als bewährtes Verfahren bezeichnet, das besser zu warten ist, aber nur nicht weiter fortgeschritten ist). ..zu Hause darüber nachdenken, aber ... ich bin immer noch nicht überzeugt. Aber kürzlich ... hat er meinen Code gesehen und mich gefragt, warum ich ihn nicht auf seinen Vorschlag abgeändert habe. Dies ist das 3. Mal in 2-3 Wochen.

(Leicht bearbeitet für die Aktionen.)

Dieser Teil betrifft mich. Eine Möglichkeit, um zu sehen, ob Sie richtig sind oder nicht, besteht darin, zu verstehen, was er sagt. Was ich lese (mit meiner eigenen Geschichte, andere mögen anders sein), ist ein Junior-Entwickler, der nicht versteht, was der Mentor sagt, und nicht um Klärung bittet. Eine Möglichkeit, wie Sie es herausfinden können, besteht darin, ihn um eine Klarstellung zu bitten: Wie ist dies eine bessere Praxis als diese? Oder warum ist dies für unseren Code wartbarer? Wenn Sie seine Antworten darauf nicht kennen, wissen Sie wirklich nicht, ob er gute Ratschläge gibt oder nicht.

Der Teil, der mich wirklich beunruhigt, ist, dass er dich gebeten hat, es mehrmals zu ändern, und das hast du nicht. Hier ist eine Möglichkeit, wie es von seiner Seite aussehen könnte: Er bittet Sie, die Änderung vorzunehmen, Sie fragen, warum, er gibt Ihnen einen (seiner Meinung nach gültigen) Grund und Sie weigern sich, die Änderung vorzunehmen. Sie bitten nicht um Klärung, also geht er davon aus, dass Sie den Grund verstehen und entweder zu faul oder zu hartnäckig sind, um ihn zu ändern - und für einen leitenden Entwickler auch keine gute Sache, über Sie nachzudenken. Vertrauen Sie mir, es ist viel besser, Fragen zu stellen, als sich auf diese Weise einen Namen zu machen.

Ein paar Gedanken:

1 / Funktioniert es? Funktioniert er oder nicht? Ist das ein objektiver Grund, warum sein Weg minderwertig wäre?

Mit objektivem Grund meine ich etwas, das ohne Mehrdeutigkeit gemessen werden kann (Leistung, Fehler, Länge des Codes ...). Sein Weg ist besser ... weil er wahrscheinlich besser mit dem Rest der Codebasis übereinstimmt und weil es für ihn einfacher sein wird, Ihre Arbeit zu verwenden / wiederzuverwenden. Sie mögen es vielleicht nicht, aber darum geht es doch nicht, oder?

Wenn es nicht funktioniert oder bei wichtigen Metriken eine Underperformance aufweist, implementieren Sie es, vergleichen Sie seine Lösung mit Ihrer Lösung, und teilen Sie ihm dann mit, dass Sie es versucht haben, aber keine gute Leistung erzielen (geben Sie die Metriken an), und fragen Sie ihn wenn Sie einen Fehler in Ihrer Implementierung gemacht haben oder eine Anforderung vorliegt, die Ihnen nicht bekannt war

2 / Star-Programmierer sagen ... Warum scheißegal? Sie werden berühmte Programmierer finden, die sich bei vielen grundlegenden Themen wie Planung, Design, OOP vs. Prozedural, Komponententests, Ausnahmebehandlung, Quellcodeverwaltung usw. zutiefst uneins sind.

Wenn der einzige Unterschied in der Verarbeitbarkeit zwischen zwei Lösungen darin besteht, wer sie bevorzugt, überspringen Sie sie. Sie können von dem erforderlichen mentalen Training profitieren, indem Sie in einem Paradigma arbeiten, das Ihnen nicht gefällt

Basierend auf der Idee, dass Sie nur Ratschläge von Menschen annehmen sollten, denen Sie ähnlich werden möchten, lautet die Antwort, dass der Senior-Rat gut ist, wenn Sie wie er / sie werden möchten.

Die meisten meiner Probleme habe ich sortiert, indem ich in Foren gepostet und Antworten von anderen erhalten habe, und ich habe ungefähr 1 Jahr so ​​überlebt.

Was soll ich in einer solchen Situation tun?

Um ehrlich zu sein, so sind viele technische Berufe. Sie müssen ein Selbststarter sein, der schwierige Probleme selbst lösen kann (mit Hilfe des Internets und seiner Bewohner), wenn Sie müssen.

Im Hinblick auf Codeüberprüfungen und Hilfe bei Architekturentwürfen hatte ich selbst bei guten Managern noch nie eine Codeüberprüfung, die über "statische Variablen sollten mit dem Präfix a s_" hinausging.

Nutzen Sie die Gelegenheit, um zu lernen und zu lernen, wie man lernt; Das sind Fähigkeiten, die Sie für die Zukunft einsetzen können.

Wenn Sie für eine Sekunde glauben, das Management verstehe nicht, wie gut es Ihnen WIRKLICH gelingt, die Arbeit zu erledigen, dann liegen Sie wahrscheinlich falsch. Das Management versteht wahrscheinlich auch, dass Ihr Lead im Moment völlig nutzlos wäre, wenn er Sie ersetzen und Ihre Arbeit übernehmen würde.

Die WIRKLICHEN Gründe, warum sie Sie nicht umgesiedelt haben, sind, dass Sie trotz all Ihrer Herausforderungen, die Sie ihnen stellen, immer noch die beste Person für diesen Job sind. Sie schätzen Ihre Arbeit offensichtlich zu sehr, um sie an andere weiterzugeben.

Unterschätzen Sie nicht die Intelligenz des Managements ...

Sie sind viel schlauer als die meisten Entwickler glauben. Das habe ich erst verstanden, als ich angefangen habe zu managen. Sie sind sich wahrscheinlich auch bewusst, wie nutzlos Ihr Lead wirklich ist, aber sie sind wahrscheinlich machtlos, um dieses Problem anzugehen.

Lassen Sie mich ein Bild für Sie malen, Lead A mit 5 Jahren Erfahrung in der Firma ist inkompetent. Manager weiß das, empfiehlt seinem oberen Manager, Lead A zu entlassen. Oberer Manager fragt, warum er vor Jahren nicht behandelt wurde, wenn er so inkompetent ist. Manager sieht jetzt schlecht aus, zumal Lead A ein aufgeblähtes Gehalt hat, das für keinen Vorteil bezahlt wurde ...

Hier ist ein weiteres mögliches Szenario: Lead A ist eng mit jemandem befreundet, der wichtig ist. Er ist zu heiß politisch zu übernehmen,

In beiden Fällen ist es für große Unternehmen bei einem so lang anhaltenden Fehler einfacher, nicht kompetente Personen unter den Teppich zu kehren, ihnen viel zu tun und ihnen eine falsche Energie zu geben, die ihrer jahrelangen "Erfahrung" entspricht, in der sie nicht ZU VIELEN Schaden anrichten können . Leider würden viele Organisationen dies lieber tun, als sich tatsächlich mit den Problemen zu befassen.

Der Grund dafür ist natürlich, dass der Manager in dieser Art von Organisation kurzfristig immer besser dran ist, mit schlechten Talenten auf diese Weise umzugehen, als die langfristigen Probleme anzugehen, die diese Art von Menschen für die Organisation mit sich bringen können.

Obwohl es kurzsichtig und möglicherweise unethisch ist, muss man zugeben, dass es ein bisschen schlauer ist, als viele Entwickler es tatsächlich zu schätzen wissen.

ughh ahhh. Diese Frage erinnert mich an viele Dinge. Zunächst einmal sage ich, dass ich mit einem der Manager an meinem letzten Arbeitsplatz nicht auskommen konnte. Es war kein Persönlichkeitsthema. Es war ein Kommunikationsproblem. Ich sagte XYZ und dieser spezifische Manager würde unterbrechen, was ich als ABC sagte. Ich wäre nicht in der Lage, gut zu kommunizieren, wenn ich nicht länger als ein Jahr mit diesem Manager zusammenarbeiten würde.

Das letzte Wochenende. Ein Typ hat mit mir über Singletons gestritten / nicht gestimmt. Ich sagte, dass sie nicht gut sind und NIEMALS benutzt werden sollten und absolut keinen Grund, sie zu benutzen. Ich habe ihn mit http://www.gmannickg.com/?p=24 verlinkt und mit dem ausführlicheren Artikel, auf den er verweistein paar Tage nach dem Streit. Der Tag eines anderen Programmierers (DudeB) erwähnt, dass er Singletons nur dann verwendet, wenn dies angemessen ist (was ich mit 'never' ergänzt habe). DudeB hat nichts darüber gesagt, aber DudeB hat gesagt, dass DudeB in einem Projekt mit Speicherkonflikten war, weil alle Threads auf den Singleton zugegriffen haben. Nachdem ich dies erwähnt, den Artikel gezeigt und den Streit um das Gedächtnis erwähnt hatte, sagte der Typ, dass wir zustimmen müssen, dass ich nicht zustimme, weil ich nicht gerne über Singletons spreche (aber ich schreibe dieses d'oh).

Fakt ist. Manchmal könnte man sich total irren, wie dieser Typ es ist (vielleicht ist sich jemand in einem Kommentar über Singletons mit mir nicht einig). In meiner Situation mit meinem Manager, der mein leitender Programmierer war, habe ich einfach das getan, was ich ausdrücklich verlangt hatte, und ich habe die Qualität an diesem Arbeitsplatz nie wieder ernst genommen. Ich tat, was ich lieber tat, wenn es mir erlaubt war, aber ich tat immer, was ich wollte, aber wenn ich nicht damit einverstanden war, brachte ich es mindestens einmal zur Sprache.

Ich habe eine völlig andere / kontroverse Meinung dazu.

Oft verlieren die Menschen den Überblick über das Endziel, bei dem es in den meisten Branchen darum geht, Gewinne zu maximieren und Verluste zu minimieren. Ich weiß, dass dies herzlos klingt (daher die negativen Punkte), aber Erfahrung und Scharfsinn sind sehr unwichtig, wenn Sie keine Ergebnisse erzielen wollen.

Die Leute können sich mit extrem indirekten Kleinigkeiten beschäftigen, über die man streiten kann, und die nur einen geringen Einfluss auf die direkten Ergebnisse des Unternehmens haben.

Wenn Sie der Meinung sind, dass Sie mit etwas Recht haben, sollten Sie am besten zeigen, wie dies zu besser messbaren Ergebnissen führt .

Ich würde anfänglich versuchen, es durchzuhalten, am Ende des Tages ist es wahrscheinlich, dass Widerstand gegen den Senior vergeblich ist, zumindest bis Sie mehr Erfahrung und Respekt sammeln. Nutzen Sie dies als Lernerfahrung und in mehr als zwei Jahren, wenn Sie immer noch genauso denken - wechseln Sie zu einem anderen Unternehmen. Dann können Sie eine Kombination aus guten Ideen von Ihnen und Ihren Senioren nutzen, um Ihren neuen Arbeitgeber zu beeindrucken. Natürlich werden Sie möglicherweise einige Gründe für die von Ihnen zu Beginn Ihrer Karriere als falsch empfundenen Entscheidungen erkennen, und irgendwann arbeitet möglicherweise ein Junior-Entwickler für Sie.

[Repost: weil ich hier irgendwie einen zweiten Account angelegt habe]

Aber vor kurzem hat er mich noch einmal angesprochen, meinen Code gesehen und mich gefragt, warum ich ihn nicht auf seinen Vorschlag abgeändert habe .

Sie sollten sich darüber im Klaren sein, ob es sich um Vorschläge oder um Aufträge / Anweisungen / Richtlinien handelt.

Vorschlag = Ich denke, es ist besser, es so zu machen; aber es ist deine Wahl.

Bestellung / etc. = Ich möchte, dass es so gemacht wird; und es ist MEINE Wahl.

Wenn es sich wirklich um einen Vorschlag handelt, tun Sie, was Sie möchten, und lassen Sie Ihren Code stehen. Wenn es ein Befehl ist (und dieser Mentor hat auf diese Weise die Autorität über Sie), tun Sie, was sie sagen.