Gestresst von einem Kollegen, der generell gegen meine Arbeitsweise ist

Für andere mag das nichts bedeuten, aber ich persönlich brauche Hilfe.

Ich habe kürzlich mit diesem Kollegen zusammengearbeitet und sie sind der Hauptgrund, warum ich darüber nachdenke, meinen Job zu kündigen. Boss sagt mir, dass sie und mein Arbeitsstil ganz anders sind.

Sie entwickelten ein CMS (Content Management System), bevor ich durch ihre Bitte, die Last zu teilen, beteiligt wurde. Es wurde mit Nuxt gebaut, beginnend mit einer Kopie aus einem anderen Projekt. Das erste Problem, das mir bei dieser Arbeit aufgefallen ist, war, dass es trotz der Verwendung von Nuxt( Vue.js) unnötigerweise verwendet wurde jQuery(Elemente ausblenden, Klassen hinzufügen usw.), was mich ein wenig gestresst hat (in letzter Zeit werde ich leicht gestresst). Ich sagte dem Kollegen, er solle es vermeiden, jQueryund sie stimmten zu. So weit, ist es gut.

Nachdem ich einige Git-Commits gepusht hatte, bekam ich wütende Nachrichten von dem Kollegen. Obwohl ich diese sehr einfachen Konflikte vor dem Push gelöst habe, waren ihre Dateien irgendwie voller Konflikte, die von mir verursacht wurden. Und sie sagten, dass ich das Drücken nicht erwähnt habe, bevor ich drücke. Ich war schließlich damit einverstanden. Aber es ist seltsam, dass ich Gitlike verwenden sollte SVN. Ich hatte auch meine Zweifel, dass sie auch Fehler haben. Ich habe gesehen, dass 5 bis 8 Dateien nicht von ihrem Computer gesendet wurden und direkt git addauf dem Zweig entwickelt wurden . masterIch schlug vor, dass jeder von uns seine eigenen Niederlassungen nutzen sollte, um dies zu lösen, womit sie anfangs nicht einverstanden waren.

Kürzlich wurde ich von meinem Chef erwähnt, dass mein Kollege sich Sorgen darüber macht, dass mein Teil Bootstrap-Vue. Ihr Teil bestand nicht darin, es zu verwenden, und stattdessen wurden die meisten Module mithilfe globaler Variablen handgefertigt. Und sie sagten, dass dieser Unterschied in der Zukunft zu einigen "Konflikten" führen könnte, und schlugen vor, dass wir unsere Entwicklungsmethode vereinheitlichen sollten. Ich stimmte zu, obwohl ich nicht sicher bin, welche Art von Konflikt sie erwarteten. Aber ich vermute, dass der Kollege nicht weiß, wie man Bootstrap benutzt (andere Kollegen vermuten das auch) und mich zwingen könnte, meine Arbeit auf ihre Art zu erledigen, was ich hasse.

Es ist noch nicht einmal ein Monat her, aber seit ich mit der Arbeit am CMS anfange, habe ich immer wieder große und kleine Reibungen mit diesem Kollegen. Ich weiß, dass ich voreilig bin, aber ich hätte es fast geschafft. Ich denke, es ist an der Zeit, dass ich meinen Job nach 6 Jahren Arbeit für ein paar Monate kündige. Aber bevor ich das tue, möchte ich wissen, wie ich diese Reibungen in Zukunft möglichst lösen kann. Es wäre auch toll, eine Lösung für dieses aktuelle Problem zu finden.

