Frage:
Wie gehe ich mit Kollegen um, die bei der Codeüberprüfung nicht hilfreiche Kritik üben?
opel
2015-10-09 22:06:07 UTC
view on stackexchange narkive permalink

Ich habe Probleme mit einem Kollegen, der bei Codeüberprüfungen heftige Kritik übt, bis er zu Argumenten über "Wer weiß mehr" wird, anstatt sie fokussiert und hilfreich zu halten.

Manchmal liefert er nützliche Informationen Feedback. Zum Beispiel wies er darauf hin, dass meine Codekommentare beim Schreiben auf Englisch schwer zu verstehen sind - stattdessen fordert er mich auf, sie in meiner Muttersprache zu schreiben. Ok, dem stimme ich zu.

Aber er hat mir auch einmal gesagt, dass es schlecht ist, eine neue Funktion zu erstellen, wenn ich sie nur einmal benutze - ich war damit nicht einverstanden und fühlte mich wie er Ich versuche nur, ein Argument zu beginnen. Ich gab ihm ein Beispiel, in dem ein hochkarätiger, weithin anerkannter Entwickler dies getan hatte, und seine Antwort lautete: "Sie lesen einen Mann im Internet und glauben, was er erzählt?" Ich sagte nein. Er sagte auch: "Sie haben das gerade gefunden, um zu zeigen, dass Sie Recht haben."

Wann immer er meinen Code überprüft und ich kein gutes Argument habe - es ist eine schlechte Situation, weil er sagt: " das ist kein gutes Argument. " Wenn ich jedoch ein vernünftiges Argument finde, greift er mich immer noch an und versucht mich zu widerlegen. Meine Frage ist, was kann ich tun, um eine hilfreiche Codeüberprüfung durchzuführen, anstatt sie in ein Argument umzuwandeln? Wenn sie sich in ein Argument verwandelt, fühle ich mich schlecht. Ich würde gerne ein gutes Feedback erhalten, aber letztendlich möchte ich mich danach nicht schlecht fühlen.

Einige Lösungen, die ich in Betracht gezogen habe, sind:

Sollte ich nicht antworten zu ihm überhaupt? Ich mache das oft. Aber wenn ich das tue, fühle ich Ärger und andere schlechte Gefühle. Es passiert, wenn mir jemand etwas Schlechtes über mich erzählt, ohne dass mir ein gutes Argument beweist, dass dies real ist und nicht nur ihr Gedanke.

Soll ich einfach meinen Job wechseln? . Aber ich glaube, dass es in fast jedem guten Job Leute geben wird, die versuchen, Ihnen zu zeigen, dass Sie schlecht sind, wenn Sie tatsächlich nicht schlecht in Ihrem Job sind, zumindest in dieser bestimmten Situation.

Soll ich ihn bitten, mich nicht zu beleidigen? Aber das lässt mich nur schwach aussehen, wie "der arme Junge hier kann sich nicht rächen, also bittet er uns nur, ihn nicht anzugreifen."

Die ganze Situation erinnert mich an ein Spiel. Zum Beispiel kämpfen wir in einem Spiel gegeneinander und das Gewinnen ist Schweiß. Und in einem Spiel fragen wir nicht höflich - tu dies oder das nicht, weil ich dann kaum gewinnen werde. Ich denke, bei einer Codeüberprüfung sollten wir höflich sein, anstatt es wie ein Spiel zu behandeln, das wir um jeden Preis gewinnen wollen.

Stattdessen verwandelt er die Codeüberprüfung in ein Spiel , aber das Spiel ist kein Computerspiel oder Sportspiel - es ist ein Argumentationsspiel, ein Wissensspiel. Wer ist besser im Code. Imo.

