Frage:
Wie kann ich Qualitätsprobleme ansprechen, wenn es eine umstrittene Geschichte gibt?
user1766760
2014-03-19 03:26:51 UTC
view on stackexchange narkive permalink

Bei meiner Arbeit mache ich mir zunehmend Sorgen um die Codequalität, kann sie jedoch nicht beheben. Ich denke hauptsächlich an die große Anzahl der eingehenden Arbeiten und Entwickler, mit denen ich gearbeitet habe.

Ich halte einige Hintergrundinformationen zu meiner Arbeitssituation für relevant. Ich halte meine Codierungsfähigkeit für besser in Bezug auf OOP, aber weniger in Bezug auf die Vielfalt der Technologien / Frameworks. Ich habe technisch gesehen ein niedrigeres Lohnniveau / eine niedrigere Berufsbezeichnung und bin auch körperlich jünger als die meisten anderen (ich kann die meisten Kinder meiner Mitarbeiter sein).

Dinge, die ich in der Vergangenheit versucht habe, aber nicht funktionieren so gut:

Ich habe versucht, Bedenken hinsichtlich der Codierung über Codeüberprüfungen zu äußern. Aber normalerweise sagt niemand wirklich etwas und ich sage am Ende viel. Irgendwann lerne ich einfach, die Klappe zu halten (ich habe das Gefühl, andere beleidigt zu haben, und / oder sie hören mir einfach nicht zu, es sei denn, der Manager unterstützt mich).

Bei zwei Gelegenheiten würde ein Problem auftreten werde zu hitzig und konfrontativ zwischen mir und einem anderen Entwickler. Ich baue meine Standpunkte auf, indem ich online nach den besten Codierungsmethoden recherchiere und ihnen E-Mails schreibe, die zur Diskussion einladen, um mit "Traue dem Internet nicht" und "Erfahrung" konterkariert zu werden.

Ich habe auch privat Bedenken an meinen Manager weitergeleitet, aber ich habe das Gefühl, dass ich zu diesem Zeitpunkt auch diesen Veranstaltungsort bereits ausgeschöpft habe.

Fragen:

  1. Wie kann ich berechtigte Bedenken äußern und Kritik äußern und sie berücksichtigen, akzeptieren und / oder letztendlich ansprechen?
  2. Vielleicht habe ich bereits die Chance auf eine herzliche Zusammenarbeit mit einigen Entwicklern ruiniert. Wie ändere / korrigiere ich, wie andere mich wahrnehmen, damit sie mir wieder zuhören?
  3. ol>
