it-swarm.dev

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

Vor kurzem habe ich meinen ersten Job als Junior-Entwickler begonnen und ich habe einen erfahreneren Entwickler, der mich in diesem kleinen Unternehmen betreut. Es gibt jedoch mehrere Male, in denen er mir Ratschläge zu Dingen gibt, denen ich einfach nicht zustimmen kann (dies widerspricht dem, was ich in mehreren guten Büchern zu dem von Experten verfassten Thema gelernt habe, Fragen, die ich auf einigen Q & A-Websites gestellt habe, stimmen ebenfalls überein mit mir) und angesichts unseres vollen Terminkalenders haben wir wahrscheinlich keine Zeit für lange Debatten.

Bisher habe ich versucht, das Problem zu vermeiden, indem ich ihm zugehört und einen Kontrapunkt angesprochen habe, der auf dem basiert, was ich als aktuelle bewährte Verfahren gelernt habe. Er hebt seinen ursprünglichen Punkt noch einmal an (die meiste Zeit wird er Best Practice sagen, besser zu warten, ging aber nicht weiter), nehme ich eine Notiz (da er keinen neuen Punkt angesprochen hat, um meinem Kontrapunkt entgegenzuwirken), denke darüber nach es und zu Hause recherchieren, aber keine Änderungen vornehmen (ich bin immer noch nicht überzeugt). Aber kürzlich hat er sich noch einmal an mich gewandt, meinen Code gesehen und mich gefragt, warum ich ihn nicht in seinen Vorschlag geä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 ist: Was kann ich tun, um besser beurteilen zu können, ob der Rat eines erfahrenen Entwicklers gut, schlecht oder vielleicht gut, aber im heutigen Kontext veraltet ist? Und wenn es schlecht/veraltet ist, mit welcher Taktik kann ich es trotz seines „Drucks“ nicht auf seine Weise umsetzen und gleichzeitig die Tatsache beibehalten, dass ich ihn als Senior respektiere?

266
learnjourney

Erstens erwarte ich als leitender Entwickler, dass die Junioren, die ich bei Projekten leite, ihre Anliegen direkt und direkt zu mir bringen. Wenn sie nicht einverstanden sind, ist das für mich vollkommen in Ordnung. In einigen Fällen werde ich auf ihre Bedenken eingehen. In den meisten Fällen sind ihre Bedenken beiseite geworfen beiseite mit einer kurzen Erklärung der Argumentation, nicht aus Respektlosigkeit gegenüber dem Entwickler selbst, sondern aus einem anderen Grund wie:

  1. Der Junior verfügt nicht über alle Informationen, 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 entspricht in Bezug auf Software einem Teenager. Ich bin sicher, Sie haben viele großartige Ideen, aber es ist nur 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. Diesen Entwicklern wird es besser gedient, Demut zu erlangen.
  3. Die Entscheidung, etwas Besonderes zu tun, wurde über dem Kopf des Senioren getroffen. Der Senior arbeitet am Ende immer noch für jemand anderen. Möglicherweise gibt es tatsächlich einen besseren Weg, etwas zu tun, einen effizienteren Weg, etwas zu schreiben, oder eine bessere Software/Hardware, um die Arbeit zu erledigen. Das Geschäft bestimmt jedoch immer noch die Entscheidungen. Geschäftsführer, Direktoren, Vizepräsidenten usw. treffen häufig Entscheidungen, die sich auf den Entwicklungsprozess auswirken. Diese liegen 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 im Midstream bis zu dieser Frist kostspielig. Da es sein Hals am Hackklotz ist, ist es oft wichtiger, das Produkt funktionsfähig und pünktlich herauszubringen, 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 jemandem, der höher als Sie ist, verworfen oder verworfen werden kann. Viele von ihnen sind unangenehm, aber sie alle laufen darauf hinaus, dass wir alle Menschen sind und alle Meinungen haben. Seine Meinung ist Ihrer momentan nur zahlenmäßig überlegen.

Unter Berücksichtigung dieser Konzepte sollten Sie Ihre Bedenken weiterhin dem leitenden Entwickler mitteilen. Finden Sie einen anderen erfahrenen Entwickler, der möglicherweise die Lücken ausfüllen kann. Viele leitende Entwickler sind dort, wo sie sind, weil sie besser mit Software umgehen können 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 holen Sie sich seine ehrliche Meinung. 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 besteigen. Selbst wenn Sie an Ihr Herz glauben, dass Ihr Weg richtig ist, haben Sie eine Anweisung erhalten, der Sie folgen müssen, und Sie sollten sie befolgen (es sei denn, dies ist offensichtlich illegal). Wenn Sie Probleme haben, diese Anweisungen zu befolgen, möchten Sie möglicherweise herausfinden, warum dies so ist, da Sie feststellen werden, dass dieses Verhaltensmuster in sehr vielen Unternehmen, die Software jeglicher Art herstellen, weit verbreitet ist.