Hallo opel, und willkommen auf der Seite.Ich habe Ihre Frage bearbeitet, um das Lesen zu erleichtern.Wenn Ihnen die Änderungen nicht gefallen, können Sie sie erneut bearbeiten.
Es ist sehr wahrscheinlich, dass dies aufgrund persönlicher Erfahrungen fortgesetzt wird.Versuchen Sie, nach anderen Optionen für die Codeüberprüfung zu suchen: verschiedenen Teammitgliedern, einem neuen Manager oder einer neuen Firma.Zu oft habe ich gesehen, wie Codeüberprüfungen giftig wurden und sich in eine Form passiver aggressiver Sabotage verwandelten.Manager, die es giftigen Mitarbeitern ermöglichen, dies zu tun, sind Teil des Problems.Dies hat zwei Gründe: 1) Sozialwissenschaftlern ist bekannt, dass Menschen [Autoritätsbias] haben (https://en.wikipedia.org/wiki/Authority_bias).2) [Das Gefangenendilemma] (https://scholar.harvard.edu/files/jonathanxc/files/fostering_collaboration.pdf)
Elf antworten:
#1
+11
user42762
2015-10-10 01:54:06 UTC
view on stackexchange narkive permalink

Making something a function is not only for reuse but also to reduce complexity. Moving 6 lines of code out of a 20-line block is good, moving two lines out proly not, so it depends what you did.

You need to discuss the whys, not the whats. Ask all the time why, might help you understand how others (later maintainers) see your code.

And insist on politeness if he is rude, things can always be discussed polite.

Ich werde oft komplexe Bedingungen in ihre eigene Funktion verschieben, wenn dies nicht zu viel Parameterübergabe verursacht. Ich finde es viel klarer und ich denke, der Compiler wird es sowieso nur einbinden, damit es keinen Leistungseinbruch gibt. Ich versuche zu vermeiden, mehr als einen Block tief in eine Funktion zu gehen.
Ich fragte warum. Er hat nichts erzählt. Nachdem ich ein Beispiel gezeigt habe, dass andere, von denen ich annehme, dass sie gut sind, dies tun, habe ich gerade die Antwort erhalten, dass ich ihm zeigen wollte, dass ich Recht habe. Das bedeutet, dass er keine wirklichen Argumente hatte. @LorenPechtel - wenn es viele Parameter gibt - ich setze diese oft als private Klassenvariablen und dann sieht jede Funktion sie in der Klasse.
Ganz zu schweigen von einer gründlicheren Codeabdeckung beim automatisierten Testen!
Dies erleichtert auch das Testen von Einheiten und macht den Code besser lesbar und somit wartbar.
#2
+10
Xavier J
2015-10-09 23:47:01 UTC
view on stackexchange narkive permalink

Peer review is opinion-based. He's not your boss. You can take the information constructively, or you can ignore it altogether. If he's pointing out things that are objective (i.e. ways to measurably improve performance, maintainability, reliability, scalability) work with those, but with the other stuff you can't let it bother you so much. Someone's always going to have an opinion different from yours.

Wenn es seine Meinung ist, sollte er es nicht so aussehen lassen, wie es eine Regel ist, nehme ich an. Er kann sagen, dass es seine Meinung ist, ich sage meiner Meinung nach, dass es anders ist, dann ok, wir können unterschiedliche Meinungen haben. Aber es sah nicht nach einer Meinung aus, sondern nach einer Möglichkeit, allen zu zeigen, wie schlecht ich bin und wie gut er ist, dass er dies entdeckt hat.
Es wird immer Menschen geben, die ihre Befriedigung erhalten, wenn sie glauben, dass sie RICHTIG sind, unabhängig davon, ob es tatsächlich von Wert ist oder nicht. Lernen Sie, diese Leute zu erkennen, und wenn Sie in ein Gespräch geraten, nicken Sie einfach viel mit dem Kopf, weil es nutzlos wird, nicht zuzustimmen. Finde eine Ausrede, um so schnell wie möglich aus dem Gespräch auszusteigen !!!
Diese Art von Rat ist mit einer Einschränkung großartig: Wenn und nur wenn der Manager Sie tatsächlich dabei unterstützt, die überkritischen Bemerkungen des kanterhaften Rezensenten und die Dinge, die er von Ihnen verlangt, zu ändern, außer Kraft zu setzen.Manchmal ist ein Manager nachlässig, schaut aktiv weg oder ermöglicht das Mobbing- und Sabotageverhalten eines Mitarbeiters.Dies ist der Zeitpunkt, an dem es zu einer giftigen Umgebung und einem feindlichen Arbeitsplatz wird: Ihre Arbeit hängt davon ab, dass Sie Code nach eingehenden Überprüfungen erhalten, und Ihre Arbeit wird konsequent zugunsten nicht funktionierender Kritik, vorübergehender Launen oder Sabotage der Prüfer zurückgehalten, damit Sie schlechter aussehen als sie.
#3
+6
Dan
2015-10-09 23:42:30 UTC
view on stackexchange narkive permalink

Peer Review ist in der Branche weit verbreitet. Es hört sich für mich so an, als würden Sie es persönlich nehmen, wenn jemand etwas über Ihren Code sagt, was daran zu erkennen ist, dass Sie ihm "zeigen" möchten, was mit seinem Denken / Code nicht stimmt.

Mein erster Rat ist: immer mit der Ruhe. Mein Rat ist, zu versuchen, das, was sie sagen, von "kritisch" bis vielleicht "schön zu haben" zu priorisieren.

Auf der anderen Seite denke ich manchmal, dass Unternehmen eine inkonsistente Struktur haben, wenn es um Code-Review / Peer-Review geht. In erster Linie sollte eine "Best Practice" -Richtlinie festgelegt werden, wenn es um die Codierung geht. Von Namenskonventionen bis hin zur Integration von Datenbanken in den Code sollten Dinge festgelegt werden. Es muss nicht auf branchenweiten Best Practices basieren, sondern sollte lose darauf basieren und in Ihre Branche passen.

Einige Orte haben ungeschriebene Best Practices, aber ich denke, die meisten Orte fehlen . Was ich tun würde, ist zuerst die Person zu bitten, ihre Kommentare von "kritisch, muss haben" bis "schön zu haben" zu priorisieren. Wenn ALLES kritisch ist, muss und Sie keine bewährten Methoden haben, würde ich zum Chef gehen und erklären, dass es bewährte Methoden geben muss, da die Codeüberprüfung einer Person sehr locker ist, während eine andere überkritisch ist, um alles zu ändern Befolgen Sie jedoch keine festgelegten Richtlinien.

Denken Sie daran, dass das allgemeine Ziel der Peer Review darin besteht, dass jemand Ihren Code überprüft, um festzustellen, ob Sie geschäftslogische, sicherheitsrelevante oder allgemein leicht lesbare Codes übersehen. Ich schlage vor, einige Codierbücher in die Hand zu nehmen und zu prüfen, ob etwas, was diese Person sagt, mit dem übereinstimmt, was in der Branche am besten bekannt ist. Wenn das, was er sagt, weit verbreitet ist und andere in Ihrem Unternehmen zustimmen, würde ich diese Person eher als Mentor sehen als als jemanden, der "Sie herausholen" will.

Bearbeiten: Wenn Sie der Meinung sind, dass dieser Mitarbeiter schlecht ist, versuchen Sie, Open-Source-Code auf github einzureichen. Es ist sicher, dass Ihr Code in 95% der Fälle abgeschossen wird. Sie können sich nicht von Emotionen antreiben lassen. Stattdessen muss man es vom Standpunkt des allgemeinen Konsenses aus betrachten und was jeder für das Beste hält. Es gibt Zeiten, in denen ich eine Woche lang an einem Code arbeite und dieser einer Peer-Review unterzogen wird. Letztendlich entscheiden wir uns, dies nicht zu tun, und ich speichere ihn einfach. Manchmal kommt es zurück, manchmal geht es tot. Nimm es einfach nicht persönlich.

"Mein erster Rat ist, es ruhig angehen zu lassen." - das versuche ich oft und bekomme schlechte Gefühle wie Wut.
Aber wenn er mir sagt, dass das Erstellen von Funktionen für den einmaligen Gebrauch schlecht ist, wette ich, dass es nicht das ist, was jeder denkt.
#4
+3
paparazzo
2015-10-09 23:37:57 UTC
view on stackexchange narkive permalink

Blaming is a bad title. He is not blaming you for a program crashing that was not you fault. He is disagreeing with some code practices. There some code practices that are clearly bad (repeated code blocks) and lot in the middle that people are not going to all agree on. Try and turn it into acceptable code practices rather than best. Is a single use function acceptable - I hope yes. Try and get it moved from optimal code to acceptable. Does it perform? Can it be maintained?

Es geht nicht um Code-Praxis, sondern im Allgemeinen darum, etwas zu beschuldigen, wenn er es nicht sollte. Code-Praktiken waren nur ein Beispiel für Illustration
Dann war es ein schlechtes Beispiel für Schuldzuweisungen. Lernen Sie, Kritik zu nehmen und weniger konfrontative Sprache zu verwenden.
das ist leicht zu sagen :) Ich meine, ich muss lernen, keine schlechten Emotionen zu bekommen, aber wie geht das? :) Mit schlechten Emotionen kann ich schweigen und keine konfrontative Sprache verwenden.
#5
+2
Adel
2015-10-09 22:46:16 UTC
view on stackexchange narkive permalink