Schon mal was von Schlachten gehört? Wie fühlen Sie sich bei den anderen Entwicklern, wenn Sie diese Bedenken äußern, z. sollen sie glauben, dass ihre Arbeit Mist ist, weil sie diese Technik, die Sie online gefunden haben, nicht angewendet haben? Dies passt möglicherweise besser zu Programmers SE, obwohl ich mich fragen würde, wie viel Erfahrung Sie haben müssen, um zu wissen, was insgesamt am besten ist.
Sie können dies zu einer besseren Frage machen, indem Sie (lol) umgestalten, damit es für alle Arbeitsqualitäten und nicht nur für die Codequalität allgemein ist.
@JBKing Ich habe gehört, dass ich meine Schlachten ausgewählt und meine Erwartungen stark gesenkt habe. Normalerweise werde ich nicht kritisieren, es sei denn, ich interagiere sowieso mit einem bestimmten Code und bin davon betroffen. Ich fühle mich glücklich, wenn mir jemand sagt, was ich falsch mache, damit ich lernen kann, aber das ist nicht die Einstellung, die ich hier sehe. Da ich nicht so viel "Erfahrung" habe, lese ich viele Erfahrungen anderer Fachleute nach und sammle eine fundierte Entscheidung. Ich habe versucht, E-Mails mit einer Untergruppe von Entwicklern zu versenden, aber sie sind nicht empfänglich / wollten keine Nachforschungen anstellen. Ich finde, ich habe ein großes Problem mit dieser Mentalität!
@Pheonixblade9 Ich dachte darüber nach, die Fragen in ihrer Formulierung etwas offen zu lassen, da mir klar ist, dass dies auch in anderen Situationen gelten könnte. Mm .. nicht sicher wie (meinst du den eigentlichen Titel?)
Sie können beginnen, indem Sie den Titel in z. "Wie kann ich Bedenken hinsichtlich der Qualität äußern, sie berücksichtigen und mit meinen Kollegen weitermachen?" Der größte Teil des restlichen Beitrags ist bereits ziemlich allgemein gehalten. Ersetzen Sie "Ich betrachte ... Framework" durch "Ich betrachte meine technischen Fähigkeiten als recht gut in bestimmten Bereichen, aber aufgrund meiner mangelnden Erfahrung durchweg schwächer". Sie müssen wahrscheinlich noch irgendwo sagen, dass Sie in der Softwareindustrie für den Kontext sind, aber ich denke, dass @Pheonixblade9 ganz richtig ist: Sie würden eine größere Bandbreite an Antworten erhalten, wenn Sie Ihre Fragen allgemein formulieren würden. Viel Glück!
Was genau macht Ihnen Sorgen um die "Codequalität"? Bitte seien Sie sehr genau!
Bei Programmierern in mehreren Fragen gestellt und beantwortet, z. B.: [Wie bringen Sie Leute dazu, Codeüberprüfungen zu akzeptieren?] (http://programmers.stackexchange.com/questions/72806/how-do-you-make-people-accept-code -Rezension)
Fragen zur Einbeziehung des Managements, um dies zu unterstützen, wurden auch bei Programmierern gestellt und beantwortet, zum Beispiel: [Wie kann ich meinen Chef davon überzeugen, dass Qualität eine gute Sache im Code ist?] (http://programmers.stackexchange.com/q/) 87757/31260)
arbeitest du mit http://workplace.stackexchange.com/q/20796/14433
@gnat Ich werde mir in den nächsten Tagen etwas Zeit nehmen müssen, um sie mir anzusehen. Ich habe nicht auf Programmierer geschaut: /
@TooTone Ich mag den Titel, den Sie sich ausgedacht haben, und angesichts aller Kommentare werde ich mir später Zeit nehmen, um die Frage erneut zu bearbeiten. Machen Sie es über die Codierung hinaus klarer und anwendbarer.
@Kiwy - lol, auf einen Blick, nein. Niemand arbeitet wirklich spät bei meiner Arbeit, aber es gibt Ähnlichkeiten ... und es ist das, was ich fürchte zu werden und doch seltsamerweise gleichzeitig zu wollen - sei ein "Mr. Besserwisser" (um die Vorteile zu haben ohne die negativen Konnotationen) _seufz_
Wenn das Problem nur in Codierungsstandards besteht - besprechen Sie die Erstellung offizieller Codierungsstandards für Ihr Unternehmen mit Ihrem Manager (** die jeder / die meisten akzeptieren sollten **) - versuchen Sie nicht, Ihre Standards zu erzwingen, sondern lassen Sie alle bei der Erstellung mitreden ). Es gibt Kodierungsstandards, denen ich niemals zustimmen werde, unabhängig davon, wer wo was darüber sagt, aber ich wäre sicherlich offen dafür, mich daran zu halten, wenn es sich um einen unternehmensweiten Standard handeln würde.
Acht antworten:
#1
+29
Brad Thomas
2014-03-19 04:16:36 UTC
view on stackexchange narkive permalink

Wie kann ich berechtigte Bedenken äußern und Kritik üben? (und lassen Sie sie berücksichtigen, akzeptieren und / oder letztendlich ansprechen)

  • persönlich.
  • One- on-one.
  • Und nur für Dinge, die wirklich wichtig sind.

Was Sie erkennen müssen, ist, dass Sie es sind wird nicht wesentlich ändern, wie andere Entwickler Code. Abgesehen von der Religion, jemals vom Gelassenheitsgebet gehört? Wie der Code anderer Entwickler größtenteils außerhalb Ihrer Kontrolle liegt und immer sein wird, und je früher Sie damit einverstanden sind, desto besser für alle.

Vielleicht habe ich bereits ruiniert die Chance, eine herzliche Arbeitsbeziehung mit einigen Entwicklern zu haben. Wie ändere / behebe ich das? (Wie andere mich wahrnehmen, hören Sie mir noch einmal zu.)

Ja, Sie haben vielleicht erstaunliche technische Fähigkeiten, aber Sie lernen immer noch wirklich die Fähigkeiten der Menschen. Einfühlen. Wenn Sie das nächste Mal über Kritik nachdenken, die Sie möglicherweise als Versuch ansehen, anderen zu helfen, sich zu verbessern, denken Sie zuerst aus der Perspektive ihrer Bedürfnisse darüber nach. Was brauchen Ihre Kollegen? Respekt für ihren Code, Anerkennung, einen einfachen und unterhaltsamen Arbeitstag. Geben Sie ihnen das und Sie werden anfangen, die Dinge in Ordnung zu bringen.

Ich wusste nicht, wie das Gelassenheitsgebet offiziell genannt wurde. Ich habe das Sprichwort schon einmal gesehen (und das Lesen gab mir auf gute Weise ein gutes Kichern). In Bezug auf Ihren zweiten Punkt denke ich, dass einige Ihrer Aussagen bedeuten, die Codequalität loszulassen (?). Was ist eine Codeüberprüfung, wenn Sie kein Feedback geben können? Zum Beispiel: "Sie könnten hier benannte Konstanten anstelle von magischen Zahlen verwenden, da dies für den nächsten Entwickler offensichtlicher ist. Oder noch besser, Aufzählungen ..."
(Ich teile meinen Kommentar in zwei Teile auf, weil es zu lang und umständlich ist, ihn in einem zu halten.) Ich freue mich über Ihr Feedback, wie Sie die Dinge wieder in Ordnung bringen können, und werde daran arbeiten, anderen Anerkennung zu verschaffen und zu versuchen, ihn leicht zu halten.
Halten Sie die Codequalität so hoch wie möglich. Seien Sie so produktiv wie möglich. Geben Sie anderen Entwicklern Hilfe / Ratschläge / Ideen - wenn sie danach fragen. Es klingt für mich so, als ob die Codeüberprüfungen, die Sie haben, Treffen mit mehreren Personen sind. Ugh, wie demoralisierend. Ich würde sogar sagen, dass diese Art von Codeüberprüfungen tatsächlich schlimmer sind als Zeitverschwendung. kontraproduktiv für den Zusammenhalt des Teams sein. Nur wenige Leute nehmen Kritik gut auf. Fast niemand nimmt öffentliche Kritik gut auf. Die Codierung ist sehr persönlich. Es ist ein persönlicher Stil und ein persönliches Kunstwerk.
Du meinst, ich muss mich mit x anderen Leuten zusammensetzen, die mir sagen, wie ich meinen persönlichen Stil ändern soll und warum meine Kunst, mein Baby, nicht ihren Standards entspricht. Oh Freude! Ja, melde dich! Diese Art von Codeüberprüfungen war schon immer ein totes Pferd. Das Problem hier ist, dass Sie nobel versuchen, ein totes Pferd zum Laufen zu bringen, wie Sie es für richtig halten. Das kannst du nicht. Es ist tot. Es ist ein kaputtes System. Sie können nur eine Szene machen. Hören Sie auf, es zu schlagen, sitzen Sie ruhig und hören Sie auf die Bedürfnisse anderer. Dann sind Sie gut aufgestellt, um ihnen zu helfen. Wenn Sie ausgeführt werden, gewinnen Sie Freunde und Einfluss.
-1: Sicher, Sie sind möglicherweise nicht in der Lage, ihren Stil zu ändern, aber selbstgefällig zu sitzen, während sie die Qualität des Produkts beeinträchtigen, für das Sie verantwortlich sind? Furchtbar.
@Telastyn "Schaden" ist subjektiv. Jemand, der schlampigen Code schreibt, aber schnell gute Geschäftsfunktionen bereitstellt, wird ein Superstar für das Management sein, egal was Sie oder ich denken. Sagen Sie dieser Person oder dem Management, dass sie "das Produkt schädigt", und sehen Sie, wie viel Traktion Sie erhalten. Ich wette, Sie haben das gleiche Ergebnis wie beim Öffnen des Posters. Außerdem sage ich nicht, dass Sie selbstgefällig sitzen, sondern dass Sie sich hauptsächlich auf das konzentrieren, was unter Ihrer Kontrolle steht, und dass Sie die Bereitstellung von Kritik mit Sorgfalt und Einfühlungsvermögen behandeln ... konstruktiv, nachdenklich und professionell.
@BradThomas - Und Entwickler wissen, wie gut das langfristig funktionieren wird. Umso mehr Grund, mit Gleichaltrigen (ja, konstruktiv und professionell) auf Qualität zu drängen.
@BradThomas Ja, es ist eine dieser Arten von Codeüberprüfungen. Ich mag deine Analogie über das tote Pferd. Ich glaube, ich kann niemanden zwingen, zu lernen oder sich zu ändern, insb. wenn sie auf ihre Weise eingestellt sind. Ich bin damit einverstanden, dass Codierung ein kreativer Prozess ist und die Leute beleidigt werden, wenn Sie ihre Arbeit kritisieren. Die Art und Weise, wie das Codieren funktioniert (ein Teil des Codes wird von mehreren Personen berührt), legt nahe, dass es sich auch um einen kollaborativen Prozess handelt (aber häufig nicht, nur ppl-Code). Es ist wirklich seltsam, diese Mischung zu haben. Ich frage mich, ob andere in ihrer Branche darauf stoßen und wie sie damit umgehen (vielleicht wie Schriftsteller / Journalisten).
#2
+15
JB King
2014-03-19 05:24:43 UTC
view on stackexchange narkive permalink

Wie kann ich berechtigte Bedenken äußern und Kritik üben? (und lassen Sie sie berücksichtigen, akzeptieren und / oder letztendlich ansprechen)

Überlegen Sie, wie Sie dies ansprechen. Glauben Sie, dass es nur einen Weg gibt, Dinge zu tun, und wenn es nicht so ist, muss es falsch, arm oder suboptimal sein? Es kann viele Möglichkeiten geben, Dinge zu tun, und es kann sein, dass Sie die Perspektive eines anderen hier für einen Punkt nicht verstehen.

Überlegen Sie, wie gut Sie diese Gewohnheiten aus 7 Gewohnheiten hochwirksamer Menschen verwenden:

  Gewohnheit 1: Seien Sie proaktivHabit 2: Beginnen Sie mit dem Ende in MindHabit 3: Stellen Sie die ersten Dinge an die erste Stelle p> Beachten Sie, Gewohnheiten 2,4 und 5 für einige, die hier in Ihrer Umgebung möglicherweise eine Überlegung wert sind. Welches spezifische Ende möchten Sie, wenn Sie Bedenken äußern? Wie gut verstehen Sie die Kompromisse, Dinge auf verschiedene Arten zu tun? Einige Unternehmen müssen möglicherweise schwierige Entscheidungen treffen. Auch wenn Sie aus der akademischen Welt kommen, in der viel Zeit bleibt, um die Dinge gut zu machen, ist dies nicht unbedingt die Art und Weise, wie Unternehmen in der realen Welt arbeiten.  

Vielleicht habe ich bereits die Chance auf eine herzliche Zusammenarbeit mit einigen Entwicklern ruiniert. Wie ändere / behebe ich das?

Wie man Freunde gewinnt und Menschen beeinflusst hat einige Ideen, die Sie sorgfältig prüfen sollten:

Grundlegende Techniken im Umgang mit Menschen

  1. Kritisieren, verurteilen oder beschweren Sie sich nicht.
  2. Geben Sie ehrliche und aufrichtige Wertschätzung.
  3. Erwecken Sie bei der anderen Person einen eifrigen Wunsch.
  4. Zeigen Sie anderen niemals, dass Sie nicht daran interessiert sind, was sie zu sagen haben.
  5. ol>

    Sechs Möglichkeiten, Menschen zu mögen Sie

    1. werden wirklich interessiert an anderen Menschen.
    2. Lächeln.
    3. Denken Sie daran, dass der Name einer Person für diese Person der süßeste und wichtigste Klang in jeder Sprache ist.
    4. Seien Sie ein guter Zuhörer. Ermutigen Sie andere, über sich selbst zu sprechen.
    5. Sprechen Sie über das Interesse der anderen Person.
    6. Geben Sie der anderen Person das Gefühl, wichtig zu sein - und tun Sie es aufrichtig.
    7. ol>

      Zwölf Möglichkeiten, Menschen für Ihre Denkweise zu gewinnen

      1. Der einzige Weg, das Beste aus einem Argument herauszuholen, besteht darin, es zu vermeiden.
      2. Zeigen Sie Respekt vor dem anderen Meinungen der Person. Sagen Sie niemals "Sie liegen falsch".
      3. Wenn Sie sich irren, geben Sie es schnell und nachdrücklich zu.
      4. Beginnen Sie freundlich.
      5. Beginnen Sie mit Fragen, auf die die andere Person mit Ja antworten wird.
      6. Lassen Sie die andere Person viel reden.
      7. Lassen Sie die andere Person das Gefühl haben, dass die Idee ihre oder ihre ist.
      8. Versuchen Sie ehrlich, die Dinge aus der Sicht der anderen Person zu sehen.
      9. Seien Sie mit den Ideen und Wünschen der anderen Person sympathisch.
      10. Appellieren Sie an die edleren Motive.
      11. Dramatisieren Sie Ihre Ideen.
      12. Stellen Sie sich einer Herausforderung.
      13. ol>

        Seien Sie führend: So ändern Sie Menschen, ohne Beleidigungen zu erregen oder Ressentiments zu erregen

        1. Beginnen Sie mit Lob und ehrlicher Wertschätzung.
        2. Machen Sie indirekt auf die Fehler der Menschen aufmerksam.
        3. Sprechen Sie über Ihre eigenen Fehler, bevor Sie die andere Person kritisieren.
        4. Stellen Sie Fragen, anstatt direkte Befehle zu erteilen.
        5. Lassen Sie die andere Person das Gesicht wahren.
        6. Loben Sie jede Verbesserung.
        7. Geben Sie der anderen Person einen guten Ruf, dem sie gerecht werden kann.
        8. Verwenden Sie Ermutigung. Lassen Sie den Fehler leicht zu beheben erscheinen.
        9. Machen Sie die andere Person glücklich darüber, was Sie vorschlagen.
        10. ol>

Zeigen Sie jemals, wo die Dinge richtig laufen? Erkennen Sie jemals gute Arbeit, die andere leisten? Wenn nicht, könnte ich leicht erkennen, wo Sie viele Probleme verursachen, wenn Sie versuchen, Dinge einzubringen, ohne zu wissen, wie gut oder nicht so gut das für dieses Team und diese Situation ist. Einige Best Practices sind möglicherweise nicht immer großartig, da nicht an jedem Ort eine Umgebung vorhanden ist, in der Sie über ein scheinbar unbegrenztes Budget und Zeit verfügen, um Dinge mit der neuesten Technologie, großartigen Maschinen und ohne enge Fristen zu erledigen.

Kaufen Sie eine Kopie von Wie man Freunde gewinnt und Menschen beeinflusst und halten Sie sie in Reichweite des Klos oder eines ähnlichen Ortes.
@AnsisMalins Ich habe es vor ein paar Monaten gekauft, muss mich aber noch hinsetzen und es lesen (ein Teil von mir hat Angst vor ...)
#3
+10
Amy Blankenship
2014-03-19 22:48:03 UTC
view on stackexchange narkive permalink

Herzlichen Glückwunsch. Wenn Sie es nutzen können, haben Sie die Möglichkeit, Ihre Karriere in die Stratosphäre zu starten.

Welche Art von Dingen sehen Sie in den Lebensläufen hochqualifizierter Ingenieure? Könnten es Dinge sein, wie Praktiken in einem Team von Grund auf neu zu implementieren, Teamkollegen zu schulen usw.? Sie haben keine Gelegenheit, diese Dinge in einem Team zu tun, das bereits beim Joel-Test hohe Punktzahlen erzielt. Die Landung in einem Team von Leuten, die sich nicht um diese Dinge kümmern, ist ein Segen in der Verkleidung - es gibt all diese Dinge im Bereich Senior Engineering, die darauf warten, erledigt zu werden, und genau eine Person, die sich darum kümmert, sie zu tun p> Wenn Sie diese Gelegenheit nutzen möchten, müssen Sie Ihr Denken etwas anpassen.

  1. Stellen Sie fest, dass Ihre Teamkollegen sich nie so sehr um Codequalität und bewährte Methoden kümmern wie Sie tun es. Ihre Erwartungen wurden durch Websites wie diese geweckt, die implizieren, dass die meisten Entwickler sich ständig bemühen, das Neueste und Beste zu lernen und Dinge im Einklang mit "Best Practices" zu tun. Die Realität ist, dass die Dinge, die uns alle hier interessieren, nicht einmal auf dem Radar der überwiegenden Mehrheit der Programmierer registriert werden. Lernen Sie zu akzeptieren, dass Ihre Änderungen zunächst wahrscheinlich klein sind, aber jede Änderung, die die Dinge verbessert, ist von Bedeutung.
  2. Lernen Sie, über die POV darüber nachzudenken. Ja, theoretisch klingt es großartig, Dinge einfach von Grund auf neu zu schreiben, um eine gute Codequalität zu erzielen. Aber das Schreiben von schlechtem Code ist schwer , und Sie fordern sie auf, Stunden und Stunden des Wegwerfens wegzuwerfen. Darüber hinaus ist Ihr neuer Code nicht fehlerfrei, sodass ein vollständiger QS-Prozess überarbeitet werden muss. Selbst wenn Sie keine vollständige Neufassung befürworten, besteht die Natur des schlechten Codes darin, dass alles, was Sie in einem Bereich berühren, das gesamte Kartenhaus zum Erliegen bringen kann, sodass selbst das Refactoring ein hohes Risiko birgt. Ihre Erfahrung zeigt ihnen das Risiko, Dinge zu reparieren, aber nicht die Belohnungen.
  3. Ihr aktueller Ansatz funktioniert bereits (aus ihrer Sicht). Sie erfüllen bereits alle Erwartungen Das Management hat davon, ohne Ihre neuen Ideen zu verwenden. Denken Sie daran, Ihr Manager hat keine Ahnung, wer richtig und wer falsch ist. Er weiß jedoch, wer viel Umsatz generiert hat und wer nicht. Ich vermute, Sie könnten in diese letztere Kategorie fallen. Denken Sie auch daran, dass Ihr Manager, um eine Änderung zu unterstützen, sich auf die Idee einarbeiten muss, dass die Entwickler und Praktiken, die er die ganze Zeit unterstützt hat, falsch sind. Dies ist schwer für ihn, da er seine eigene Geschichte neu bewerten und die Geschichte der Menschen, die er wahrscheinlich mag, negativer beurteilen muss.
  4. ol>

    Hier sind einige Dinge, die Sie tun können, um zu bauen Vertrauen Sie und verbessern Sie Ihre eigene Situation.

    1. Wenn möglich, lassen Sie Ihre eigene Anwendung oder Ihr eigenes Subsystem arbeiten. Normalerweise macht es den Leuten nichts aus, wenn Sie sauberen Code in Ihrem eigenen Bereich implementieren - sie sind einfach nicht daran interessiert zu ändern, was sie tun. Legen Sie alle Ihre Enten in eine Reihe, damit Ihr Sandkasten zum Leuchten bereit ist, wenn jemand darauf schaut. Dokumentieren Sie alles, führen Sie Tests durch, wenn Sie können usw. Als ich dies zum ersten Mal tat, ging ich in den Urlaub - dies war nach dem angeblichen Liefertermin, aber vor einem neuen Termin - und hinterließ ein Handbuch für andere Entwickler benutze mein System. Während ich weg war, lief alles reibungslos. Darüber hinaus hat dieses Subsystem den Ruf, das zuverlässigste in der gesamten Anwendung zu sein.
    2. Finden Sie höfliche Wege, um Leute dazu zu bringen, Dinge richtig zu machen. Dies ist einfacher, wenn Sie über ein eigenes Subsystem oder eine eigene Anwendung verfügen. Als mein Chef beispielsweise sagte, "wir sollten wahrscheinlich über die Verwendung der Versionskontrolle nachdenken", versetzte ich alle meine Websites umgehend sowohl lokal als auch im Netzwerk in die Versionskontrolle, und die Benutzer mussten die Versionskontrolle verwenden, wenn sie wollten, dass ihre Updates weitergegeben werden zu allen Umgebungen. Wenn jemand kommentierte, dass etwas, das im Wiki hätte sein sollen, nicht richtig war, würde ich antworten, dass ich die relevanten Informationen dort nicht gefunden habe - und ich würde anbieten, sie hinzuzufügen.
    3. Sie müssen tatsächlich besser, schneller und fehlerfreier sein als Ihre Mitarbeiter. Ich habe unser gesamtes Framework in einer neuen Sprache umgeschrieben, und selbst während ich das tat, konnte ich aggressive Fristen einhalten und mein Framework hat Dinge getan, von denen das alte nie geträumt hat. Kurzfristig musste ich jedoch jedes Mal, wenn es einen Fehler im neuen Framework gab, den das alte Framework nicht hatte, unangenehme Fragen beantworten, warum. Langfristig hat sich herausgestellt, dass sich das Framework blitzschnell entwickelt und weitaus fehlerfreier ist. Die Herausforderung besteht jedoch darin, dass Sie und Ihr Framework so lange überleben.
    4. Lernen Sie die Frameworks kennen, in denen Sie sich schwach fühlen. Wenn Sie als Architekt auftreten möchten (und um dieser Herausforderung zu begegnen, müssen Sie dies werden), müssen Sie die dahinter stehenden Konzepte verstehen. Möglicherweise möchten Sie sie "wie sie sind" verwenden, aber wenn Sie Ihre eigenen Architekturlösungen erstellen möchten, müssen Sie verstehen, warum vorhandene funktionieren.
    5. Beachten Sie, dass Sie wahrscheinlich weitermachen müssen um den vollen Nutzen aus dem zu ziehen, was Sie erreichen werden. Da sich Ihre Teamkollegen wahrscheinlich nie um die Codequalität per se kümmern werden, ist es unwahrscheinlich, dass Sie aufgrund von Leistungen in dem Bereich, in dem Sie sich befinden, geschätzt oder entschädigt werden. Was Sie jetzt tun, ist, wertvolle Erfahrungen zu sammeln, die Sie mit Glück gesammelt haben, und diese Erfahrungen werden dann in Ihren Lebenslauf aufgenommen, um Ihnen mehr Geld und vor allem einen Platz in einem Team mit denselben Werten zu verdienen Sie tun es.
    6. ol>

      Siehe auch meine Antwort in Wie man konstruktiv ist und Probleme in einer unkonstruktiven Umgebung löst.

Ich mag Ihre Antwort wirklich, aber es scheint mir, dass dies nur gilt, wenn Ihre Arbeit relativ isoliert von der Arbeit anderer ist. Wenn zum Beispiel jemand die Konstanz-Korrektheit nicht respektiert, dies aber tut, ist es jedes Mal, wenn Sie den Code dieser anderen Person verwenden, mehr Arbeit für Sie und verringert die Qualität Ihres Codes, da Sie Konstanz oder etwas Äquivalentes wegwerfen müssten. Würden Sie immer noch nicht versuchen, die Art und Weise zu ändern, in der andere Personen codieren?
Es geht darum, Bereiche herauszuarbeiten, die "Ihnen" gehören, und mithilfe einer guten Kapselung die Auswirkungen des schlechten Codes zu minimieren. Bei dem Job, bei dem ich oben über Urlaub gesprochen habe, beruhte der gesamte Code auf einer wirklich hässlichen Grundlage von Singletons und Statics. Mir wurde das Eigentum an einem Subsystem übertragen, und ich habe es so umgeschrieben, dass genau ein Ort über all diese Hässlichkeit Bescheid wusste, und der Rest des Codes tat so, als wäre er sehr sauber und entkoppelt. Wann immer mir ein erheblicher Arbeitsaufwand zugewiesen wurde, würde ich ihn, wenn möglich, umschreiben, um den Kontakt mit dem "ick" zu minimieren.
Ich verstehe, habe nie so über das Problem nachgedacht! Ich werde es das nächste Mal versuchen!
#4
+4
TooTone
2014-03-19 05:17:52 UTC
view on stackexchange narkive permalink

Es scheint, als hätten Sie beim Schreiben der Frage herausgefunden, dass die Dinge, die Sie getan haben, nicht funktionieren. Also, wenn Sie es noch nicht getan haben, hören Sie auf, sie zu tun. Es spielt keine Rolle, ob Sie technisch richtig lagen oder ob das, was Sie getan haben, in einer anderen Umgebung funktioniert hat: Es war nicht produktiv, also hören Sie auf.

Beziehen Sie sich meiner Meinung nach auf Ihre Fragen, unabhängig davon In Bezug auf die Rechte und das Unrecht der Situation müssen Sie eine Weile schweigen, Ihren Kollegen und Ihrem Vorgesetzten zuhören und sich als jemand etablieren, der erfolgreich an dem arbeiten kann, worum er gebeten wird, und der produktive Arbeitsbeziehungen mit anderen aufbauen kann Teammitglieder. Wenn viel gearbeitet wird, wird wahrscheinlich erwartet, dass die Teammitglieder die Ladung übernehmen und das Boot nicht schaukeln.

Wie kann ich berechtigte Bedenken äußern und Kritik üben? (und lassen Sie sie berücksichtigen, akzeptieren und / oder letztendlich ansprechen)

Stellen Sie sich zuerst auf. Sie können Ihre technischen Ideen natürlich nicht an Ihre Kollegen weitergeben und das gesamte Team beeinflussen, sondern sie so oft wie möglich in Ihrer täglichen Arbeit einsetzen. Wenn Sie zeigen, dass Sie Ihre Arbeit schneller und zuverlässiger erledigen als Ihre Kollegen, sind Sie in Zukunft in einer guten Position, um Ihre Ideen zu vermitteln.

Ich hatte kürzlich eine ähnliche Erfahrung, bei der ich meinen Manager nicht überzeugen konnte, meine Ideen zu übernehmen, sondern sie selbst verwendete. Am Ende des Projekts bemerkte der Manager, dass das Projekt gut verlaufen war, und kommentierte darauf (ohne dass ich frage). Wenn Ihr Vorgesetzter oder Ihre Kollegen Ihre gute Arbeit nicht bemerken und dann nicht bereit sind, darüber zu diskutieren, haben Sie keine Hoffnung darauf, dass Ihre Ideen als egal angesehen werden.

Vielleicht Ich habe bereits die Chance auf eine herzliche Zusammenarbeit mit einigen Entwicklern ruiniert. Wie ändere / behebe ich das? (Wie andere mich wahrnehmen, hören Sie mir noch einmal zu)

Das bezweifle ich. Die meisten Menschen wollen nur Kollegen, die ihren Job machen und mit denen sie auskommen können. Wenn sich herausstellt, dass Sie aus Sicht Ihrer Kollegen beides sind, sehe ich kein Problem. Der Schlüssel ist, ob Sie aufhören können zu reden und anfangen zuzuhören. Ich mache noch einmal kein Urteil über die technischen Rechte und das Unrecht der Situation. Wenn Sie mit Ihren technischen Ideen Recht haben, können Sie in anderen Unternehmen erfolgreich sein.

Mit Blick auf die Zukunft ist meiner Meinung nach eine wichtige Frage, wie viel Sie lernen. Nehmen wir an, Sie etablieren sich, hören auf zu reden und hören mehr zu. Wie viel lernen Sie dann von Ihren erfahreneren Kollegen, technisch und in Bezug auf die Art und Weise, wie Projekte verwaltet werden, wie Geschäfte getätigt werden usw.? Sind Sie dann in der Lage, produktive Diskussionen mit Kollegen über die von Ihnen geleistete Arbeit und schließlich über die Arbeit des gesamten Teams mit Diskussionen zu führen, bei denen Sie alle etwas lernen? ?

Als ich sagte, dass Ihre Ideen mit "Traue dem Internet nicht" und "Erfahrung" konterkariert wurden, fiel mir in Ihrem Beitrag etwas auf. Anscheinend haben Sie viele Interessen und Ideen und möchten in einem leistungsstarken Team sein. Wenn Sie sich nach der Anpassung Ihrer Talk-Listen-Balance nicht in einer Umgebung befinden, in der eine ehrliche und offene Diskussion über Ideen über Jahre hinweg geschätzt wird, ist dies möglicherweise nicht der richtige Ort für Sie. Natürlich ist es in der Zwischenzeit sinnvoll, mit der Arbeit und Ihren Kollegen fortzufahren.

(Ich habe bewusst versucht, diese Antwort angesichts des Kommentars von Pheonixblade9 unter nicht softwarespezifisch zu machen die Frage.)

#5
+4
NotMe
2014-03-20 07:38:14 UTC
view on stackexchange narkive permalink

Bei zwei Gelegenheiten wurde ein Problem zwischen mir und einem anderen Entwickler zu hitzig und konfrontativ. Ich baue meine Standpunkte auf, indem ich online nach den besten Codierungsmethoden recherchiere und ihnen E-Mails schreibe und zur Diskussion einlade Alles, was mit "Traue dem Internet nicht" und "Erfahrung" konterkariert werden muss.

Eines der Dinge, die eine neue Person, die in eine Branche eintritt, lernen muss, ist Demut. Die Aussagen "Traue dem Internet nicht" und "Erfahrung" sind tatsächlich völlig gültig, ob du das noch weißt oder nicht. Genauer gesagt, Sie scheinen Köpfe gegen Menschen zu stoßen, die viel mehr Erfahrung haben als Sie ... Sie werden es einfach nicht mögen, wenn eine viel jüngere Person in ihr Gesicht kommt.

In ihren Augen, Sie Haben Sie nicht die "Kampfnarben", die entstehen, wenn Sie eine unheilige Anzahl von späten Nächten damit verbringen, Ihren Kopf gegen eine Wand zu schlagen und zu versuchen, etwas zu reparieren, das einfach hätte funktionieren sollen. Sie haben wahrscheinlich stundenlang nicht dort gesessen und sich einen Code wie var x = 1 + 1; angesehen und waren verblüfft darüber, warum das Programm darauf besteht, dass x tatsächlich gleich 3 ist. Sobald Sie fertig sind Dies nicht nur einmal, sondern über einen Zeitraum von Jahren, dann stellen Sie fest, dass das Internet oft falsch ist. Dass die vorgestellten Ideen und Konzepte gute Lösungen sein könnten ... aber in sehr spezifischen Situationen.

Ich weiß, dass ich eine große Anzahl von Nachwuchskräften gesehen habe, die sich beeilen, um das Neueste umzusetzen, worüber sie gelesen haben. oft von einem anderen Junior geschrieben, ohne die Konsequenzen zu verstehen. Ich habe auch einige späte Nächte damit verbracht, ein Projekt zu retten, als ich gerufen wurde, um das Chaos zu beseitigen. Zu diesem Zweck habe ich eine Richtlinie entwickelt: "Wenn Sie es nicht im Klartext erklären und mich davon überzeugen können, dass dies das vor uns liegende Problem löst, verstehen Sie es nicht genug und gehören daher nicht dazu."

Das heißt, der Schlüssel hier liegt wirklich darin, wie Sie die Dinge angehen. Einem Entwickler, der mehrmals in der Nähe war, zu sagen, dass er falsch liegt, wird einfach nie funktionieren. Der Versuch, dies mit einem Link zu einem Artikel zu rechtfertigen oder sogar zu sagen "Martin Fowler sagte ...", funktioniert wieder nicht. Erfahrene Leute lernen, einen Code oder einen Ansatz nach seinem Verdienst zu beurteilen, nicht danach, wer der Bote ist.

Stattdessen müssen Sie dies aus einer völlig anderen Richtung angehen. Lassen Sie sie nämlich Ihnen beibringen, warum Ihre Idee falsch ist. Dies ist im Wesentlichen eine umgekehrte Psychologie, und wenn Sie sie bitten, auf Ihre Mängel hinzuweisen (was sie gerne tun werden), wird eines von zwei Dingen passieren. Entweder werden sie erkennen, dass ihr Ansatz schlecht ist, und werden Ihnen am Ende zustimmen, oder sie werden Sie darüber aufklären, warum Sie falsch liegen. Beides sollte eine willkommene Situation sein.

Sehen Sie sich die folgenden Gespräche an:

Schlechter Weg

Sie :: "Bob, du hättest das Inversion of Control-Muster verwenden sollen
hier, sagt Martin Fowler in seinem Artikel unter www.wherever.com. Was du getan hast, muss komplett neu geschrieben werden."
Bob :: "Es funktioniert einwandfrei. Haben Sie keine Klasse, um Refactor zu werden? Vielleicht CS 101?"
Sie :: "Aber er sagte. .. "
Bob ::" Sei weg, welp! " abgesehen von Jim: "Was bringen sie diesen Kindern bei?"

Nicht gerade ein guter Ansatz, da Bob sofort in die Defensive gerät. Außerdem zeigt es, dass Ihnen einfach die Erfahrung und damit die Glaubwürdigkeit fehlt, indem Sie nur einen Verweis auf die Meinung eines anderen verwenden, um Ihre Aussage zu rechtfertigen. Wenn Sie jedoch so etwas getan haben:

Besser

Sie :: "Bob, was wäre das? Sie denken darüber nach, hier ein IoC-Muster zu verwenden? Würde dies nicht das Testen erleichtern? Wir könnten einen Konfigurationsparameter festlegen, damit wir wissen, in welcher Umgebung es sich befindet, und all diesen anderen Code entfernen. "
Bob :: "Vielleicht ... Natürlich verstehen nicht viele Leute, wie man IoC richtig macht, und haben normalerweise wirklich schwer lesbaren Code. In diesem Fall hätte ich lieber etwas, das war leichter zu verstehen."

Viel besserer Ansatz. Sie haben einen Vorschlag gemacht und einen klaren Grund dafür angegeben, warum dies gilt, während Sie auf Bobs Erfahrung zurückgreifen. Anstatt in der Defensive zu sein, ist Bob jetzt verlobt und wird natürlich versuchen, Sie zu "erziehen". Noch wichtiger ist, dass Sie die Möglichkeit haben, detailliertere Angaben zu machen, um seine Besorgnis zu zerstreuen. Während der Diskussion könnte er seine Meinung ändern oder Sie werden einige der Fallstricke mit dem, was Sie lesen, lernen. In jedem Fall sollten Sie etwas Wichtiges lernen.

Um die Probleme an diesem Punkt zu beheben, müssen Sie drei Dinge tun. Hören Sie zunächst auf, das Internet zu zitieren. Zweitens Fragen stellen, keine Aussagen machen. Drittens wissen Sie, wovon Sie sprechen, bevor Sie es ansprechen. Dies bedeutet, dass Sie tatsächlich mit dieser "Codierungspraxis" spielen und sie in einem Testprojekt verwenden, damit Sie wissen, was daran falsch ist.

@Chad: True. Ich werde das ein bisschen ändern.
Zu Ihrer Information - Ich habe in diesem Beitrag Martin Fowler (echte Person) ausgewählt. Dies sollte in keiner Weise als geringfügig gegen ihn oder gar als Meinung zu seiner Arbeit angesehen werden. Er ist sicherlich ein Oldtimer mit vielen wirklich guten Ideen. Ich habe seinen Namen einfach als echten Hinweis auf eine "Internet-Persönlichkeit" verwendet, die Leute in der Programmierbranche gerne zitieren.
Tolle Antwort - Sie haben mich dazu gebracht, mehr Austausch zwischen 'OP', Bob und Jim zu lesen! :-)
@EleventhDoctor: http://thecodelesscode.com/contents ist wahrscheinlich das Beste, das ich je gesehen habe.
#6
  0
