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


266

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?


26
Sie lernen mehr aus Fehlern als aus Erfolgen.
StuperUser

45
Können Sie ein Beispiel für eine der Fragen nennen, über die Sie zwei nicht einig sind? Ich weiß, dass dies eher eine theoretische Frage ist, und Sie möchten wahrscheinlich technische Debatten vermeiden, aber es wäre interessant zu hören, was die Meinungsverschiedenheit beendet.
Adam Rackis

140
Ich sehe eine rote Fahne in diesem Beitrag. Sie mussten dreimal aufgefordert werden, etwas zu tun. Einmal sollte reichen. Wenn Sie nichts tun möchten, müssen Sie Ihren Mentor davon überzeugen, dass dies nicht erforderlich ist. Wenn Sie das nicht können, dann halten Sie entweder Ihre Nase und tun Sie es oder finden Sie einen neuen Job.
PeterAllenWebb

6
@peterallenweb, in der Tat ist es schlecht, dreimal gefragt zu werden, unabhängig von der Qualität der Beratung. Ich denke, aus den Kommentaren hier muss ich eine Menge lernen, um in verschiedenen Teams zu arbeiten. :)
learnjourney

33
Zusätzlich zu dem, was Peter sagte: Betrachten Sie seine Sichtweise: Sie bitten den Neuen, etwas zu tun, ein technisches Gespräch zu führen, keine weiteren Einwände zu erheben, und dann - eine Woche später - stellen Sie fest, dass er Ihre Anfrage einfach ignoriert hat. Und dies ist nicht das erste Mal, dass dies passiert ist. (Machen Sie sich keine allzu großen Sorgen - Sie sind sicherlich nicht die erste Person, die direkt vom College in diese Falle gerät. Solange Sie sich dieser Probleme bewusst sind und daran arbeiten, werden Sie in Ordnung sein.)
Martin,

Antworten:


233

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.


47
@ Joel Gute Antwort, aber Vorsicht vor "beiseite werfen" Bedenken. Bedenken sollten immer anerkannt werden, auch wenn sie ungültig sind, selbst wenn die beste Antwort lautet: "Ich verstehe Ihre Bedenken, aber jetzt müssen wir X wegen Y tun." Die flüchtige Abweisung ernsthafter Ideen ist ein Moralkiller und kann schließlich sogar die gesündesten Kulturen zerstören.
Rein Henrichs

42
@Joel: Viele gute Punkte, aber das ist ein bisschen herablassend: "Das ist in Bezug auf Software das Äquivalent dazu, ein Teenager zu sein." Den Respekt, den ein Senior von den Junior-Entwicklern verdient, gewinnt er, wenn er konsequent gute Entscheidungen trifft - nicht nur aufgrund des Alters oder des Dienstalters.
Neil G

26
Es ist nicht annähernd zu beantworten, woher Sie wissen, ob ein leitender Entwickler "gut" ist oder nicht. Die hier angegebene Antwort scheint zu lauten: "Es spielt keine Rolle, nur das zu tun, was er sagt." Ich sage nicht, dass das ein falscher Rat ist. Ich sage nur, dass es die Frage nicht beantwortet. Für das, was es wert ist, denke ich, ist die einzige richtige Antwort, dass Sie wissen, ob er in 5 Jahren, wenn Sie ein Senior sind, etwas Gutes hat.
Kevin

2
@ Kevin: Ich kann mich mit diesem Kommentar nicht auseinandersetzen, und ich kann einem Junior-Entwickler auf keinen Fall eine Methode empfehlen, um einen Weg zu finden, um diese spezielle Frage zu beantworten. Oft können Senioren nicht genau aufeinander antworten. Meine Antwort war ehrlich auf einige der anderen Aspekte der OP-Frage ausgerichtet, die mir wichtiger erschienen als die Frage, wie man einen beschissenen Senior-Entwickler ausfindig macht.
Joel Etherton

11
Offenbar fehlt der Antwort die Demut, von der Sie sprechen. Junge Leute denken oft, dass sie alles wissen, aber teilen ältere Leute nicht dasselbe Laster? Dies ist in unserer Branche übertrieben - ein großer Teil unseres Wissens wird in einigen Jahren weniger relevant sein. (Beispiel aus der Praxis - Ich habe einen Mentor in einem mittleren Projekt, der sagte, wir sollten "einige Schaltflächen erstellen und SQL schreiben, um Zeit zu sparen". Er war ziemlich beeindruckt, als ich ihm LINQ to Entity und asp.net zeigte Seite ohne Code )
Kobi