Ihre beste Option ist es, Ihre Arbeit weiterhin ethisch und professionell zu erledigen. Holen Sie sich die Software, die Sie ausführen sollen, auf vorbildliche Weise und entkommen Sie der Situation, indem Sie aus ihr heraus befördert werden. Wenn keine Werbeaktionen kommen, verfügen Sie über zahlreiche Referenzen und Erfahrungen, um Möglichkeiten in anderen Abteilungen oder Unternehmen zu nutzen.

233
Joel Etherton

Respektieren Sie den Senior-Entwickler. Er steht mehr für den Erfolg des Projekts auf dem Spiel als Sie. Da er die Verantwortung hat, bekommt er auch die Autorität. Wenn er sagt, etwas ändern, dann tu es.

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

Setzen Sie sich zum Schluss zu ihm und erklären Sie ihm die gleiche Frage, die Sie hier gestellt haben. Vielleicht fehlt Ihnen etwas Großes, vielleicht öffnet er sich mehr für Ihre Vorschläge, so oder so, lassen Sie ihn nicht im Dunkeln, wenn Sie denken, dass sein Rat schlecht ist.

35
jzd

In diesem Fall müssen Sie ein Gespräch mit dem leitenden Entwickler führen. Vielleicht weiß er etwas, das Sie nicht über den Code oder die technischen/geschäftlichen Anforderungen wissen. Wenn ja, sollten Sie es lernen.

Tun Sie dies privat. Es könnte als herausfordernde Autorität angesehen werden, und solche Dinge werden am besten eins zu eins erledigt. Zeigen Sie die Bereitschaft, Kompromisse einzugehen und zusammenzuarbeiten, indem Sie sein Dienstalter anerkennen und respektieren, aber beharrlich darauf, Ihre Fragen zu beantworten. Gehen Sie die Situation von einem kollaborativen Rahmen aus, nicht von 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 in der Tat Recht, aber Sie sollten Ihr Bestes tun, um von erfahreneren Menschen zu lernen, damit Sie eine fundiertere Entscheidung treffen können. Ein guter Senior-Entwickler begrüßt die Möglichkeit, auch mit Junior-Entwicklern zusammenzuarbeiten, zu betreuen und zu lernen, und begrüßt es, wenn ihre Ideen auf konstruktive Weise in Frage gestellt werden, weil auch sie wissen, dass sie manchmal falsch liegen.

24
Rein Henrichs

Die Art und Weise, wie Sie oft erzählen, ist ein gesunder Menschenverstand. Beachten Sie, 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, angesichts dessen widerspricht, was seine Besser behaupten (dh Menschen, die älter sind als er; nicht unbedingt in Ihrer Firma). Ich spreche von bekannten "Promi" -Entwicklern, 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 "schlechte Ratschläge" eines leitenden Entwicklers (oder eines Entwicklers): Wenn er nicht weiß, was lose Kopplung ist und warum dies eine gute Sache ist, und Sie aufgefordert werden, den gesamten Code beispielsweise in den Code zu schreiben - Hinter einer ASPX-Datei ist es offensichtlich, dass der leitende Entwickler keine Ahnung hat und sein Rat nicht angehört werden sollte.

Wenn er Ihnen andererseits sagt, wie ein bestimmtes Modul im System funktioniert, ist es oft am besten, so lange wie möglich 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 in Ihrem Bereich 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.

Vollständige Erwartung von Abstimmungen/Meinungsverschiedenheiten für einen extrem voreingenommenen Standpunkt.

18
Wayne Molina

Wenn der Senior Ihnen keine guten Gründe nennen kann, warum er die Best Practices der Branche ignoriert, verschwenden Sie dort keine Zeit. Sie werden niemals vorankommen, weil Sie zu bedrohlich sind, und möchten Sie trotzdem Zeit damit verbringen, einen Stapel schlechten 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.

11
kevin cline

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 und keine Entscheidung treffen konnte, also nutzte ich diese Gelegenheit, um zu lernen, wie man die Arbeit der nächsthöheren Ebene erledigt. Es hat mich befördert. Do solltest das auch machen.