Ein Teil des Bürolebens, insbesondere für Programmierer, besteht darin, manchmal mit etwas herausfordernden Persönlichkeiten umzugehen. Sie können Sie beleidigen, Ihre Gefühle verletzen.

Manchmal versuchen Sie, die guten Teile zu extrahieren und die schlechten Teile zu verlassen. Ich hatte einen ehemaligen Chef, bei dem Sie häufig Schimpfwörter verwendeten. Es würde mich nerven, aber ich habe mir auf die Oberlippe gebissen.

Wenn er sagt "Diese Codezeile sieht aus wie @ # $ @ * & und ich bin ernsthaft @ # $ @ # $ @ #" dann Ich nickte mit dem Kopf und versuchte, geduldig zu sein.

Aber eines Tages hatten wir ein Besprechungstreffen, und er überprüfte meine Leistung. Dann fragte er mich am Ende des Treffens: "Gibt es einen Vorschlag, den Sie für mich haben?" Und ich sagte: "Nun, ich habe das Gefühl, dass Sie die Sprache ein wenig abschwächen können."

Danach bemerkte ich einen wirklich starken Rückgang der schlechten Langugae. Daher denke ich, dass der beste Zeitpunkt für Ratschläge die Leistungsbeurteilung sein kann. Aber wenn es ein ernstes Problem ist, können Sie immer höflich kommunizieren. Bitten Sie um ein kurzes Treffen. Von Angesicht zu Angesicht ist besser als E-Mail. Aber sei höflich und professionell