35

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.


29
OP - Sie sind beide Profis, auch wenn Sie weniger Erfahrung haben. Besprechen Sie mit ihm professionell die Dinge, die Sie in Frage stellen. Wenn er nicht bereit ist, über das Warum seiner Anweisungen zu sprechen , ist er kein großer Mentor.
DaveE

10
+1 Für "Er ist mehr für den Erfolg des Projekts als Sie". Wie wahr es ist. Ich weiß, dass Sie als Nachwuchsentwickler nicht zu schätzen wissen, wie viel Glück Sie haben, wenn Sie nicht so gestresst sind, weil ich das als Nachwuchsentwickler sicher nicht getan habe. Jetzt runter von meinem Rasen!
maple_shaft

1
Ich würde auch vorschlagen, dass Sie, wenn Sie seinen Vorschlägen folgen, ein Dokument Ihrer Bedenken in Bezug auf die Änderung aufbewahren. Wenn diese später unterbrochen wird, können Sie möglicherweise darauf hinweisen, um zu zeigen, dass Sie den Fehler vorhergesagt haben.
Daenyth

4
@ DaveE: Hört sich so an, als hätten sie die Diskussion bereits geführt und das OP hatte einfach nicht genug Kontext, um derzeit die Weisheit der Senioren zu verstehen. Manchmal kann man nur so viel erklären, dass der Rest aus Erfahrung kommen muss.
Martin York

2
@ Niphra: Möglich. Aber ohne genauere Informationen neige ich eher dazu zu glauben, dass dies nur ein naiver Lernender ist, der weniger weiß, als er denkt. Die meisten Senioren wissen tatsächlich, was sie tun (Sie werden kein Senior Engineer, wenn Sie dumm sind, gehen Sie stattdessen ins Management).
Martin York

24

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.


4
+1 für ein Gespräch. Der leitende Entwickler ist möglicherweise besser in der Lage (und verantwortlich), verschiedene Bedenken auszugleichen, sollte jedoch in der Lage sein, seine Gründe zu erläutern. Sich Junioren zu erklären, damit sie lernen können, ist ein großer Teil des Seniorseins. Und wenn Sie als Junior nicht das Gefühl haben, etwas zu lernen, ist es vielleicht an der Zeit, den Job zu wechseln.
Jaap

+1 für das beste Einzelgespräch. Die Zeit für Meinungsverschiedenheiten ist hinter verschlossenen Türen. Wenn sich die Tür öffnet und die Diskussion beendet ist, sollte es keine Streitereien geben, keine Untergrabungen, kein Gejammer. Öffnen Sie die Tür erst, wenn Sie an diesem Punkt angelangt sind. Wenn Sie immer noch nicht einverstanden sind, teilen Sie dem Senior mit, dass Sie beabsichtigen, dies zu seinem Vorgesetzten zu machen.
Michael Riley - AKA Gunny

18

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.


Ich muss zugeben, dass ich eigentlich schockiert bin, dass ich (bis jetzt) ​​sieben positive Stimmen und keine negativen Stimmen habe. Ich hätte gedacht, dass meine Einstellung / pessimistische Sichtweise / der Ranty-Ton nicht gut zu den Leuten gepasst hätte :)
Wayne Molina

Auf Slashdot war es eine bewährte Technik, zu verkünden, dass man damit rechnete, dass man abgemodert wird.
Carson63000

Ich werde es öfter versuchen müssen j / k :)
Wayne Molina

11

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.


11

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.


9
Es ist möglicherweise nicht der beste Weg, eine Diskussion zu eröffnen, wenn man blindlings nur sagt, dass wir branchenweit bewährte Verfahren anwenden müssen. Es könnte sehr gute Gründe geben, etwas anderes zu tun als die meisten anderen.

7
Ich denke, das kommt einer tatsächlichen Antwort noch am nächsten. Ein leitender Entwickler sollte überzeugende Gründe dafür liefern können, dass die von ihm empfohlenen Methoden angemessen sind. Sie werden sich nicht verbessern können, wenn Sie von jemandem betreut werden, der dies nicht kann. Wenn Sie sich in Ihrer dritten Firma befinden und alle älteren Entwickler Ihrer Meinung nach Idioten waren, ist es möglicherweise an der Zeit, einen genaueren Blick in den Spiegel zu werfen.
PeterAllenWebb