11
HLGEM

Es mag schwierig sein, den Standpunkt des leitenden Entwicklers zu verstehen, und ja, er führt die Dinge möglicherweise auf den falschen Weg. Bei großen Projekten ist jedoch die Konsistenz wichtiger.

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

Wenn es an der Zeit ist, Wartungsarbeiten 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 angesehen.

11
maple_shaft

Als leitender Entwickler würde mich diese Art des passiven aggressiven Nit-Pickings 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 zusammen leben kann.

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

9
rerun

Sie befinden sich in einer nicht so guten Situation, aber wie HLGEM betonte, können Sie diese Positionen in Segen in Verkleidung verwandeln. Ihre Frage ist vielfältig, daher werde ich sie teilweise behandeln.

Ich vermute, er weiß es nicht. Gleichzeitig versucht er mir zu zeigen, dass Arroganz sein kann, so dass ich bei Fragen nicht viel 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 Software-Leads sind - aus einer Entwicklung ) oder einen Mentoring-Standpunkt (es gibt einen Unterschied). Die Erfahrung stammt aus der Bewältigung neuer Herausforderungen, dem Ausprobieren neuer Ideen und dem Erlernen neuer Fähigkeiten, aber die Mehrheit der Programmierer verbringen ihr Leben in einem Flügel der Unternehmenszentrale und arbeiten mit ihrem zuverlässigen Visual Basic an der Payroll-Anwendung und Java Tools, die niemals die Welt in ihrem kalten, grauen Büro rasen sehen.

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.

Tapferkeit und Arroganz können ein Abwehrmechanismus sein, der versucht, Unzulänglichkeiten auszugleichen. Wie gehst du damit um? Nicht Konfrontiere es direkt - wenn dein Vorsprung inkompetent ist und der Chef nicht bereit ist, die Situation zu korrigieren, dann du musst damit leben . Das bedeutet nicht, dass man sich umdreht und stirbt, aber man kann nicht jemanden, der eine gute Führung hat, zwingen.

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, dass er möglicherweise kein guter Programmierer ist. Das heißt nicht, 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 auch das bedeutet nicht, dass er ein Programmierer ist effektives Blei. Richtlinien sind alle gut und schön, aber sie stehen an zweiter Stelle nach der Funktion, Effektivität und Effizienz des Codes.

Was soll ich in einer solchen Situation tun?

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

Haben Sie dem Manager alle diese spezifischen Punkte und spezifische Beispiele zur Sicherung aufgezählt? 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 zu ignorieren, in der Hoffnung, dass sie sich "von selbst" entwickelt.

Hier sind einige Vorschläge.

  1. Scheuern Sie nicht an Ihrer Situation - Feuerprobe, obwohl sie keinen Spaß macht, bringt Ihnen einige wichtige Forschungsfähigkeiten für später in Ihrer Karriere bei.
  2. Schieben Sie Ihren Vorsprung, um sich stärker einzubringen. Tun Sie dies sorgfältig und respektvoll. Drücken Sie weiter und bleiben Sie hartnäckig, bis er nachgibt (dies funktioniert tatsächlich für viele Lebenssituationen).
  3. Wenn Ihr Lead wird nicht sich einmischen, prüfen Sie, ob es andere gibt, die Ihnen helfen könnten. Wenn Sie nicht in einem Sweat-Shop arbeiten, der sich nur mit Melkzeiten befasst, macht es Ihrem Unternehmen nichts aus, wenn ein anderer Entwickler mit mehr Erfahrung Ihnen einige Seile zeigt und Ihren Code überprüft.
  4. Halten Sie Ausschau nach einem neuen Job. Ich würde nicht sagen, dass Sie sich in einer "Muss" -Situation befinden, aber es würde Ihrer Karriere nicht schaden, an einem Ort zu sein, der Ihre Entwicklung als Programmierer ernster nimmt.
9
Jarrod Nettles

Wenn Sie eine bessere Möglichkeit haben, ein bestimmtes Problem zu lösen, einfach DO IT.

Lassen Sie Ihren Code/Ihre Lösung Ihr bestes Argument sein. Ansonsten bleib bei dem, was dir gesagt wurde.

Beispiel

als ich ein Junior war, hatte ich eine Situation, in der ein bestimmter Codeabschnitt nicht der beste war, der es sein konnte. Anstatt nur darüber zu debattieren, habe ich es einfach verbessert DANN zeigte die Ergebnisse meinem Senior. Er akzeptierte es, weil der Code immer König ist.