user18099
2014-03-19 20:33:21 UTC
view on stackexchange narkive permalink

Versuchen Sie es aus einer anderen Perspektive. Wenn Sie nicht in der Lage sind zu gewinnen, verursachen Sie keine Reibung.

Sie können Ihr Alter nicht ändern Sachverstand. Das steht an erster Stelle.

Es spielt keine Rolle, was Sie von Ihrem Können halten oder wie die Qualität Ihrer Arbeit ist. Weil Kommunikation die Antwort ist, die Sie erhalten. Für Ihr spezielles Problem ist es wichtig, was sie über Sie denken.

Lösen Sie das zuerst. Und es wird viel einfacher sein, sich für Verbesserungen einzusetzen, die Sie für angemessen halten.

#7
  0
Tasos
2014-03-19 20:47:24 UTC
view on stackexchange narkive permalink

Zu Ihren Fragen:

  1. Das braucht Zeit, beeilen Sie sich nicht und bleiben Sie ruhig.

    Es geht darum, die richtige Zeit und die richtige Zeit zu finden der richtige Ort, um solche Fragen zu stellen. Niemand mag eine kluge Person und die Leute hören nicht zu und ignorieren nicht, was Sie sagen, weil sie glauben, dass Sie eine sind.

    In einer Arbeitsumgebung haben Sie zwei Jobs. Die Arbeit, die Sie täglich erledigen, und die zweite ist die, bei der Sie Beziehungen und Vertrauen aufbauen.

    Wenn Sie also gut in Ihrem Job sind und respektvoll, möchten Sie ein Problem ohne das ansprechen Respekt und Unterstützung Ihrer Mitarbeiter werden höchstwahrscheinlich niemand zuhören und Sie sind der Ungewöhnliche.

    Der beste Rat, den ich sagen kann, ist Geduld. Sie haben versucht, ein Problem anzusprechen, und es lief nicht wie geplant. Machen Sie also eine Verschnaufpause und lassen Sie sich nicht stören. Arbeiten Sie langsam an einem anderen taktischen Ansatz, wenn Sie das Problem so stark ansprechen möchten. Vielleicht sehen andere Leute das auch so, Sie müssen sie nur finden. Es braucht Zeit.

  2. Laden Sie diese Entwickler zu einem abendlichen Drink ein. Sag diesmal, es liegt an dir. Die meisten der besten Arbeitsbeziehungen finden außerhalb des Büros statt. Trinken Sie ein paar Drinks und entspannen Sie sich. Sie werden feststellen, dass die Leute besser zuhören, wenn sie nicht im Büro sind und entspannt. Besonders in einer Bar. Sprechen Sie über gängige Dinge wie Sport oder Filme oder Haustiere oder was auch immer. Die Leute werden viel besser mit dir umgehen.

    Vielleicht sprechen Sie nach einiger Zeit, wenn Sie wieder etwas von der Arbeit trinken gehen, über das Problem mit dem Codierungsstandard. Nach meiner Erfahrung werden Sie eine bessere Veränderung für jemanden ertragen, der zuhört, was Sie zu sagen haben.

  3. ol>

    Viel Glück