@JoeStrazzere der OP ist seit 6 Jahren dort, dieses Interview ist eine Weile her und das Personal hat sich wahrscheinlich geändert…
@SolarMike Dachte ich anfangs auch, aber jetzt glaube ich, hat er es für die nächsten Vorstellungsgespräche gesagt.
@JoeStrazzere Ich habe eine neue Frage hinzugefügt, um eine Lösung für das aktuelle Problem zu finden. Entschuldigung, dass ich das spät hinzufüge.
"Sie entwickelten ein CMS" Sie entwickelten ein kompaktes Muon-Solenoid? Das ist ziemlich beeindruckend.
@Stef Hahaha, OK, ich werde klären. Es ist ein Content-Management-System.
Hast du mit dem Ziel-Git-Zweig zusammengeführt, bevor du deine Änderungen gepusht hast? Wenn nicht, bedenken Sie das in Zukunft.
Sie und Ihr Kollege müssen Ihren Git fit machen.
@iLuvLogix Ich glaube, das hat er schon gemacht. Ich führe von masterzu meinem Zweig zusammen, dann führe ich von meinem Zweig zu zusammenmaster

Antworten (3)

Lassen Sie uns dies aus einer anderen Perspektive aufschlüsseln.

Der andere Entwickler arbeitete an einem Projekt und bat um Hilfe. Du tauchst auf und fängst an, Dinge anders zu machen. Sie fangen dann an, sich darüber zu beschweren, wie die Dinge erledigt werden, folgen ihrem Beispiel nicht und anstatt zu helfen, verursachen Sie tatsächlich zusätzliche Arbeit.

Ich würde dringend vorschlagen, dass Sie, um die Reibung hier zu verringern, einen Schritt zurücktreten und die Dinge so codieren, wie der andere Entwickler es eingerichtet hat. Wenn Sie Fragen haben, stellen Sie sie. Wenn Sie eine andere Richtung einschlagen möchten, sprechen Sie zuerst mit ihnen. Wenn Sie Toolkit A verwenden möchten und sie B verwenden, verwenden Sie einfach B. Wenn sie nein sagen, ist es ein nein.

Eine große Herausforderung für die Entwicklung besteht darin, dass Menschen sich nicht an festgelegte Standards halten. Es macht nichts, wenn die Standards nicht so groß sind. Wichtig ist, dass das Projekt konsistent ist. In dieser Situation sind Sie derjenige, der sich nicht an die Projektstandards hält.

Es gibt immer einen "besseren" Weg, Dinge zu tun, aber das bedeutet nicht unbedingt, dass Sie das, was gerade getan wird, über Bord werfen sollten.

Gut gesagt, ich stimme vollkommen zu, tatsächlich würde ich noch ein wenig weiter gehen.
Dem stimme ich teilweise nicht zu. Wenn eine Organisation nicht einmal eine grundlegende Grundlage für die ordnungsgemäße Organisation ihrer Arbeit hat, ist es keine große Herausforderung, sie zu meistern, es ist Scheiße, damit fertig zu werden oder wegzulaufen. In der Industrie gibt es Standardmethoden, um sogar ein Anfängerteam zu organisieren und Tools zu verwenden. Obwohl ich nur die OP-Version habe, können wir sagen, dass diese Leute nicht einmal verstehen, was sie tun, und sich weigern, Fortschritte überhaupt in Betracht zu ziehen. Also entweder OP wird damit fertig oder er rennt weg. Bitte nennen Sie nicht "Herausforderung", was es nicht ist. Es ist eine Beleidigung für den Entwickler, der eine echte "Herausforderung" überwindet.
@Walfrat: Wenn ein kleines Team aktiv gegeneinander arbeitet, dann wird das Projekt scheitern. OTOH, wenn OP den Anweisungen der anderen Entwickler folgt, besteht zumindest eine gewisse Chance auf Erfolg. Es wird nicht der schönste Code sein, und es wird wahrscheinlich einiges an Refactoring erfordern, aber zumindest haben sie eine Chance auf eine Veröffentlichung. Wenn OP später für sein eigenes Projekt verantwortlich ist, kann er/sie die Messlatte um einiges höher legen.
"mindestens eine Chance auf Erfolg" ja und im Falle eines Misserfolgs, wer wäre schuld? Natürlich "es kommt darauf an", aber ich würde sagen, dass es viel wahrscheinlicher ist, dass der kompetente Entwickler beschuldigt wird als die anderen.