Ok, sagen wir mal, ich bin der Gute, der ihn höflich zu einem Treffen einlädt, um über das Problem zu sprechen. Trotzdem besteht eine hohe Wahrscheinlichkeit, dass er dieselben Argumente vorbringt - dass ich mich in der Situation geirrt habe und er Recht hatte, also hat er das Recht, mir die Schuld zu geben.
#6
+2
gnasher729
2015-10-11 03:17:15 UTC
view on stackexchange narkive permalink

Code reviews are mainly done for two reasons: To stop bad design and bugs to enter a code base, and to educate less experienced developers. It seems the latter is not the case here, so the idea behind the code review is to stop bad design and bugs.

In a good environment, if the reviewer finds bad design or bugs, that is appreciated and gladly fixed. There are situations where it is opinion based or style based which way to write code is the best; in that case it is absolutely fine for a reviewer to point out a way that is better, or that the reviewer thinks is better, but that isn't so much and better or so undisputed better that it is worth investing the work for a change.

Your environment seems to be toxic. Code reviews seem to have deteriorated to power fights. So your coworker demands that you remove all small functions that are called only once. Why don't you demand that he extracts code into small functions when you review his code? The outcome, if you both do as you are told, is ridiculous: You change your code to something that you feel is worse, and he changes his code to something that he feels is worse. Totally ridiculous.

What actually needs to happen is that your manager bangs your heads together and tells you how to do code reviews. The reviewer can state objections to the code, and the objections must be answered. That doesn't mean the reviewer can act as a tyrant whose orders need to be obeyed. If I told you "this function should not be a separate function but incorporated in other code" then stating "being a separate function makes this more adaptable and maintainable, and even if it where true then the benefit would be so small that it doesn't justify the effort to make the change and verify that it is correct" is a perfectly reasonable answer.

#7
+2
dwizum
2018-05-25 17:59:58 UTC
view on stackexchange narkive permalink

Codeüberprüfungen und Codestandards sind ein Mittel zum Zweck. Bei korrekter Ausführung besteht das Ziel nicht darin, einen Standard zu erfüllen oder eine mögliche Verbesserung in einer Überprüfung zu finden . Das Ziel besteht vielmehr darin, Software zu schreiben, die für einen bestimmten Anwendungsfall geeignet und nachhaltig / unterstützbar ist.

Anders ausgedrückt, Ihr Ziel ist nicht " perfekter "Code. Ihr Ziel ist "geeigneter" Code. Alles andere ist im Wesentlichen eine Verschwendung von Ressourcen.

Vor diesem Hintergrund lautete Ihre Frage:

Was kann ich hier also noch tun?