7
Darknight

Natürlich könnte ich mich als unerfahrener Entwickler irren und sein Weg könnte besser sein. Meine Frage ist also, 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 schlecht gerüstet, um 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
Blrfl

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, wenn Sie versuchen, den Ansatz 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, ständig suboptimale Dinge zu tun. Wenn es dir wirklich nicht gefällt, kannst du tun, was du getan hast, und es ansprechen. Danach ist es der Weg des Chefs oder die Autobahn. Auf der helleren Seite sind Sie von einem Großteil des Risikos schlechter Entscheidungen als Junior isoliert.

7

Wähle deine Schlachten aus. Wenn Sie über eine Arbeitsstunde sprechen, müssen Sie Ihren Code manchmal ändern, bis Sie sich nach oben arbeiten. Wenn Sie das nächste Mal ein großes Projekt erhalten, fragen Sie im Voraus nach einer Möglichkeit, Ihre Ideen zu präsentieren, bevor Sie beginnen. Nehmen Sie sich etwas Zeit und erstellen Sie eine erstaunliche Demo oder einen Prototyp.

6
Jim Crandall

Erschreckenderweise habe ich einfach aufgehört zu fragen. Wenn mir eine andere Option gegeben wird, schweife ich einfach ab und mache es auf seine Weise, füge aber mein eigenes Flair hinzu. Nutzen Sie es als Lernerfahrung, um Ihre Fähigkeiten zu verbessern und gleichzeitig sein Bedürfnis zu stillen, es in der alten Schule zu halten.

Am Ende achtet nicht jeder leitende Entwickler auf neue Methoden. Sie haben manchmal alte Schulmethoden, die für die Sprache, mit der sie vor 20 Jahren angefangen haben, großartig waren, aber in der heutigen Welt als hackig gelten oder "einen schlechten Geruch haben".

Dies mag nach einem schrecklichen Weg klingen, um weiterzumachen, und das ist es auch. Aber ich habe auch viel von meinen Senioren gelernt. Aber das ist wirklich nur meine Meinung. Am Ende muss man bei der 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 deutlich abnimmt.

4
Tim Meers

Vertraue älteren Menschen nicht wegen ihres Dienstalters. Fordern Sie die Autorität so oft wie möglich heraus. Eine zuständige Behörde sollte in der Lage sein, jede Frage überzeugend zu beantworten. Das macht ihn überhaupt zu einer Autorität, nicht wahr?

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

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

3
ThomasW

gute Antworten oben würden hinzufügen, dass eine Antwort wie "Best Practices" oder "wartbarer" eine Gelegenheit ist, etwas zu lernen. Sie sagen: "Können Sie mir ein Beispiel geben, warum dieser Weg am besten ist, damit ich den Unterschied verstehen kann?" oder "In welchen Situationen wäre dieser Weg besser zu warten 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 ... geben Sie ihm einen Cracker, um den Squawkin aufzuhalten, und tun Sie, was Sie für das Beste halten. Bis anders bestellt.

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

2
Steven A. Lowe

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 Domain befindet, können Sie einige wichtige Entscheidungen für Ihren Teil der Anwendung treffen, da Ihr Lead nicht viel über Middleware weiß. Sie haben auch mit Ihrem Manager einen Abschluss darüber, wie die Anwendung ablaufen soll, was die Produktbenutzer wollen und wie Ihr Manager eine Situation angehen möchte, die ihm vom Produktteam präsentiert wird. Sagen Sie mir, wie viele Personen diese Art von Wissen über eine Anwendung erhalten.

Wenn Sie in einem großen Team sind, 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 so etwas im Allgemeinen durch Ihren Lead geht und möglicherweise ist Einige ältere Entwickler in einem Team. Ich bin damit einverstanden, dass Ein-Personen-Projekte schwer zu realisieren sind, aber wenn die andere Seite der Medaille so großartig ist, warum sollte man dann eine Chance verpassen? Erfahren 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.

2
Amar Jarubula

Wenn Sie für eine Sekunde denken, dass das Management nicht versteht, wie fähig Sie WIRKLICH sind, 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 den Job sind. Sie schätzen Ihre Arbeit offensichtlich zu sehr, um zu riskieren, sie an andere weiterzugeben.

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