Ich habe das Gefühl, dass dies nichts mit Workplace zu tun hat, sondern eher mit einer Softwarearchitektur, die Teil von StackExchange ist. Und Ihr Beitrag bringt mich dazu, fast nichts als Fragen zu stellen.

Nachdem ich einige Git-Commits gepusht hatte, bekam ich wütende Nachrichten von dem Kollegen. Obwohl ich diese sehr einfachen Konflikte vor dem Push gelöst habe, waren ihre Dateien irgendwie voller Konflikte, die von mir verursacht wurden.

Sollte Git nicht aufhören und davor warnen? Wie ist das überhaupt möglich?

Und sie sagten, dass ich das Drücken nicht erwähnt habe, bevor ich drücke.

Lächerlich, das ist die Arbeitsweise der 90er.

Ich war schließlich damit einverstanden. Aber es ist seltsam, dass ich Git wie SVN verwenden sollte.

Warum haben Sie dem zugestimmt? Wie ist es Ihre Aufgabe, seine Konflikte zu lösen? Inwiefern ist es Ihre Pflicht, Git wie SVN zu verwenden?

Ich hatte auch meine Zweifel, dass sie auch Fehler haben.

Ich habe Ihren Code noch nie gesehen und habe auch ernsthafte Zweifel, nur aufgrund dessen, was ich aus Ihrem Beitrag gelesen habe.

Ich habe gesehen, dass 5-8 Dateien nicht von ihrem Computer hinzugefügt wurden und sie direkt auf dem Master-Branch entwickelt wurden. Ich schlug vor, dass jeder von uns seine eigenen Niederlassungen nutzen sollte, um dies zu lösen, womit sie anfangs nicht einverstanden waren.

Warum haben Sie diese Meinungsverschiedenheit akzeptiert? Sie scheinen nur vor sinnlosen und veralteten Arbeitsabläufen einzuknicken. Der Git-Workflow erfordert nichts davon. Und mit mehreren Leuten am Master-Zweig zu arbeiten und sich dann darüber zu beschweren, dass andere Leute Konflikte verursachen und ihnen die Schuld geben, schreit nach Ignoranz gegenüber Git. Wenn er nichts zu Git hinzufügt und dann Konflikte bekommt, ist das allein seine Schuld.

Kürzlich wurde ich von meinem Chef erwähnt, dass mein Kollege sich Sorgen um meinen Teil macht, der Bootstrap-Vue verwendet. Ihr Teil bestand nicht darin, es zu verwenden, und stattdessen wurden die meisten Module mithilfe globaler Variablen handgefertigt.

Ich habe keine Meinung zu Ersterem (kein Vue-Experte, habe einmal Bootstrap verwendet), aber ich verstehe wirklich nicht, warum Sie handgefertigte Module mit globalen Variablen verwenden, es sei denn, es handelt sich um ein Firmendesign. In Ihrem Beitrag fehlen wichtige Informationen, z. B. warum Sie diese hausgemachten Module anstelle eines öffentlich verfügbaren Moduls verwenden.

Und sie sagten, dass dieser Unterschied in der Zukunft zu einigen "Konflikten" führen könnte, und schlugen vor, dass wir unsere Entwicklungsmethode vereinheitlichen sollten. Ich stimmte zu, obwohl ich nicht sicher bin, welche Art von Konflikt sie erwarteten.

Selbstgemachte und öffentliche Module/Frameworks zu haben, wird sicherlich irgendwann zu Designkonflikten führen, aber die eigentliche Frage ist, warum Ihre selbstgemachten besser funktionieren und warum Sie ihre anstelle eines bewährten öffentlichen verwenden sollten?

Aber ich vermute, dass der Kollege nicht weiß, wie man Bootstrap benutzt (andere Kollegen vermuten das auch) und mich zwingen könnte, meine Arbeit auf ihre Art zu erledigen, was ich hasse.

Auch hier sagen Sie nicht die Hälfte von dem, was Sie sollten.

  1. Warum verwenden Sie hausgemachte Module/Frameworks anstelle öffentlicher?