Zuerst müssen Sie das Feedback Ihres Mitarbeiters filtern: Ist es hilfreich, Ihren Code auf den gewünschten Standard zu bringen?

  1. Wenn ja: Integrieren Sie das Feedback und fahren Sie fort. Es ist leicht zu fühlen, dass er dich persönlich angreift. Sie müssen in der Lage sein, persönliche Emotionen von Ihrer Arbeit zu trennen. Wir alle werden manchmal Lücken in unserem Arbeitsprodukt haben, deshalb machen wir Reviews.
  2. Wenn nein: Lassen Sie ihn sein Stück sagen und geben Sie keine emotionale oder argumentative Antwort. Wenn Sie antworten, spielen Sie in sein Spiel (das Spiel, das Sie in Ihrem Update Ihrer Frage bestätigt haben). Zum Spielen eines Spiels sind zwei Personen erforderlich. Wenn Sie aufhören zu spielen, wird das Spiel beendet!
  3. ol>

    Wenn es in Ihrer Umgebung keine dokumentierten Standards gibt: Es ist schwieriger, die Entscheidung zwischen dem ersten und dem zweiten Fall zu treffen dein eigener Richter sein. Der Haupttrick ist jedoch, sein Spiel nicht zu spielen. Drehen Sie dies stattdessen um und konzentrieren Sie sich darauf, das hilfreiche Feedback herauszufiltern, das Sie einbeziehen können, und zu lernen, das nicht hilfreiche Feedback zu ignorieren.

    Egal, wo Sie arbeiten oder welchen Job Sie haben, es wird immer Leute geben, die nichts anderes wollen, als darauf hinzuweisen, dass Sie nicht gut genug sind oder besser als Sie. Eine der grundlegendsten Lebenskompetenzen, auf die Sie sich konzentrieren können - sowohl für Ihre persönliche Zufriedenheit als auch um sicherzustellen, dass Sie sich als Mitarbeiter verbessern -, besteht darin, zu lernen, wichtige Dinge aus Dingen herauszufiltern, die dies nicht tun.

#8
+1
user9641
2015-10-10 15:22:47 UTC
view on stackexchange narkive permalink

es ist ein Argumentationsspiel, ein Wissensspiel. Wer ist besser im Code. Imo.

Ich denke, das ist Ihr größtes Problem. Es ist kein Spiel, es ist ein kollaborativer Prozess, um etwas Besseres zu schaffen. Sie müssen lernen, nicht mehr an Gewinnen und Verlieren zu denken. Ich verstehe, warum du so fühlst, wie du es tust, weil es die menschliche Natur ist. Aber mit Erfahrung und pflegendem Vertrauen können Sie dies überwinden und die Gelegenheit schätzen, über Ihre Ansichten nachzudenken.

Es würde viele Kritikpunkte geben, die nicht gültig sind und mit denen Sie nicht einverstanden sind. Sie können sie nicht wirklich beseitigen. So wie niemand ständig fehlerfreien Code schreiben kann, kann niemand jederzeit perfekte Urteile fällen. Sie müssen eine Lücke schließen, nicht zuletzt, weil Sie es auch tun.

Wenn dies passiert, sollten Sie fragen, ob dies erhebliche negative Auswirkungen auf die Codebasis haben würde, wenn ich der Empfehlung folge, mit der ich nicht einverstanden bin? . Wenn nein, folgen Sie der Empfehlung. Die Leute fühlen sich gut, also bekommen Sie dort zumindest Wert. Wenn ja, wägen Sie die beiden Optionen erneut sehr sorgfältig ab. Manchmal geht es nicht nur um Technologie, sondern auch um Menschen. Wirklich gute Entwickler können mit Code UND Menschen arbeiten. Wenn Sie nach dem Abwägen des menschlichen Faktors immer noch der Meinung sind, dass die Auswirkungen netto-negativ sind, sprechen Sie sich dagegen aus. Stellen Sie jedoch sicher, dass Sie IMMER zuerst versuchen, den Grund für die Empfehlung herauszufinden! In vielen Fällen haben Sie diesen Standpunkt noch nicht bemerkt. Und dann wachsen Sie als Entwickler.

Vergessen Sie den Stolz, er ist weit überbewertet!