#8
  0
Hogan
2014-03-19 23:02:39 UTC
view on stackexchange narkive permalink

Möglicherweise irren Sie sich in Bezug auf Ihre Bedenken, und die von Ihnen angesprochenen Probleme mit der Codequalität wurden von informierten und erfahrenen Ingenieuren speziell ausgewählt.

Stellen Sie sich das folgende Szenario vor:

Ein Team steht unter dem Druck des Managements, ein Projekt zu beschleunigen, und aufgrund dieses Drucks verkürzt es die Design- und Entwicklungszeit.
Um die Wunde mit Salz zu versorgen, stellt das Management billige unerfahrene Teammitglieder ein, mit der Erwartung, dass sich dieser Wille verbessern wird Teamproduktivität, aber alles, was dieses neue Mitglied tut, ist sich über die Qualität des Codes und die Designauswahl zu beschweren.

Ich sage nicht, dass dies Ihre Geschichte ist, aber es könnte sein.

Denken Sie daran, dass dies Menschen sind, mit denen Sie jeden Tag arbeiten müssen - seien Sie respektvoll und rücksichtsvoll, die Geschichte enthält möglicherweise mehr - Sie werden auf lange Sicht besser bedient und lernen mehr wenn Sie schnell loben und nicht schnell kritisieren.



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