Sie sind viel schlauer, als die meisten Entwickler ihnen zuschreiben. Ich habe das nicht verstanden, bis ich anfing zu verwalten. 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 im Unternehmen ist inkompetent. Der Manager weiß das und empfiehlt seinem oberen Manager, Lead A zu entlassen. Der obere Manager fragt, warum er vor Jahren nicht behandelt wurde, wenn er so inkompetent ist. Der Manager sieht jetzt schlecht aus, zumal Lead A ein aufgeblähtes Gehalt hat, das ohne Leistung ausgezahlt wurde ...

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

In jedem Fall ist es für große Unternehmen mit einem solchen langfristigen Fehler einfacher, inkompetente Menschen unter den Teppich zu kehren, ihnen viel Arbeit und falsche Macht zu geben, die ihrer jahrelangen "Erfahrung" entspricht, in der sie nicht ZU VIEL Schaden anrichten können . Leider würden viele Organisationen dies dann lieber tun sich tatsächlich mit den Problemen 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 in die Organisation bringen können.

Obwohl es kurzsichtig und möglicherweise unethisch ist, muss man zugeben, dass es etwas schlauer ist, als viele Entwickler es tatsächlich glauben.

1
maple_shaft

All dies hat eine Unterströmung, die meiner Meinung nach klar herausgestellt werden sollte: sei nicht kämpferisch. Bewahren Sie Ihre Beziehung zu ihm. Es ist großartig, seinen Rat mit einem Körnchen Salz zu nehmen und ihn in Büchern und auf solchen Websites 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 bereits den Wunsch geäußert, seinen Standpunkt zu verstehen. Auch wenn Sie sicher sind, dass er falsch liegt und Sie Recht haben, akzeptieren Sie die Möglichkeit des Gegenteils (anscheinend verstehen Sie dies bereits). Versuchen Sie klar zu machen, dass Sie streiten, weil Sie seinen Standpunkt besser verstehen wollen, 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 hier bereits erwähnt, ist er möglicherweise beschäftigt und/oder gestresst.

Es ist auch toll, geduldig zu sein. Behalten Sie eine Liste von Dingen in Ihrem Kopf, die Ihrer Meinung nach anders gemacht werden sollten, und präsentieren Sie sie zum richtigen Zeitpunkt. Stellen Sie sicher, dass Sie neben "Best Practice" auch eine Begründung für den Vorschlag haben. Und achten Sie darauf, die Dinge richtig zu machen und keine Fehler zu machen, damit Sie glaubwürdig sind, wenn Sie später Ihre Argumente vorbringen.

1
Mr. Jefferson

Bisher habe ich versucht, das Problem zu vermeiden, indem ich ihm zugehört und einen Kontrapunkt angesprochen habe. Er hat seinen ursprünglichen Punkt erneut angesprochen (die meiste Zeit wird er Best Practice sagen, besser wartbar, aber einfach nicht weiter gegangen). .. denke zuhause darüber nach, aber ... ich bin immer noch nicht überzeugt. Aber kürzlich hat er ... meinen Code gesehen und mich gefragt, warum ich ihn nicht in seinen Vorschlag geändert habe. Dies ist das 3. Mal in 2-3 Wochen.

(Für die Aktionen leicht bearbeitet.)

Dieser Teil betrifft mich. Eine Möglichkeit 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 Klarstellung bittet. Eine Möglichkeit, dies herauszufinden, besteht darin, ihn zu bitten, zu klären: Wie ist dies eine bessere Praxis als diese? Oder warum ist dies für unseren Code wartbarer als das? 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 Sie gebeten hat, ihn mehrmals zu ändern, und Sie haben es nicht getan. 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 an und Sie weigern sich, die Änderung vorzunehmen. Sie bitten nicht um Klärung, daher geht er davon aus, dass Sie den Grund verstehen und entweder zu faul oder zu hartnäckig sind, um ihn zu ändern - auch keine gute Sache für einen erfahrenen Entwickler, um über Sie nachzudenken. Vertrauen Sie mir, es ist viel besser, Fragen zu stellen, als sich auf diese Weise einen Ruf zu verschaffen.

Ein paar Gedanken:

1/Funktioniert es? Funktioniert seine Art oder nicht? Ist der objektive Grund, warum sein Weg minderwertig wäre?