2
@PeterAllenWebb, "sollte in der Lage sein", ja, aber Sie möchten nicht unbedingt Stunde für Stunde ausführlich darüber streiten, warum Sie eine bestimmte Praxis als schlecht für Sie empfunden haben. Gelegentlich kann "Warum?" Mit "Weil!" Beantwortet werden.

@ Thorbjørn Ravn Andersen: Dem stimme ich zu, solange es gelegentlich vorkommt.
PeterAllenWebb

11

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.


Ich schätze Ihr Denken, aber ich habe Angst vor der Zukunft und bin spekulativ, da es schwierigere Situationen geben kann, in denen das Posten in Foren möglicherweise nicht hilft. Was sollte ich dann tun?
developer123

4
Stöbere in den Büchern und lerne ausführlich. Das Internet ist nicht der einzige Weg, um zu lernen. Treten Sie einer lokalen Entwicklergruppe bei und knüpfen Sie Kontakte zu älteren Menschen, die Sie als Mentor einsetzen können.
HLGEM

das ist gut
developer123

9

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.


6
Als Nachwuchsentwickler würde mich diese Art von Diktatur verrückt machen. Ich habe abgestimmt, sorry.
kizzx2

9

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.

Vielen Dank, Ihre Punkte sind wirklich nett und nachdenklich. Upvote für dich.
developer123

Danke, ich habe deine Antwort ausgewählt, da sie das Beste kombiniert.
developer123

7

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.


11
@maple_shaft: Was für ein Team bist du, wenn Code (und jeder, der ihn pflegt) leiden muss, um die Gefühle der Senior-Entwickler zu schützen?
Jaap

1
@Jaap, Zunächst spreche ich von einem Technologie- oder Projektleiter, dies muss nicht unbedingt ein leitender Entwickler sein. Zweitens geht es nicht um ihre Gefühle, sondern darum, sich als Gruppe einem gemeinsamen Ziel zu nähern. Der Anführer sollte eine gewisse Kontrolle über seine Gruppe haben, unabhängig davon, ob er sich irrt. Der Anführer ist derjenige, der die Verantwortung für fehlerhaften Code übernimmt, der gelöscht wird, unvollständige Funktionen und versäumte Fristen. Wenn er also ein Dummkopf ist, wird er leiden. Wenn die Firma nicht erkennt, dass er ein Dummkopf ist, leidet die Firma.
maple_shaft

2
Wenn er bereits angewiesen wurde, es zu ändern, ist die Codeüberprüfung fehlgeschlagen. Der Versuch, es erneut einzureichen, bedeutet, dass ihm mitgeteilt wird, dass dies bereits fehlgeschlagen ist.
Martin York

2
@darknight, vorausgesetzt, dies ist kein winziges Problem, ein Paradigmenwechsel auf einer vorhandenen Codebasis könnte schwerwiegende Folgen haben. Was mir bei solchen Debatten einfällt, ist die Datenbankstruktur. Änderungen wie diese werden mit Sicherheit nicht gewürdigt.
Morgan Herlocker

1
Dies gilt nur für sehr kleine Arbeitseinheiten. Angenommen, Sie haben zwei Wochen lang gearbeitet, und der Kodex wird abgelehnt. Wie erhalten Sie die Mittel für diese zwei Wochen?

7

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.


7

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.


6

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.


4

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.


3

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?


5
Die meisten Manager werden nicht viel Geduld für einen Junior-Entwickler haben, der alles in Frage stellt. Wenn dies bei Ihnen der Fall ist, opfern Sie ein Huhn zu Ehren von Cthulhu, denn Sie haben einen großartigen Chef gefunden! Andernfalls sollten Sie sich darauf gefasst machen, so lange zu stöbern, bis Sie eine finden.

2

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.


2

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.


Vielen Dank an HLGEM und Jarrod, die auf die positiven Aspekte hingewiesen haben.
developer123

1

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.


1

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.


5
Es gibt so gut wie keinen triftigen Grund, Best Practices der Branche zu ignorieren, außer Unwissenheit und / oder dem Unwillen, es richtig zu machen. Sie sind aus einem bestimmten Grund "beste" Praktiken, und die Leute, die sie entwickeln, sind zehnmal schlauer und sogar älter als der leitende Entwickler, der sie ignoriert oder sich dessen nicht bewusst ist.
Wayne Molina

@ Wayne M: Gut gesagt.
Jim G.