"Wenn nein, folgen Sie der Empfehlung." - Ich frage meinen Chef, und wenn er auch sagt, dass er dasselbe tun soll, dann tue ich, was mein Chef sagt.
Ja, ich kann schlechte Kritiken nicht beseitigen. Aber wir können herausfinden, ob es schlecht oder gültig ist, indem wir Fakten auf Google aus gültigen Quellen diskutieren und finden. Und dann sollte er zugeben, dass seine Kritik schlecht war, so wie ich meine Fehler zugebe, wenn seine Kritik gut ist. Das erwarte ich von klugen, angesehenen Menschen.
Vollkommen anderer Meinung sein. Änderungen sind Arbeit und führen zu Fehlern. Die Frage sollte also lauten: Würde es einen signifikanten positiven Einfluss auf die Codebasis haben, wenn ich der Empfehlung folgen würde?
@gnasher729: Die Annahme hier ist, dass der andere stark davon überzeugt ist, dass es befolgt werden sollte und dass es keine signifikanten Negative gibt, wie viel Arbeit. Z.B. Wenn jemand der Meinung ist, dass x eine separate Funktion sein sollte, warum nicht, auch wenn Sie nicht wirklich der Meinung sind, dass es wichtig ist? Zumindest können Sie weitermachen und etwas Nützliches tun.
#9
  0
Edwin Buck
2018-05-24 20:26:06 UTC
view on stackexchange narkive permalink

Lösen Sie die Probleme, indem Sie sie beheben.

  • Ihre Funktion wird nur einmal verwendet.

Ehrlich gesagt kann eine Funktion, die nur einmal verwendet wird, leicht verwendet werden inline. Vielleicht gibt es einen guten Grund, es nicht zu inline. Wenn ja, nutzen Sie diesen Grund.

Ich weiß nicht, was dieser Grund sein könnte, aber ich weiß, dass wenn die Funktion wirklich nur einmal verwendet wird, sie nicht durch Tests verwendet wird. Das heißt, Sie haben keinen Komponententest für die Funktion. Schreiben Sie eine, und dann haben Sie eine bessere Codequalität (nicht unbedingt eine bessere Lösung, aber zumindest ein Beweis dafür, dass die Lösung das tut, was beabsichtigt war). Sie haben auch zwei Stellen, an denen die Funktion verwendet wird.

Der Versuch, Wege zu finden, auf denen beide Seiten ein bisschen von dem bekommen können, was sie wollen, kann sich wie eine lästige Pflicht anfühlen. Aber auf lange Sicht werden Sie effektiver sein.

Eine Funktion, die nur einmal verwendet wird, kann morgen erneut verwendet werden.Es kann bereits geplant sein, dass es wieder verwendet wird.
@gnasher729 Befürworten Sie, keine Unit-Tests zu schreiben?Das scheint eine seltsame Sache zu sein.Wenn es einmal verwendet wird, gibt es keinen Komponententest.
#10
-1
Francesco Dondi
2017-04-12 17:01:28 UTC
view on stackexchange narkive permalink

Ich glaube ich verstehe, ich hatte einen Freund, der sich in der gleichen Situation befand. Seine Teamkollegen mochten ihn aus Gründen der Persönlichkeit nicht und standen seinem Code äußerst kritisch gegenüber, während sie viel größere Fehler miteinander übersahen. Sie hielten seinen Code an hohen Standards fest, die sie im Wesentlichen erfanden, so dass er sie unmöglich richtig machen konnte. Am Ende zeigte er nur allen den Mittelfinger und ging.

Vielleicht kann Ihr Manager sie schelten, da sie die Produktion aufhalten, indem sie das Feedback der Bewertungen nutzlos aufblähen, aber im Fall meines Freundes war es ihm egal . Wenn das nicht hilft und Sie dort weiterarbeiten möchten, ist mein Rat, sich darauf zu konzentrieren, zu verstehen, warum sie Sie nicht mögen, und das zu ändern. Andernfalls müssen Sie lernen, Ihre Emotionen zu kontrollieren und die Kritik zu ertragen, auch wenn Sie unfair sind.

#11
-1
Voxwoman
2018-05-25 21:09:25 UTC
view on stackexchange narkive permalink

Meine Empfehlung ist, dass Sie das Buch Die sanfte Kunst der verbalen Selbstverteidigung von Suzette Hayden-Elgin lesen. Es wird Ihnen helfen, mit Menschen umzugehen, die im Umgang mit Ihnen weniger als professionell sind.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...