Mit objektivem Grund meine ich etwas, das ohne Mehrdeutigkeit gemessen werden kann (Leistung, Fehler, Codelänge ...). Wenn seine Lösungen funktionieren und es keine objektive Metrik gibt, die darauf hinweist, dass es sich um eine schlechte Lösung handelt, machen Sie es auf seine Weise. Sein Weg ist besser ... weil er wahrscheinlich konsistenter mit dem Rest der Codebasis ist 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 bei wichtigen Metriken nicht funktioniert oder unterdurchschnittlich abschneidet, implementieren Sie es, vergleichen Sie seine Lösung mit Ihrer Lösung, und teilen Sie ihm mit, dass Sie es versucht haben, aber keine gute Leistung erzielen können (geben Sie die Metriken an), und fragen Sie ihn wenn Sie bei Ihrer Implementierung einen Fehler gemacht haben oder wenn es eine Anforderung gibt, die Ihnen nicht bekannt war

2/Star-Programmierer sagen ... Warum ist das egal? Sie werden berühmte Programmierer finden, die in vielen grundlegenden Themen wie Planung, Design, OOP vs Prozedur, Unit-Test, Ausnahmebehandlung, Quellcodeverwaltung, usw.) im Widerspruch zueinander stehen.

Wenn der einzige Unterschied in der Verarbeitbarkeit zwischen zwei Lösungen darin besteht, wer sie bevorzugt, überspringen Sie sie. Sie könnten von dem mentalen Training profitieren, das erforderlich ist, wenn Sie in einem Paradigma arbeiten, das Sie nicht mögen

1
Sylverdrag

Basierend auf der Idee, dass Sie nur Ratschläge von Menschen erhalten 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
Alexander

Sie werden während Ihrer gesamten Karriere mit solchen Menschen zu tun haben. Und es wird viele geben, mit denen Sie sich nicht einig sind, wie Sie ein Codierungsproblem am besten lösen können. Das Beste, was meiner Meinung nach über die Jahre für mich funktioniert hat, ist, dass sie, wenn sie weiter auf ein Problem drängen, mit ihnen in Kontakt treten und ihnen sagen, dass Sie ihre Lösung unter den verschiedenen möglichen Lösungen in Betracht gezogen haben und dass Sie das Gefühl haben, dass die Lösung Sie sind Sie haben sich für den entschieden, der in dieser Situation der beste Ansatz war.

Wenn Sie sich jetzt jedes Mal gegen ihren Rat entscheiden, müssen Sie gelegentlich nachgeben und von Zeit zu Zeit ihren "Rat" verwenden, um ein paar gekräuselte Federn zu glätten. Solange sie nicht das Gefühl haben, dass Sie ihre Beiträge jedes Mal ablehnen, wird dies einen großen Beitrag zur Wahrung des Friedens zwischen Ihnen leisten.

Bedenken Sie auch, dass sie ein leitender Entwickler sind und länger in dieser Umgebung gearbeitet haben als Sie. Die Codierung im realen Leben passt oft nicht zu Best Practices oder von der Community akzeptierten Standards. Es kann einen Grund geben, warum sie empfohlen haben, etwas auf eine bestimmte Weise zu tun, die sie nicht vollständig artikulieren können. Selbst wenn Sie mit ihnen nicht einverstanden sind, stellen Sie sicher, dass Sie ihren Rat nicht sofort ablehnen, nur weil Sie glauben, dass Ihre Lösung besser ist.

Es geht nur um Balance. Und nicht nur Coding Balance, sondern Team Balance. Viele Projekte sind gescheitert, nicht weil die Entwickler dazu nicht in der Lage waren, sondern weil sie keine Möglichkeit fanden, einvernehmlich zusammenzuarbeiten.

1
BBlake

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

  1. Fragen Sie einen anderen leitenden Entwickler.
  2. Recherchiere selbst.

Bei einem professionellen Termin sollte ich von einem Senior betreut werden. Er wusste einiges, aber ehrlich gesagt nicht so viel, leider wusste er es nicht, also war er sehr zuversichtlich bei seinen Antworten. Ich hatte irgendwie das Gefühl, dass das, was er sagte, falsch war. Ich hatte einige Beweise, als Sachen, die er tat, gegen die Best Practices verstießen, die in der MS-Zertifizierung erwähnt wurden, die ich gemacht habe :-). Danach begann ich 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 großartig, wenn ich mich irren würde, weil ich nur mein Verhalten ändern würde, aber ich war es nicht.

Ich habe in den letzten Jahren etwas bemerkt, fast jedes Unternehmen, in dem ich bin, mit fast jedem Projekt, an dem ich arbeite, mit fast jedem neuen Mitarbeiter (unabhängig von Können/Erfahrung) möchte etwas "anderes" machen.

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

