Hintergrund: Ich bin frisch gebackener Hochschulabsolvent und Softwareentwickler. Das Unternehmen, in dem ich arbeite, hat ein relativ kleines Team mit 8 Mitarbeitern. Ich bin der Neuste im Team und seit 10 Monaten hier.
Ich verstehe mich gut mit einem der Senior-Entwickler, wenn ich über etwas anderes als Code-Besonderheiten spreche. Ich muss häufig zu ihm gehen, um Unterstützung zu erhalten, da er sich mit .NET recht gut auskennt. Wenn wir über die verschiedenen Möglichkeiten sprechen, ein technisches Problem zu lösen, mit dem ich Probleme habe, gibt es spürbare Konflikte und Spannungen. Das liegt daran, dass wir beide unterschiedliche Vorgehensweisen und unterschiedliche grundlegende Denkprozesse haben. Nur ein Beispiel (von vielen), wo wir anders denken, ist, dass ich mit mehr Fokus auf objektorientiertes Design trainiert wurde, indem ich Vererbung verwendete, während er Daten so sieht, wie sie in eine Tabelle passen würden, und sogar fragt, warum Sie Vererbung im Vergleich zu nur a verwenden würden Einfacher Verweis auf ein übergeordnetes Objekt.
Immer wenn ich versuche, höflich etwas zu sagen wie: „Ich verstehe, was du meinst, aber ich denke immer noch, dass dies der bessere Ansatz ist, weil xy z“, sieht er meinen Standpunkt nicht und wird sogar ein bisschen eindringlicher als die Methode er empfiehlt, ist besser und dies führt zu erhöhter Spannung. Ich verstehe, woher er kommt, und ich kann die Vorteile darin sehen, es auf seine Art zu tun, aber ich sehe mehr Vorteile darin, das Problem auf meine Art zu lösen.
Meine Frage ist also, wie ich mit ihm so umgehe, dass sich meine Beziehung zu ihm verbessert, oder ob es der beste Ansatz ist, einfach etwas Abstand zwischen ihm und mir zu erzwingen, wenn es um technische Gespräche geht, und ihn dadurch zu hemmen wertvoller Mentor?
HINWEIS: Wie kann ich Kommunikationslücken mit einem Kollegen verringern, der einen anderen Arbeitsstil hat? <-- Eine ähnliche Frage, aber mehr zur Kommunikation, die kein Thema ist.
EDIT: Diese Person ist nicht mein Vorgesetzter, er ist einfach ein erfahrenerer Kollege, mein Chef (ich habe 2...), der für meine Arbeit zuständig ist, arbeitet und denkt genauso wie ich, wenn es um die Lösung von Problemen geht . Das bedeutet, dass die Implementierung einer Lösung in der Art und Weise, wie dieser andere Entwickler vorschlägt, dazu führen würde, dass ich die gleiche Diskussion mit meinem Chef führen müsste, aber ich würde für eine Implementierung argumentieren, an die ich nicht wirklich glaube. Mein Chef kennt .NET nicht sehr gut, aber er ist nicht in der Lage, mir bei den technischen / Implementierungsfragen zu helfen, die ich habe.
BEARBEITEN 2: Ich habe die Frage geändert und viele technische Details gemäß dem Vorschlag in den Kommentaren entfernt.
Ihre Entschlossenheit, OOP zu verwenden, wo dies möglicherweise keine Rolle spielt, und seine Entschlossenheit, eine reale Datenbank zu verwenden, in der sie möglicherweise keine Rolle spielt, sind Flipseiten derselben Medaille. Sie werden besser mit ihm auskommen, wenn Sie sich daran erinnern, dass dies ein Handwerk ist, keine Wissenschaft, und zwei Entwickler werden sich häufig dem gleichen Problem aus verschiedenen Richtungen nähern, ohne dass sich entweder irren. Die Auswahl der besten Lösung hängt davon ab, wie es verwendet werden soll, und wie viel Mühe es in die eine oder andere Weise dauert ... und das letzte variiert von Individuum zu Individuum. Und manchmal ist die richtige Antwort nicht diejenige, die technisch am besten ist oder die Sie bevorzugen, aber die, die einfacher zu pflegen ist.
Anstatt sich mit dem Recht verwickeln zu lassen, konzentrieren Sie sich darauf, zu lernen, warum ein Vorschlag gemacht wird und was die Kompromisse sind.
Und wenn überhaupt, kämpfen Sie nicht um Dinge, die keine Rolle spielen. Wer hat rechts von Bedeutung als die Arbeit zu erledigen?
Ich sehe deinen Standpunkt, aber ich denke immer noch, dass dies der bessere Ansatz ist
"Besser" in diesem Satz ist eine rein fiktive Messung, zumindest für ihn. Sie (beide, als Team) haben die Standards von "Gut" nie festgelegt, so dass die "bessere" keine gemeinsame Basis hat.
Ihnen wurde beigebracht, dass OOP "besser" ist. Aber wenn es eine gute Ausbildung war, wurde Ihnen auch beigebracht, warum . Machen Sie also einen Fall. Was würde Ihre Lösung bieten, die sein nicht bieten würde ? Was könnte mit Ihrer Software gemacht werden, das konnte nicht mit seinem gemacht werden?
Wenn Sie ihm einen wahrscheinlichen Business Case präsentieren, den Ihre Lösung in kürzerer Zeit oder für weniger Geld erledigen würde, dann wird er sehen, dass es tatsächlich „besser“ ist. Wenn Sie kein Beispiel finden, warum Ihr Ansatz "besser" ist, ist er es vielleicht nicht. OOP und Vererbung sind Werkzeuge, um Probleme zu lösen. Vielleicht ist dies nicht das richtige Problem für Ihr Toolset? Es könnte auch sein, dass Sie ein zweites (und drittes und viertes ...) Toolset benötigen.
Ich möchte Ihnen vorschlagen, das Gespräch mit ihm in einer positiven Einstellung zu beginnen – z. B. könnte ich großartige Dinge von diesem Senior-Entwickler lernen usw. Warum möchten Sie nicht wissen, warum seine Methode besser ist als Ihre, indem Sie mehrere Fragen stellen? auf seine Methode.
Ich denke, es wäre gut, sich hier einige relevante "Dale Carnegie-Regeln" zu merken:
1) Kritisieren, verurteilen oder beschweren Sie sich nicht (ohne einen richtigen Ansatz zu versuchen – ich glaube, der oben genannte, den ich erwähnt habe, ist einer davon);
2) Wecken Sie in der anderen Person einen eifrigen Wunsch (lassen Sie ihn glauben, dass er auch zu Ihrem Projekt/Ihrer Lösung beiträgt).
Wenn Ihr OOP-Ansatz besser ist, stellen Sie einige Anwendungsfälle in Ihrer Situation vor, in denen der OOP-Ansatz besser funktioniert als der Datenbank-/Tabellenansatz (der wie Delegierung aussieht). Wenn die Anwendungsfälle wichtig genug sind, kann dies Ihrem Mentor helfen, zu Ihrer Schlussfolgerung zu gelangen.
Da er der Mentor ist, sollten Sie seinen Ansatz möglicherweise auch von Anfang bis Ende ausprobieren. Sie können lernen, dass sein Weg besser ist oder dass Ihr Weg besser ist oder dass beide Wege nur zwei verschiedene Wege sind, um dasselbe Problem zu lösen. Aber Ihr Wissen wird erfahrungsbasiert sein. Und wenn Sie beide Wege lernen, können Sie beim nächsten Mal, wenn Sie ihn um Hilfe bitten, seinen bevorzugten Ansatz problemlos in Ihren bevorzugten Ansatz übersetzen.
Ich hatte eine Situation, in der ich mithilfe der Ruby Enumerable-Bibliothek mit kaskadierenden Zuordnungs-/Reduce-Blöcken einen Codeblock geschrieben habe, um eine schmerzhafte Datenverarbeitungsaufgabe für einen Datensatz auszuführen. Mein Chef schätzte die Vorteile der Verwendung von Cascading Map/Reduce (einem funktionaleren Programmierstil) nicht und beschwerte sich, dass der Code schwer zu lesen sei. Ich entgegnete, dass ich wechseln könnte, wenn er den Code prägnanter und mit einem zwingenderen Codierungsstil schreiben könnte. (Ich habe es nur gesagt, weil ich wusste, dass frühere Versuche mit ähnlichen Problemen das dreifache Codevolumen hatten und es spröde war). Mein Ansatz hat sich bisher bewährt, weil er funktioniert und weil er noch keinen Code produziert hat, um dasselbe Problem im imperativen Programmierstil zu lösen. In diesem Fall habe ich die beiden unterschiedlichen Methoden ausprobiert, sodass ich sowohl die Unterschiede artikulieren als auch den Code schreiben konnte.
Myles
Brandin
Another one of the conflicts was where he was suggesting creating a database to store data on disk for an ad-hoc solution that would only be used by me<-- Ich verstehe diesen Konflikt nicht. Wenn die Lösung nur von Ihnen verwendet werden soll, warum ist dann der Input Ihres Vorgesetzten wichtig? OTOH, wenn es sich um ein Produkt handelt, das von anderen verwendet werden soll, dann kann der Beitrag Ihres Vorgesetzten nicht ignoriert werden, selbst wenn er "falsch" ist.Adrian773
Adrian773
Brandin
You: I was thinking of using X for this. What do you think? Him: Hmm... I would definitely use Y for this.. Dies ist kein "Konflikt", es sei denn, Sie versuchen, den Punkt zu argumentieren (ohne Grund). Es sind nur zwei verschiedene Meinungen. Wenn du X machen willst, tu es einfach. Du musst es ihm nicht einmal sagen.Adrian773
Me: I was thinking of using X for this. Have you already done X and if so, what library did you use? Him: I haven't done X, what is this for? Me: Its for Y. Him: Oh, Z would be a better solution to Y. Me: Really? That wouldn't have A or B and X has C and D. Wouldn't that make X a much better solution? Him: Nah, A and B are negligible.Ich könnte von hier aus weitermachen, aber es wäre ziemlich dasselbe, bis es angespannt und schwer für mich ist, ihn einfach zu ignorieren und wegzugehen, ohne unhöflich zu sein.Brandin