6
@ Wayne, Sie müssen noch verstehen, warum es sich um Best Practices handelt. Wenn Sie blind sagen, "das ist die beste Vorgehensweise, müssen wir es tun!" ohne zu wissen warum, bist du selbst nicht besser.

Ich würde sagen, dass Wayne in seiner Antwort auf Andersens Gegenargument genügend Platz gelassen hat.
C Johnson

@ Thorbjørn Ravn Andersen, @learnjourney - Von allen Kommentaren und Antworten ist Thorbjørns Kommentar wahrscheinlich der kritischste und relevanteste Ratschlag. Sie müssen die Probleme verstehen, die eine bestimmte bewährte Methode zu verhindern oder zu lösen versucht hat. Andernfalls werden Sie nie erfahren, ob diese Probleme weiterhin bestehen. Kurz gesagt, Sie müssen verstehen, warum dies eine bewährte Methode ist. So schlagen Sie Alternativen vor: indem Sie die Probleme beleuchten, die durch die bewährte Methode gelöst wurden. Wie der Merowinger aus der Matrix sagte: "Ohne" Warum "hast du nichts."
Thomas

1

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.


17
-1: Meiner Meinung nach habe ich einen Chef. Meine ganze Aufgabe ist es, meinen Chef glücklich zu machen. Es geht nicht darum, Entscheidungen zu überdenken, die außerhalb meiner Gehaltsklasse getroffen wurden. : Du wirst nie für mich arbeiten. Ich stelle keine "Yes Men" ein. Ich möchte, dass meine direkten Berichte konstruktive Kritik anbringen, wenn ich im Begriff bin, eine suboptimale Entscheidung zu treffen. Wenn ich ihre Meinung nicht gewürdigt hätte, hätte ich sie gar nicht erst angeheuert.
Jim G.

7
Ich bin mit diesem Gefühl nicht einverstanden. Wenn Sie befördert werden möchten, sollten Sie zunächst zeigen, dass Sie in der Lage und bereit sind, die Verantwortung für eine leitende Position zu übernehmen. In dieser Hinsicht ist es für Ihre langfristige Karriere nicht gut, den Kopf gesenkt zu halten. Zweitens glaube ich nicht an die Arbeitsweise, die über meinem Gehaltsniveau liegt. Jeder ist da, um das Unternehmen erfolgreich zu machen (wenn dies nicht der Fall ist, haben Sie keinen Job mehr). Wenn Sie also eine bessere Möglichkeit sehen, etwas zu tun, das über Ihrer Gehaltsstufe liegt oder nicht, sollten Sie darauf hinweisen. Manchmal kann ein neuer Mitarbeiter gute Vorschläge machen, weil er eine neue Perspektive hat.
Cercerilla

6
Ich muss @Jim G. zustimmen. Die Einstellung, ein "Schmied" zu sein, ist das Schlimmste, was man tun kann. Zu denken, dass Ihr Manager immer Recht hat, ist eine schreckliche Sache, weil sie oft nicht Recht haben. Stimmen Sie auch @CodeninjaTim zu - ein neuer Mitarbeiter hat oft bessere Vorschläge, weil er nicht die gleiche Sichtweise hat wie die Langzeit-Mitarbeiter. Daher ist es weniger wahrscheinlich, dass er nur dem "Status Quo" folgt
Wayne Molina

4
@ Jim G: Es hört sich so an, als hätte der OP bereits seine Besorgnis geweckt. "Dies ist das dritte Mal in zwei bis drei Wochen." - Ich kann mir nicht vorstellen, dass Sie jemanden einstellen möchten, der, nachdem er seine Meinung geäußert und erklärt hat, dass A besser ist als B (auch wenn er anderer Meinung ist), die Änderung ablehnt. Zu diesem Zeitpunkt arbeitet er wirklich nicht für Sie.
Rob P.

3
@ Wayne M - Ich befürworte nicht, dass unsere Manager immer Recht haben. Ich schlug vor, seine Bedenken angemessen zu äußern. Nachdem OP innerhalb weniger Wochen drei Mal angewiesen wurde, etwas zu tun, wird es nicht richtig gehandhabt. Sagen Sie auf jeden Fall Ihre Bedenken, aber stellen Sie fest, dass Sie BESCHÄFTIGT sind (es sei denn, Sie sind es nicht - dann ignorieren Sie dies). Sie haben zugestimmt, für jemand anderen zu arbeiten, um eine gewisse Entschädigung zu erhalten. Die Tatsache , dass Sie haben einen Chef impliziert eine Erwartung , dass Sie tun , wie Sie gesagt, im Rahmen des Zumutbaren. Richtig oder falsch, dafür haben Sie sich als Mitarbeiter angemeldet
Rob P.