Mein Rat an Sie ist seien Sie nicht dieser Typ.

Eines Tages wirst du ein hochrangiger Kick-Butt-Typ sein, der eingestellt und bezahlt wird, um diese Entscheidungen zu treffen. Wenn dieser Tag kommt, geh dorthin! Erkenne bis zu diesem Tag, was deine Position ist. Ich habe einen Chef, soweit es mich betrifft, ist es meine ganze Aufgabe, meinen Chef glücklich zu machen. Es geht nicht darum, Entscheidungen zu erraten, die außerhalb meiner Gehaltsstufe 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.

1
Rob P.

Die meisten meiner Probleme habe ich sortiert, indem ich sie 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.

Unter dem Gesichtspunkt, Codeüberprüfungen zu erhalten und Hilfe bei Architekturentwürfen zu erhalten, hatte ich selbst bei guten Managern noch nie eine Codeüberprüfung, die über "statische Variablen sollten ein s_ vorangestellt werden" hinausging.

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

1
user23157

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ß, das klingt herzlos (daher die negativen Punkte), aber Erfahrung und Scharfsinn spielen keine Rolle, wenn Sie keine Ergebnisse erzielen wollen.

Menschen können sich mit extrem indirekten Kleinigkeiten beschäftigen, über die sie streiten müssen, und die nur sehr geringe Auswirkungen 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.

0
Adam Gent

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

Aber kürzlich kam er noch einmal auf mich zu, sah meinen Code und fragte mich, warum ich ihn nicht in seinen Vorschlag geändert habe.

Sie sollten sich darüber im Klaren sein, ob es sich um Vorschläge oder Befehle/Anweisungen/Anweisungen/was auch immer 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 wirklich ein Vorschlag ist, machen Sie, was Sie wollen, und lassen Sie Ihren Code stehen. Wenn es ein Befehl ist (und dieser Mentor auf diese Weise Autorität über Sie hat) - tun Sie, was sie sagen.

0
BIBD

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

Am vergangenen Wochenende. Ein Typ hat mit mir über Singletons gestritten/war nicht einverstanden. Ich sagte, sie sind nicht gut und sollten NIEMALS verwendet werden und absolut kein Grund, sie zu verwenden. Ich habe ihn ein paar Tage nach dem Streit mit http://www.gmannickg.com/?p=24 und dem ausführlicheren Artikel, auf den es verweist verlinkt. Der Tag eines anderen Programmierers (DudeB) erwähnt, dass er Singletons nur verwendet, wenn es angebracht ist (was ich mit 'nie' hinzugefügt habe). DudeB hat nichts dazu gesagt, aber DudeB hat gesagt, dass DudeB in einem Projekt war, das Speicherkonflikte hatte, weil alle Threads auf den Singleton zugegriffen haben. Nachdem ich dies erwähnt, den Artikel gezeigt und die Gedächtniskonflikte erwähnt habe, sagte der Typ, mit dem ich gestritten habe, dass wir zustimmen müssen, nicht zuzustimmen, dem ich zugestimmt habe, weil ich nicht gerne über Singletons spreche (aber ich schreibe dieses d'oh)

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

0
user2528

Ich würde zunächst versuchen, es herauszuhalten, am Ende des Tages wird der Widerstand gegen den Senior wahrscheinlich vergeblich sein, zumindest bis Sie mehr Erfahrung und Respekt sammeln. Nutzen Sie dies als Lernerfahrung und in 2+ 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 verwenden, um Ihren neuen Arbeitgeber zu beeindrucken. Natürlich können Sie anfangen, einige der Gründe für das zu erkennen, was Sie früher in Ihrer Karriere als schlechte Entscheidungen empfunden haben, und irgendwann kann es sein, dass ein Junior-Entwickler für Sie arbeitet.

0
Matt Wilko

Es ist in Ordnung, Dinge zu hinterfragen, während sie genau so ausgeführt werden, wie sie gestellt wurden. Ein guter älterer Mensch kann Sie möglicherweise nicht immer von der Richtigkeit überzeugen, Dinge zu tun, bevor sie erledigt werden müssen, aus geschäftlichen Gründen oder auch nur aus Gründen der Aufgabenabhängigkeit. Es sollte sich jedoch Zeit nehmen, Ihr Anliegen anzuerkennen, zuzugeben, wenn sie es nicht angesprochen haben, und es zu einem anderen Zeitpunkt berühren.