Zu sagen "Ich hasse seinen Weg" rechtfertigt nichts, erklären Sie bitte, warum er überhaupt seine eigenen Module verwendet und warum es besser ist als Bootstrap-Vue. Ist dies nicht der Fall, sollten Sie argumentieren, dass sein Weg falsch ist, und nicht nachgeben.

  1. Warum akzeptieren Sie widersprüchliche Aussagen von Ihrem Kollegen, wenn er eindeutig nicht den richtigen Arbeitsablauf verwendet?

Git nicht richtig zu verwenden und dir dann die Schuld zu geben, ist völlige Inkompetenz, die dir auf die Schultern geschoben wird. Das sollte man sich nicht entgehen lassen.

  1. Warum geben Sie ihm in diesen Konflikten nach?

Warum um alles in der Welt "stimmen" Sie jemandem zu, von dem Sie wissen, dass er Git nicht richtig verwendet, nicht bereit ist, etwas so Einfaches wie das Verzweigen zu tun, und Ihnen die Schuld gibt, wenn er nur einen Teil seiner Arbeit vorantreibt und dann Konflikte bekommt?

Dies ist entweder ein technisches Problem, in diesem Fall sind Sie nicht am richtigen Ort, oder ein Persönlichkeitsproblem, bei dem Sie ohne jeden Grund schlechten Praktiken und unverantwortlichem/inkompetentem Verhalten nachgeben.

1. Davon werde ich überzeugen. Es dauert noch an. 2. Es liegt ein Missverständnis vor. Ich sagte, "sie waren anfangs anderer Meinung" git add, aber schließlich stimmten sie zu. Ich habe ihrer Amtszeit nicht zugestimmt. 3. Ich stimme zu, dass es unlogisch war. Ich habe mein Bestes versucht, sie zu überzeugen, aber sie sind so stur und ich wollte weitermachen. Also dachte ich, ihnen von Zeit zu Zeit Nachrichten über meinen Vorstoß zu schicken, wäre ein kleiner Preis, den ich zahlen muss, was ich jetzt bereue. Und ... Ich war mir nicht ganz sicher über die Git-Nutzung.
@Asimpleuser dafür ist es ein bisschen spät, aber Faustregel: Stimmen Sie NIEMALS "vorübergehend" etwas in der Geschäftswelt zu. Einmal „Ja“ zu sagen, heißt für immer „Ja“ zu sagen, denn Arbeitsabläufe in einem Unternehmen zu verändern ist etwas, was niemand jemals tun möchte. Wenn du bei absurden Dingen nachgibst, wirst du sie für immer tun.

Die Antwort auf das Problem ist genau hier

Gestresst von einem Kollegen, der grundsätzlich gegen meine Arbeitsweise ist

Die Arbeitsweise des Teams/der Abteilung/des Unternehmens sollte hier beschrieben werden.

Normalerweise als neues Mitglied eines Teams; Ob Software schreiben oder Bergsteigen, Sie sollten derjenige sein, der dazugehört. Aus Ihrem Beitrag geht hervor, egal welche Probleme das Projekt hat, es ist klar, dass Sie im Moment nicht die Person sind, die "hineinpassen" möchte. Dies verursacht zweifellos mehr Probleme und trägt daher nicht wirklich zur Entlastung bei.

Da Sie nach nur 6 Jahren immer noch ein Neuling sind, sollte Ihr Abgang kein großes Problem für das Unternehmen darstellen, so dass keine Bindungsprobleme entstehen müssen. Die Diskussion liegt also bei Ihnen. Obwohl ich bezweifle, dass Sie es ernst meinen mit dem Verlassen, da dies eine persönliche Entscheidung ist, die Sie selbst treffen müssen. Dies scheint eher nur ein Stöhnen zu sein, eine Gelegenheit, Ihrer Frustration Luft zu machen, wie aus dem detaillierten Bericht hervorgeht. Auf jeden Fall wünsche ich dir viel Glück für die Zukunft.

Gestresst von einem Kollegen, der generell gegen meine Arbeitsweise ist
AntwortenHierDatenschutz-Bestimmungen1y, 0v