1

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.


1

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.


Ich habe um Klarstellung gebeten, aber die Antwort, die ich immer erhielt, ist "es ist eine bessere Praxis" oder so, bevor er wieder seine eigenen Sachen machen konnte. Meiner Meinung nach ist es eine Sache, zu sagen, dass es eine gute oder bessere Praxis ist, aber ich wollte wissen, warum es besser ist, was er mir nicht erklären konnte, aber darauf zu bestehen ist besser und als Senior Ich sollte ihm vertrauen. Trotzdem ist es schlecht von mir, mich nicht zu ändern, obwohl ich dreimal danach gefragt wurde.
learnjourney

@learnjourney: Ich stimme zu, dass es wahrscheinlich ein Problem gibt, wenn Sie nach dem Grund fragen und keine Antworten erhalten. Ich würde Ihnen trotzdem empfehlen, sich darüber im Klaren zu bleiben, wie es von der anderen Seite aussehen könnte. Wenn Ihnen dieser leitende Entwickler jedoch nicht weiterhelfen kann, suchen Sie nach einem anderen und stellen Sie das Problem mit den grundlegenden ", sagte er, <Grund>. können Sie erklären, wie das hier zutrifft? "und keine Beschuldigung. Wenn das nicht funktioniert, schaue ich mir einige der anderen Antworten an, die besagen, dass die Änderung trotzdem vorgenommen werden soll, halte aber deine Version und die Gründe bereit. Stellen Sie sicher, dass Sie so oder so davon lernen.
Caleb Huitt - cjhuitt

1

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


1

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.


1

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.


Ja, das ist das einzige Optimistische, was ich in meiner Situation sehe.
developer123

1

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.


Vielen Dank für die Antwort und die Einbeziehung der Managementseite in das Denken und ihre Standpunkte. Upvote für dich.
developer123

0

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.


1
Re: „Vielleicht wird jemand nicht einverstanden mit mir über Singletons in einem Kommentar“ - Ich bin nicht einverstanden mit Ihnen; o) Aber läßt nicht zustimmen zustimmen
JW01

0

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 .


-1: So lächerlich. // Der Kern Ihrer "kontroversen" Meinung liegt in der Tatsache, dass das OP in Kleinigkeiten oder Kleinigkeiten verwickelt ist. Das weißt du nicht! Nehmen Sie die Frage zum Nennwert.
Jim G.

Die meisten Programme werden von Jim G. erstellt. Und aus Erfahrung (ich bin ein leitender Entwickler) gibt es noch viele andere BS, die mit Recht zu tun haben . Es gibt fast immer ein größeres Bild. Und die Leute weiter oben reagieren auf ein größeres Bild (siehe sein Update), nicht auf "aber mein Design ist mehr entkoppelt". Da das OP kein Beispiel lieferte, musste ich mir ein paar Freiheiten nehmen.
Adam Gent

0

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.


5
-1: Warum mehr als 2 Jahre für ein Senior n00b arbeiten?
Jim G.

@ Jim - Ein Jobwechsel nach 6 Monaten sieht in Ihrem Lebenslauf nicht gut aus. Wenn Sie an einen anderen Ort ziehen und der Senior ist noch schlimmer, ist die Auswirkung auf Ihren Lebenslauf exponentiell schlecht! Außerdem lernst du vielleicht zu erkennen, dass nicht alles, was sie sagten, falsch war oder zumindest einen Grund dafür gab.
Matt Wilko

1
@ Jim - Während ich in der Praxis zustimme, hat Matt einen Punkt; Leute sind dumm und ständiges Job-Hopping, das versucht, ein angemessenes Umfeld zu finden, kann dich verletzen (ich kann aus Erfahrung in diesem Fall sprechen). Es hängt davon ab, was genau der Rat ist, ob es einfach nicht optimal ist (z. B. wir können kein TDD durchführen oder einen IoC-Container verwenden) oder völlig falsch (z. B. ich weiß nicht, was eine Schnittstelle ist oder warum Sie jemals eine in verwenden würden Programmierung). Ersteres ist in Ordnung, um "durchzuhalten", letzteres ist der Ort, an dem du schreiend davonläufst, weil der Senior ein Idiot ist (ich hoffe, ich habe die Begriffe richtig verstanden ... sie verwirren mich immer)
Wayne Molina

0

[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.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.