0
solidsnack

Bei meinem letzten Job arbeitete ich mit einem anderen Entwickler zusammen, der erst seit Monaten länger dort war als ich. Er hatte einige Erfahrungen in anderen Unternehmen, die an ähnlichen Systemen arbeiteten. Er war sehr ruhig und besonnen. Trotzdem machte er den Eindruck, dass es sich nicht um einen nativen Softwareentwickler handelte. Mit "gebürtig" meine ich, dass er im Laufe der Zeit allmählich in eine Entwicklerposition geriet. Man konnte sehen, dass er in einigen Bereichen gut gelesen war, aber einige Grundlagen fehlten. Es war klar, dass er mit einigen scheinbar einfachen Problemen zu kämpfen hatte. Er konnte die Software dazu bringen, das zu tun, was er wollte, aber er hat es einfach nicht "verstanden".

Persönlich konnte ich nie über die Mentalität "Mein Weg ist besser, weil ich ihn in einem Buch gelesen habe" hinwegkommen, was ich offen zugab, als ich dort arbeitete. In vielerlei Hinsicht hat mich meine vorherige Erfahrung schlecht für die Position fit gemacht. Ich bin mir nicht sicher, ob es daran lag, dass ich "zu fortgeschritten" war oder nur auf einem anderen Weg.

Er und ich stritten uns ständig darüber, wie man Unit-Tests durchführt. Er glaubte an einen sehr White-Box-Ansatz durch Affen-Patching. Ich bevorzuge Black-Box-Tests, die mit Mocks und Abhängigkeitsinjektion unterstützt werden. Ich dachte, sein Ansatz führte zu fragilen Tests, aber ich bin sicher, dass einige meiner Meinungen durch meinen Hintergrund in C # beeinflusst wurden. Er hatte immer in Python gearbeitet. Wer hatte recht? Wir beide? Keiner von uns?

Unternehmen sollten vorsichtiger sein, wenn sie Entwickler in den Senior-Status befördern. Es ist sehr schwierig, an einem Arbeitsplatz genügend Erfahrung zu sammeln. Ein guter leitender Entwickler muss wissen, welche Tools verfügbar sind und wie andere Geschäfte mit ähnlichen Problemen umgehen. Erst als ich meinen ersten Job verließ (wo ich als leitender Entwickler tätig war), lernte ich, wie man moderne Websites erstellt, eine kontinuierliche Bereitstellung ordnungsgemäß durchführt, Quellcodeverwaltungszweige verwaltet, verteilte Dienste erstellt oder NoSQL-Datenbanken verwendet. Sie müssen neue Philosophien, Technologien und Prozesse lernen, um wirklich ein leitender Entwickler zu sein.

Letztendlich gaben ihm die sechs Monate, die er länger als ich dort gewesen war, den Vorteil. Ich beugte mich immer zu seinem Willen und testete seinen Weg. Das machen Profis. Ich war dort, um zu lernen. Trotzdem schlängelte er sich, wie bei den meisten nicht ganz Entwicklern, in eine Führungsposition. In weniger als 3 Wochen hatten wir ein Treffen und ich ging mit einem Karton hinaus. Jetzt bin ich froh, dass ich gefeuert wurde, weil dieser Ort mich zu Tränen gerührt hat.

Es war kein Umfeld der Selbstverbesserung. Leider können Richtlinien, die helfen sollen, die Produktivität beeinträchtigen, wenn sie zu streng befolgt werden. Ich saß stundenlang da und wartete darauf, dass andere meinen Code überprüften, nur um Kommentare zu Zeilenabständen und Namenskonventionen zu erhalten. Als ich anfing, Vorschläge zu machen, die der Politik widersprachen ... wurde ich plötzlich als Rebell, Neinsager und Anstifter bezeichnet.

0
Travis Parks

So wie ich es verstehe, ist Ihr Entwickler-Lead eigentlich nur da, um Sie im Auge zu behalten, "weil es unverantwortlich wäre, einen Entwickler ganz alleine zu lassen". Aber er hat keine Ahnung, wie er Ihre Arbeit tatsächlich beurteilen soll.

Hast du mit ihm darüber gesprochen? Vielleicht ist er es leid, das auch tun zu müssen.

Wenn Sie Rat und Hilfe benötigen, wäre es nicht eine bessere und produktivere Lösung, wenn stattdessen ein Teamkollege mit Ihnen zusammenarbeitet?

0
guillaume31