Wie ist mit unprofessionellem Verhalten von Praktikanten umzugehen?

Ich bin Softwareentwickler in einem kleinen Unternehmen (ein paar Dutzend Mitarbeiter). Wir haben ein Sommerpraktikum am laufen. Die Praktikanten sind Studenten ohne Berufserfahrung und mit eher Grundkenntnissen der Programmiersprache. (Bei der Auswahl der Praktikanten war ich nicht beteiligt). Ein Teil der Praktikanten wird zukünftig aufgrund ihrer Leistung im Unternehmen übernommen.

Die Praktikanten entwickeln eine einfache Anwendung (nicht für das Unternehmen, kein Produktionscode), nur um einige Grundprinzipien zu erhalten und sich kennenzulernen, bevor sie sich komplexeren Dingen zuwenden.

Ich helfe ihnen täglich bei der Entwicklung (schnelle Besprechungen, um Probleme zu lösen, die sie nicht selbst lösen können) und mache Code-Reviews. Eines der Hauptprobleme, das sie haben, ist, dass sie sich nicht an Namenskonventionen halten und schlechte und kurze Namen für Methoden erstellen (wie convert). Natürlich habe ich ihnen erklärt, dass die richtige Benennung sehr wichtig ist, dass sie sich nicht scheuen sollten, längere, aussagekräftige Methodennamen (wie convertGallonsToMilliliters) zu verwenden. Unglücklicherweise entschieden sich einige von ihnen (und ich weiß wer, weil sie die Versionskontrolle verwenden) offenbar dazu, etwas Spaß zu haben (oder sich über mich lustig zu machen) und fingen an, dumme Methodennamen zu erstellen wie convertToMillilitersBecauseIAmUsingSuchCleanCode- nicht ein einziges Vorkommen, aber ein paar.

Wie soll ich darauf reagieren? Ich weiß, dass es kein Produktionscode ist, aber ich verbringe ziemlich viel Zeit damit, ihn zu überprüfen, und ich tue mein Bestes, um den Praktikanten beim Lernen zu helfen und sie Best Practices in Bezug auf sauberen Code aufgreifen zu lassen.

Soll ich durch reagieren

  • darüber lachen ("Ja, es ist lustig, aber bitte entferne es")
  • nur höflich darum bitten, es zu entfernen
  • sagen, dass ich es nicht mag, wenn jemand meine Zeit verschwendet und er die Codeüberprüfung ernster nehmen sollte

Ich weiß, es ist wahrscheinlich keine so große Sache, aber es ist das erste Mal, dass ich den Praktikanten helfe, und ich würde gerne wissen, wie man mit einer solchen Situation richtig umgeht. Ihre Leistung während des Praktikums wirkt sich jedoch auf ihre Einstellungschancen aus, und Situationen wie diese können später eine Rolle spielen. Oder sollte ich ihnen etwas in dieser Richtung sagen, um sie motivierter zu machen, tatsächlich etwas zu lernen?


EDIT: Vielen Dank für Ihre tollen Antworten. Ich habe das Thema mit meinem Vorgesetzten besprochen und mit den Praktikanten gesprochen. Ich schrieb den Namen der Methode auf das Whiteboard und fragte, ob sie meinen, dass es ein guter Name sei. Ich habe mit ihnen auch noch einmal kurz den Zweck von Code-Reviews besprochen. Ich sagte ihnen, dass wir in echten Projekten externe Firmen haben, die Code-Review-Audits durchführen – diese Art von Witz könnte sie später wirklich in Schwierigkeiten bringen. Also ist es eigentlich besser für sie, diese Lektion während des Praktikums zu lernen.

Nachdem wir uns unterhalten hatten, gaben sie zu, dass sie solchen Code nicht begehen sollten. Sie sagten mir auch, dass sie dankbar für die Zeit sind, die ich für die Überprüfung ihres Codes aufgewendet habe, und für meine Hilfe. Aber das Beste daran ist, dass sich ihre Arbeitsqualität seitdem wirklich verbessert hat. Tatsächlich hat der Typ, der den Witz begangen hat, damit begonnen, den besten Code in der Gruppe zu liefern - ich sehe, dass er (und auch andere Praktikanten) meine Notizen aus der Codeüberprüfung jetzt viel ernster nehmen.

Kommentare sind nicht für längere Diskussionen gedacht; Diese Konversation wurde in den Chat verschoben .
Eine potenziell urkomische Option: Lassen Sie einen Obfuscator über ihren Code laufen und sagen Sie ihnen, dass kurze Variablennamen so aussehen, wenn Sie Code wiederholen, der vor 6 Monaten geschrieben wurde.
Haben Sie jemals den Linux-Kernel-Code gesehen? Schauen Sie sich das zum Beispiel genau an. Überraschenderweise funktioniert es, und zwar so gut, dass es weltweit eingesetzt wird. Ich kenne die Details des Projekts, an dem sie gearbeitet haben, nicht, aber im Allgemeinen ist Camel Case nicht der einzig gültige Namensstil, und ich kann ihre Frustration verstehen, wenn Sie versuchen, Ihre eigenen persönlichen Vorlieben im Codierungsstil durchzusetzen, ohne es zu erklären warum der von Ihnen vorgeschlagene Stil objektiv besser für ihr Projekt wäre.
Als Einschränkung, das ist der Grund, warum Sie keine neuen Mitarbeiter bekommen, um neuen Code zu erstellen. Sie bringen sie dazu, Code zu warten, und dort werden sie wirklich lernen, warum Sie Programmierstandards ernst nehmen.
Bedenken Sie die Möglichkeit, dass Sie mindestens genauso falsch liegen wie Ihre Praktikanten, und dass der Versuch, Informationen, die in Kommentaren stehen sollten, in sesquipedale Variablennamen zu stopfen, der Lesbarkeit genauso schaden kann.
Für das, was es wert ist, fand ich Ihr Beispiel eigentlich ziemlich lustig. Wenn sie so sind, denke ich, dass es den Schlag abmildern könnte, ihnen zu sagen, dass es nicht professionell ist und dass sie es in Zukunft vermeiden müssen, wenn Sie sie wissen lassen, dass Sie den Humor genossen haben. Es wird dir auch einige Chillness-/Coolness-Punkte einbringen, die wahrscheinlich dazu beitragen werden, dass sie dir tatsächlich zuhören. (Machen Sie jedoch deutlich, dass Sie solchen Humor nicht noch einmal genießen werden.)
Off Topic, aber was mir aufgefallen ist: "Ein Teil der Praktikanten wird in Zukunft aufgrund ihrer Leistung im Unternehmen übernommen." Nein, Sie werden einigen der Praktikanten ein Angebot machen, im Unternehmen zu arbeiten. Sie sollten nicht davon ausgehen, dass sie Ihr Angebot annehmen werden.
Offtopic ... aber bin ich der einzige, der das Gefühl converthat, dass ein VIEL saubererer Name für eine solche Methode ist als convertGallonsToMilliliters(natürlich mit der richtigen Klasse und dem richtigen Kontext).
@jamesqf Die einzige Information, die in den Kommentaren stehen sollte , ist das Warum , nicht das Was . Wenn Ihr Code nicht klar zeigt, was er tut, ist es schlechter Code, und schlechter Code kann nicht repariert werden, indem Sie Kommentare darauf werfen, zumal die Wahrscheinlichkeit, dass Kommentare aktualisiert werden, noch geringer ist als die Wahrscheinlichkeit, dass Code aktualisiert wird.
@PriiduNeemre Wenn convertin Ihrem Code Dutzende von Methoden herumschwirren (und ja, das haben Sie nie ... wenn Sie anfangen, aber bald werden Sie es tun), wird es schwierig, sofort zu erkennen, welche dies ist. Indem Sie es klar benennen oder dies auf andere Weise verdeutlichen, können Sie die Komplexität des Lesens reduzieren. Natürlich ist sowas Gallons.of( x ).convertTo( Unit.Milliliters)auch eine Möglichkeit. Nur wenn Sie sich zu 110% sicher sind, dass dies die einzige Konvertierung sein wird, die jemals in Ihrem Code durchgeführt wurde ... Aber selbst dann, nur wenn der Kontext darum herum klar macht, worum es bei dieser Konvertierung geht.
@PriiduNeemre: Ich nehme an, die Leute, die die Software für Mars Climate Orbiter geschrieben haben, sind davon ausgegangen, dass sie auch sauberen Code in einem klar definierten Kontext schreiben.
Fügen Sie dem Projekt eine neue Methode hinzu, um sie zu demonstrieren. FireEmployee(string employeeName, string reason) und fügen Sie einen Einheitentest hinzu, der die Methode mit dem Namen des problematischen Mitarbeiters und dem Grund aufruft, der erklärt, was er falsch gemacht hat. Zeigen Sie, dass dieser Test besteht und bereit ist, live zu gehen ;)
@FlorianSchaetz: Tatsächlich hatte ich so etwas wie Ihr zweites Beispiel im Sinn. IMHO ist es wichtig, beschreibende Namen nicht nur auf Methodenebene, sondern auch auf Klassen- und Variablenebene zu haben ( z . B. . DtoAssembler.assemble(customer)statt CustomerHelper.assembleCustomerToCustomerDto(entity), obwohl dies vielleicht nicht das beste Beispiel ist). Wenn Sie das Gefühl haben, dass Sie ein einfaches convertzu solchen Ausmaßen aufblähen müssen, ist es wahrscheinlich zunächst an der falschen Stelle. Wie auch immer, das wagt sich wahrscheinlich zu weit von der ursprünglichen Frage ab :).
@undercat Was soll in der Linux-Quelle zu sehen sein?
@undercat macht hier einen wichtigen Punkt. Es gibt eine lange Tradition respektlosen Humors, der im Quellcode verborgen ist; Die Behauptung, dies sei unprofessionell, ist ein lokaler Standard, kein universeller.
Ich stimme Mehrdad nicht zu. Wir reden von Professionalität? Warum sollten Sie Zeit damit verbringen, den Respekt Ihrer Praktikanten zu erlangen, damit sie Ihnen zuhören? Dies ist ein Testgelände, sie sollten Ihren Respekt bekommen. Ich verstehe, dass es die Kommunikation definitiv ruinieren kann, ein Verfechter zu sein, aber ich denke, dass es nicht anwendbar ist, eine Anleitung zu geben. Wenn sie Ihre Anleitung nicht befolgen, wenn sie nicht auf Code-Reviews reagieren, ist das nicht professionell. Der Humor wäre nicht so wichtig, wenn er nicht herablassend wäre.
Außerdem sollten Sie sie nicht zum Lernen motivieren müssen. Ihre Ambitionen liegen in ihrer Verantwortung. Wenn du etwas willst, hol es dir. Nur weil du an irgendeiner Universität studiert hast, einen Abschluss gemacht hast, ein Praktikum ergattert hast, spielt es für deine Karriere keine Rolle, es sei denn, du ergreifst darüber hinaus Eigeninitiative. Sie sollten sich keine Sorgen um Ihren Status unter ihnen machen müssen, Sie sollten nur deutlich machen, dass sie ihr eigenes Schicksal wählen.
@CodeSeeker wahrscheinlich der Kommentar in Zeile 9
Diese Frage ist nicht "Sollten Methoden lange oder kurze Namen haben?". Es ist "Was mache ich, wenn Kollegen dumme Witze in den Quellcode einbauen?"
Ist das wirklich ein gutes Beispiel? Das Verb allein, convert, sollte der Funktionsname sein, und die Details sind Teil der Argumenttypen. Vielleicht auto result= convert<mililiters>(original); where ist das Original vom Typ gallons. IAC-Einheiten sollten starke Typen sein und Operationen sollten für die zugrunde liegende abstrakte Menge *nicht spezifisch für bestimmte Einheiten sein.
Woher weißt du, dass sie es getan haben, um unhöflich zu sein? Vielleicht hat der Praktikant es getan, um Ihnen ausdrücklich zu zeigen, dass er zugehört hat, was Sie gesagt haben, und verstanden hat, warum Sie es gesagt haben.
Ich bin Entwickler mit mehr als zehn Jahren Berufserfahrung. Wenn ich im Code Witze machen muss, mache ich das in den Daten für Komponententests. Ich gebe Unit-Test-Kunden witzige Straßen- oder Nachnamen, ich wähle Out-of-Domain-Produkte für meine Tests aus, wie Kettensägen oder Mondraketen. Mein letzter Auszubildender wählte männliche Marvel- und DC-Charaktere als Unit-Test-Benutzer für sein Projekt aus, komplett mit E-Mail-Adressen und die Passwörter sind die Namen ihrer Freundinnen. Er hat diesen Plan durchgezogen. Ich fand es klug und urkomisch, und ich ermutigte es. Es gibt einen Platz zum Spaß, aber nicht wie in der Frage
Einfache Antwort: Planen Sie eine Codeüberprüfung. Teil des normalen Software-Entwicklungszyklus in den meisten Software-Shops.
Wechseln Sie convertToMillilitersBecauseIAmUsingSuchCleanCodezu convertToMillilitersBecauseImUsingSuchCleanCodeund warten Sie auf einen NoMethodError.
Die akzeptierte Antwort mit der im Kommentar zu dieser Antwort vorgenommenen Anpassung @inadäquater Code ist der richtige Weg. Stellen Sie außerdem keine Praktikanten ein, die sich so verhalten.
Gruppentreffen und dann die Worte „Schau mal, du kleiner Rotz – das ist kein College mehr, das ist die reale Welt. Und in der realen Welt führt so ein Unsinn dazu, dass Leute gefeuert werden.
@Florian Schaetz: Wenn Ihr Code deutlich zeigt, was er tut, arbeiten Sie nicht an sehr komplizierten Problemen :-) Versuchen Sie, beispielsweise einen eikonalen Gleichungslöser zu implementieren, den Sie aus dem Code verstehen können. Die Verwendung wirklich langer Variablennamen hilft nicht. In der Tat wird es weh tun, wenn Sie sich auf die Gleichungen in der Originalarbeit beziehen.
@jamesqf Schreiben Sie einen eikonalen Gleichungslöser, bei dem die Dokumentation gut in den Code passen kann. Es wird nicht. In diesem Fall müssen Sie in jedem Fall einfach auf das Originalpapier verweisen. Aber was Sie tun können, ist, den gesamten Solver so zu verpacken, dass klar ist, was er tut, selbst wenn das „Wie“ nur von „Mathematik“ über den Code selbst beantwortet werden kann.
Lehnen Sie die PR mit einer kurzen Begründung ab. Akzeptieren Sie keine zukünftigen PRs, die diese Art von Problemen enthalten.
Einfach ausgedrückt, das sind diejenigen, die Sie nicht einstellen werden. Ende der Geschichte.
Keine Ahnung, ich persönlich fand das lustig. Ich sehe nichts Falsches an einem frechen Sinn für Humor. Alles, was es zeigt, ist, dass sie den Nutzen geeigneter Funktions-/Variablennamen nicht wirklich verstehen - und als Praktikanten wird dies erwartet. Ich denke, es zeugt von schlechtem Urteilsvermögen, dies persönlich zu nehmen und sie nicht auf dieser Grundlage einzustellen.
Wenn das das Schlimmste an ihrem Code ist, hast du ein paar wirklich tolle Praktikanten ;) .
Sie sehen wahrscheinlich keinen Sinn darin, Eigennamen zu verwenden. Dies geschieht normalerweise viel später und mit Erfahrung. Wenn dieses Projekt bedeutungslos ist, lass sie Spaß haben. Wenn das Projekt wirklich wichtig ist, beziehen Sie die Personen ein, die in das Projekt involviert sind, und führen Sie ein Gespräch darüber, wie dieser Code in Zukunft von den Teammitgliedern gepflegt wird.
@PriiduNeemre Du bist nicht der Einzige, der auf den Upvotes zu deinem Kommentar basiert, aber ich stimme dir von ganzem Herzen nicht zu. Eine bessere Benennung ist eine der wichtigsten Methoden, um Code lesbarer zu machen. Es sei denn, der Klassenname ist GallonsToMillilitersConverter, Convertist ein schrecklicher Methodenname.
@EdmundReed Ich stimme voll und ganz zu, Dinge nicht persönlich zu nehmen. Es muss nicht sein. Siehe meine Antwort auf dieser Seite und die Kommentare.
@CodeSeeker: hast du überhaupt meinen anderen Kommentar gelesen (und den von @FlorianSchaetz)?
@PriiduNeemre Ich habe es früher gelesen, allerdings nicht zum Zeitpunkt des Kommentars. Ich verstehe Ihren Standpunkt, wirklich, aber in manchen Fällen muss Software nicht überarbeitet werden. Manchmal brauchen Sie nur ConvertGallonsToMilliliters und es gibt keinen Platz, um einen ganzen Kontext zu erstellen, in dem die Konvertierung zu einem angemessenen Anliegen auf Domänenebene befördert werden kann. Mein Punkt ist, dass es falsch ist, einen solchen Namen einfach falsch zu nennen. Es könnte für einen bestimmten Kontext richtig sein.
@CodeSeeker: Gute Argumentation, damit kann ich leben :). Um ehrlich zu sein, habe ich sowieso nicht wirklich versucht, eine pauschale Aussage zu machen ... Ich denke, es ist ein bisschen auf die provokative Seite geraten.
Ich verstehe nicht, warum das „Kennenlernen“ bei den Praktikanten überhaupt ein Faktor ist. Sie sind nicht da, um andere Kinder im College-Alter ohne Verbindungen und ohne Erfahrung kennenzulernen; sie sind da, um professionelle Entwickler „kennenzulernen“. In ähnlicher Weise bedeutet ein Projekt hauptsächlich oder vollständig von Praktikanten bearbeitet zu werden, anstatt von und über echten Code (das Gute, Schlechte und Hässliche) zu lernen, lernen sie voneinander, Blinde führen Blinde. Bei mehreren Teams wäre es viel sinnvoller, jedem Team ein oder zwei Praktikanten oder ehrenamtliche Mentoren zuzuweisen.
Ich denke ernsthaft, dass diese Frage hier nicht hingehört. Es gehört zum Stack-Austausch von 'Programmierern'. Der OP ist ein Ingenieur und er versucht, das Personalmanagement von Praktikanten zu übernehmen, und er hat die Lektion gelernt: So sei es!
@FlorianSchaetz Wenn Ihr Code nicht klar zeigt, was er tut, ist es schlechter Code - hängt von der Sprache ab :-/
Sagen Sie ihm, dass die Codeüberprüfung niemals bestehen wird, da convertToMillilitersBecauseIAmUsingSuchCleanCode mehrdeutig ist. Es sollte Gallonen in Milliliter umgerechnet werden, weil ich SuchCleanCode verwende

Antworten (22)

Auslachen halte ich nicht für den richtigen Ansatz. Sie müssen lernen, dass sie nicht mehr in der Schule sind. Abgesehen davon denke ich, dass Sie es auch nicht zu weit in die andere Richtung treiben sollten.

Ich würde Ihnen empfehlen, fest zu ihm/ihr zu sein und etwas zu sagen mit der Wirkung von:

Der Grund, warum wir Namenskonventionen durchgegangen sind, ist, dass sie sehr wichtig sind. Dieser Code muss in Zukunft wartbar sein. Viele Leute hier haben hart gearbeitet, um dorthin zu gelangen, wo sie jetzt sind, und sie mögen diese Art von Witzen vielleicht nicht. Bitte verwenden Sie diese Art von Namen in Zukunft nicht mehr, da dies dazu führen kann, dass andere Ihre Professionalität in Frage stellen.

Dies scheint der allgemein richtige Ansatz zu sein. persönlich würde ich mit ihnen mit einer weniger formalen sprache gleichziehen. Ich rief sie in mein Büro und sagte: „Hey, mir ist aufgefallen, dass Sie einige alberne Namen für Ihre Methoden verwenden. Was ist los?“ Wenn ich sie persönlich auf diese Weise anrufe, würde dies meiner Meinung nach eher Schamgefühle und Reue hervorrufen. eine zu förmliche schriftliche Schelte könnte ihnen nur noch mehr Futter für Spott liefern.

Zunächst einmal scheint dies wie ein Witz zu sein, der in einen Code eingefügt wurde, von dem sie wissen, dass er für nichts verwendet oder nie wieder gelesen wird. Ich denke, Sie interpretieren viel zu viel in diesen Vorfall hinein. Wichtig ist, dass Sie ihnen von der Namenskonvention erzählt haben und sie Sie nicht ignoriert haben, sie haben längere und aussagekräftigere Namen verwendet (wenn auch sarkastisch).

Nachdem ich dieses Video gesehen habe, kann ich sehen, dass Arbeiter 3 Dinge wünschen:

  1. Autonomie
  2. Meisterschaft
  3. Zweck

Was Sie von ihnen verlangen, ist nicht autonom, ist wahrscheinlich für einige von ihnen von trivialer Schwierigkeit und erfüllt in ihren Augen keinen Zweck.

Beheben Sie die Aufgabe, und die Arbeiter werden folgen.

Einige Beispiele:

  1. Hier ist dieses Projekt, arbeitet zusammen und lasst es bis zum ____ erledigen, lasst es mich wissen, wenn ihr nicht weiterkommt.

  2. Ich weiß, dass dies nicht wichtig erscheint, aber um Ihre Fähigkeiten einzuschätzen und Ihnen Arbeit zuzuweisen, von der wir glauben, dass sie Ihnen beim Wachsen helfen wird, brauchen wir Sie, um diese Aufgabe zu erledigen.

Einverstanden. Sie wissen, dass sie an etwas arbeiten, das völlig bedeutungslos ist, was frustrierend sein kann. Humor ist eine gute Möglichkeit, Dampf abzulassen.
Diese Antwort gefällt mir sehr gut, weil sie die Verantwortung für das unprofessionelle Verhalten des Praktikanten mit dem Management teilt. Als jemand, der bis vor kurzem in einer untergeordneten Rolle feststeckte, verstehe ich die negativen Auswirkungen, die Mikromanagement und mangelnde Autonomie auf meine eigene Produktivität haben können. Während Disziplin zu einer kurzfristigen Lösung führen kann, löst sie nicht das zugrunde liegende Problem.
Ich habe das Video gesehen und ich liebe diese Punkte. Dies ist jedoch eindeutig subversiv und respektlos. Die Frage ist warum. An einem Spielzeug zu arbeiten, bevor es ins tiefe Ende des Pools geworfen wird, ist kein Mikromanagement. Auch wenn die Praktikanten das vielleicht nicht verstehen. Der beste Weg, darauf zu reagieren, ist zu fragen, warum. Machen sie sich über die Übung, die Standards, das Management lustig oder war es einfach zu viel Zeit an der Tastatur und nicht genug Zeit, um eine Nerf-Waffe zu halten?
Lesen Sie überhaupt nichts hinein, bis Sie es im Griff haben. Das ist nicht einmal Sache des Managements. Dies ist ein Codeüberprüfungsproblem. Der Grund, warum Sie dies nicht tun, ist nicht, dass das Management Sie feuern wird. Das liegt daran, dass Ihre Kollegen wissen, wo Sie Ihre Kaffeetasse aufbewahren.
Einverstanden. Es sind Kinder, die noch nie in einem professionellen Umfeld gearbeitet haben, in einer Rolle, in der eines der Ziele darin besteht, ihnen beizubringen, wie man in einem professionellen Umfeld arbeitet. Sie zu feuern, weil sie nicht professionell sind, scheint den Punkt zu verfehlen.
@JaguarWong „Das sind Kinder, die noch nie in einem professionellen Umfeld gearbeitet haben, in einer Rolle, in der eines der Ziele darin besteht, ihnen beizubringen, wie man in einem professionellen Umfeld arbeitet.“ Sie sind wahrscheinlich in den Zwanzigern und müssen dies in Kürze tun oder weiterhin von Mama und Papa bezahlen lassen. Ehrlich gesagt, „mach dich nicht über deinen Mentor lustig“ ist etwas, was sie bereits wissen sollten.
@CandidOrange zu "subversiv / respektlos": nicht unbedingt wahr. Davon haben wir nur den Bericht des Managers. Alles, was wir wissen, convertToMillilitersBecauseIAmUsingSuchCleanCodeist ein "übertriebenes" Beispiel. Vielleicht haben es die Praktikanten eher als "zum Spotten" getan, "um zu binden", und der Manager ist verunsichert und hat sich für die schlimmstmögliche Erklärung entschieden. Vielleicht war der Praktikant stolz darauf, das dort zu platzieren, um zu zeigen, dass sie nicht nur zugehört, sondern es genossen und es geschafft hatten, etwas Spaß damit zu haben. Der Manager geht davon aus, dass er "schlau herausgefunden hat, wer", obwohl der Praktikant sich wahrscheinlich nicht versteckt und nur versucht hat, die Stimmung zu heben

TL;DR : Ich lehne den Methodennamen ab, weil er (meiner Meinung nach!) Verachtung für den Chef und/oder die "Regeln" (hier: Stilrichtlinien) zum Ausdruck bringt. Am Arbeitsplatz erwarte ich von den Menschen, dass sie sich an die Regel halten: „Love it, change it, or leave it“. In diesem Fall sollte der Praktikant, der die Richtlinie anscheinend für unnötig hält, sie entweder einfach akzeptieren; oder die Diskussion darüber am Laufen halten; oder aufhören zu tun, was er tut. Nicht gleichbedeutend mit etwas Verschmieren auf der Toilette. Gegen einen wirklich witzigen, kreativen Methodennamen hätte ich absolut nichts einzuwenden. Wenn Sie (das OP) den Methodennamen nur lustig und nicht "schlecht" finden wie ich, dann ignorieren Sie diese Antwort bitte.


Als Hintergrund habe ich in der Vergangenheit einige hochintelligente und (selbst-)motivierte Praktikanten betreut, bei denen nie die Frage stand, ob sie sich professionell verhalten würden oder nicht. Als Praktikant schulische Dummheit an einen Arbeitsplatz zu bringen, ist so weit außerhalb des Akzeptablen, dass ich vorschlagen würde, nicht herumzuspielen. Für sie und vor allem für sie.

Ich würde gerne wissen, wie man mit einer solchen Situation richtig umgeht.

Vergessen Sie zunächst die Codierungskonventionen. Das Problem bezieht sich nicht auf Computer oder Programmierung.

  • Lüge nicht. Nehmen Sie kein Blatt vor den Mund, lachen Sie nicht darüber, denn es ist wirklich nicht zum Lachen.
  • Werden Sie nicht persönlich. Es geht nicht um Sie , das OP, noch um Ihre Beziehung zu ihnen. Es geht einzig und allein um ihr Verhalten.
  • Erklären Sie die Dinge, wie sie sind. Sie können dem Täter durchaus sagen, dass Sie irgendwie verstehen, wie er auf die Idee gekommen ist, das zu tun, was er getan hat, und dass Sie nicht persönlich wütend auf ihn sind oder was auch immer (halten Sie Emotionen raus), sondern dass Sie das Praktikum als Vorführung betrachten wen man später mit an Bord nimmt.

Wenn Sie irgendwelche Emotionen darüber vermitteln möchten, bleiben Sie weit weg von Wut. Sie können leichte Traurigkeit zeigen (und ehrlich gesagt, das wäre genau das, was ich tatsächlich fühlen würde) und ihnen zeigen, dass Sie ziemlich enttäuscht waren.

Ihre Leistung während des Praktikums wirkt sich jedoch auf ihre Einstellungschancen aus, und Situationen wie diese können später eine Rolle spielen.

Unbedingt! Fummeln Sie nicht mit "kann später eine Rolle spielen". Ein solches Verhalten kann, soll und wird die Chance auf ein Angebot nach dem Praktikum gleich Null machen. Sie können das so sagen, wie Sie normalerweise mit ihnen sprechen, klar und deutlich.

Versuchen Sie, die Ursache zu finden. Wenn du das auch herausfindest...

  • ... sie sind gegen ihren freien Willen hier (vielleicht haben ihre Eltern oder ihre Schule oder was auch immer sie dazu gebracht, ein Praktikum auszuwählen, und sie haben sich zufällig für Ihre Firma entschieden) ...
  • ... sie sind überhaupt nicht an Softwareentwicklung im "Geschäftsstil" interessiert ...

...dann wäre ein Praktikumsabbruch nicht das Schlimmste, was Sie tun könnten. Das Problem ist nicht, dass Ihre Zeit verschwendet wird (Sie hatten sowieso viel Zeit darauf verwendet, sie zu beaufsichtigen, sie haben es nicht wirklich schlimmer für Sie gemacht), das Problem ist, dass ihre Zeit verschwendet ist.

Oder sollte ich ihnen etwas in dieser Richtung sagen, um sie motivierter zu machen, tatsächlich etwas zu lernen?

Ich würde sagen: „Jeder Mensch kann lernen, aber kein Mensch kann gelehrt werden.“ Ich denke, Sie werden es sehr schwer finden, diese Person dazu zu motivieren, sich über die Nützlichkeit von Programmierkonventionen zu informieren, da sie bereits gezeigt haben, dass sie kein Interesse daran haben. Sie können diejenigen unterrichten, die daran interessiert sind, was Sie zu sagen haben; aber wenn jemand desinteressiert ist, kannst du wirklich nichts tun.

Wenn Sie dieser Person wirklich helfen wollen, „das Licht zu sehen“, dann bitten Sie sie, um ihrer selbst willen zu versuchen, mitzuspielen, vielleicht lernt sie später zu schätzen, was Sie anbieten können. Praktika sind ein Austausch aller begrenzten Dienstleistungen, die sie anbieten können, gegen die Erfahrung, an einem tatsächlichen Arbeitsplatz zu arbeiten. Wenn sie nicht daran interessiert sind, die Erfahrung zu assimilieren, dann hat es wirklich keinen Sinn. Vermutlich ist Ihr Unternehmen nicht darauf angewiesen, seine „Manpower“ für irgendein reales Projekt zu haben.

Vergessen Sie zunächst die Codierungskonventionen. Das Problem bezieht sich nicht auf Computer oder Programmierung. Das ist ein wirklich guter Punkt!
Entschuldigung, aber -1, da ich Ihre Antwort zu hart und überreagiert finde. Ich finde Sätze wie „ist so weit außerhalb des Akzeptablen“, „sie haben bereits gezeigt, dass sie kein Interesse daran haben“ und „machen ihre Chance auf ein späteres Onboarding auf Null“ auf diese Situation nicht anwendbar. Sie wählen einfach ein paar dumme Namen für ein nicht relevantes Stück Code, eine Aktion, die in wenigen Sekunden korrigiert werden kann (und übrigens ist die Verwendung einiger dummer Namen in vielen ernsthaften Anwendungen ziemlich üblich). Sie haben ihren Chef nicht ermordet!
Kein Grund zur Entschuldigung, @dirkk, deine Meinung ist genauso gültig wie die aller anderen. Ich schätze, es wäre wahrscheinlich hilfreich zu wissen, welches Alter und/oder welchen Hintergrund diese Jungs haben und was der Kontext ihres Praktikums ist.
"weil es wirklich nicht zum Lachen ist". Dies ist ein Methodenname, kein medizinischer Notfall. Ja, es sollte perfekt, steril und schlachtschiffgrau sein, aber wenn Sie die Leute wirklich nach diesen Kriterien auswählen, seien Sie darauf vorbereitet, dass Ihr perfekter, steriler und grauer Laden in naher Zukunft von Skripten und KIs übernommen wird. Alle Menschen machen Fehler und wenn ihr einziger Fehler darin besteht, einen regelkonformen, aber humorvollen Methodennamen zu finden, dann würde ich sie definitiv einsetzen.
@nvoigt Es ist durchaus möglich, ohne Vorschuldummheit guten Code mit Programmierflair zu schreiben. (Und nein, es entspricht nicht den Regeln.) Ihr Fehler besteht darin, das OP nur als einen weiteren Lehrer in einer Wir-und-sie-Situation zu sehen, anstatt als einen Kollegen, der versucht, ihnen zu helfen. Wenn sie mit dieser kindischen Einstellung Schritt halten, warum würden Sie sie einstellen? Wenn es viele Praktikanten und weniger Vollzeitjobs gibt, müssen sie dir einen Grund geben , warum sie mit dir zusammenarbeiten wollen, sonst gehst du besser zu jemand anderem.
@Graham Basierend auf dem, was Sie schreiben, scheint Ihr Land mit perfekten CS-Leuten überfüllt zu sein, die um Jobs betteln. Meins ist es nicht, ich nehme jemanden, dessen größter Fehler darin besteht, jeden Tag einen lustigen Methodennamen in den Regeln zu finden.
@nvoigt, das Problem (für mich) ist nicht, dass sie einen lustigen Methodennamen verwendet haben. Zum Beispiel hat einer unserer Entwickler ein Paket "I" genannt, was zu Methodennamen wie "I.run()" usw. führte. Das ist in Ordnung, das ist lustig usw. Der Methodenname, den der Typ in dieser Frage gewählt hat, ist ungefähr übersetzt mit " mein Chef ist scheiße, aber ich tue, was er sagt, weil er es sagt“. Ja, das ist natürlich nur meine Meinung, aber wir sind in Workplace.SE, und ein bisschen Meinung sollte hier erlaubt sein, zumal der Abstimmungsmechanismus sich darum kümmert.
@nvoigt: TL;DR hinzugefügt, um den Geist meiner Antwort besser zu erklären.
@dirkk Wie AnoE erwähnt, ist dies nicht "nur ein dummer Name". Im Wesentlichen ist dies niedergeschriebener Sarkasmus, der als Kränkung gegen das OP gedacht ist und an einem Arbeitsplatz einfach nicht in Frage kommt. Das ist relativ milde und wahrscheinlich nur ein unangemessener Versuch des Humors, aber wenn es nicht um Praktikanten ginge, würde ich mit Begriffen wie passiv-aggressivem Verhalten, böswilliger Fügsamkeit, Rufschädigung und karrierebegrenzendem Schritt um sich werfen. Aber von Praktikanten, die neu in einer Bürokultur sind, wird erwartet, dass sie Fehler machen, und dies sollte ein lehrreicher Moment sein. Dies nicht ernst zu nehmen, würde diesen Praktikanten einen Bärendienst erweisen.
@AnoE Ich folge deiner Meinung dazu, aber wenn ich etwas (hoffentlich konstruktive) Kritik anbringen darf, finde ich, dass deine Antwort etwas unstrukturiert und weitschweifig ist. Ich denke, es würde helfen, das Hauptproblem mit dem Verhalten (unprofessionell, an einem Arbeitsplatz nicht angemessen) und dem, was das OP tun sollte, zusammenzufassen (erklären Sie, warum es für Menschen, die neu am Arbeitsplatz sind, unangemessen ist = seine Praktikanten verwalten). Ich bin mir auch nicht sicher, was Ihren Abschnitt über die Grundursache betrifft. Ich würde nicht automatisch annehmen, dass sie wegen dieses speziellen Vorfalls von schlechtem Urteilsvermögen unmotiviert waren.
@Lilienthal: Danke für dieses Feedback, es scheint, dass das gelegentlich ein Problem für mich ist (um auf den Punkt zu kommen). Ich werde versuchen, daran zu arbeiten. ;)
@AnoE Ich kenne das Gefühl, es ist nur die Beschränkung auf 600 Zeichen, die meine Kommentare in Schach hält.:) Ping mich im The Workplace Chat an, wenn du antworten möchtest, ich möchte diesen Kommentar-Thread nicht weiter ergänzen. Fahren Sie fort und kennzeichnen Sie meinen obigen Kommentar als veraltet, wenn Sie diesen Teil davon löschen möchten.
"Das Problem hat nichts mit der Programmierung zu tun." Das ist ein fantastischer Punkt und trifft den Kern des Problems. Ich denke, die meisten anderen Antworten haben es irgendwie impliziert, aber ein großes Lob dafür, dass Sie es explizit formuliert haben.

Wir alle hassen es, aber manchmal muss man Probleme einfach mit Autorität lösen. Rufen Sie die Praktikanten zu einem Treffen ein und fragen Sie nach, warum die Namenskonventionen nicht eingehalten wurden.

Die einzuhaltenden Namenskonventionen habe ich bei unserem letzten Treffen erläutert. Ich bin auf eine Reihe von Fällen gestoßen, in denen die Namenskonvention nicht eingehalten wurde. Zum Beispiel convertToMillilitersBecauseIAmUsingSuchCleanCode. Können Sie bitte erklären, warum dieser Name gewählt wurde?

Ihre "Antwort" ist irrelevant, dies sollte als "erste Warnung" genug dienen, dass es in einem professionellen Umfeld nicht akzeptabel ist, gegen die Anweisungen ihres Vorgesetzten (was ich annehme, Sie sind es) zu sein und Witze auf seine Kosten zu machen. Das passt sogar gut zu einem Ziel des Praktikums, nämlich Studenten den Weg in ein professionelles Umfeld zu zeigen.

Wenn sie mit ihrem kindischen Verhalten fortfahren, dann sind Sie, glaube ich, zu dem Schluss gekommen:

Ein Teil der Praktikanten wird zukünftig aufgrund ihrer Leistung im Unternehmen übernommen.

Das Problem dabei ist, dass sie sich an die Namenskonventionen gehalten haben
@JoeS wie? convertToMillilitersBecauseIAmUsingSuchCleanCodebefolgt nicht die Anweisung von should not be afraid to use longer, descriptive method names. Es ist lang, aber nicht beschreibend.
@Cheshire sie haben das Spiel "genaue Worte" gespielt. Das wird man nicht mit roher Gewalt lösen.
@JoeS Nein, haben sie nicht. Es ist offensichtlich, dass ihr Verhalten passiv aggressiv war, und sie wählten den langen Namen nur, um den Vorgesetzten zu verspotten. Ich wäre daran interessiert zu sehen, wie sich ein vollwertiger Berufstätiger ähnlich verhält und nicht stark gerügt wird (wenn nicht schlimmer). Es gibt keine Rechtfertigung dafür, Namen länger als nötig zu wählen, sie spielen nicht das „beste Schlupflochmissbrauchsspiel“, und selbst wenn etwas mit der Regel nicht stimmt, sollten sie dies konstruktiv ansprechen, nicht indem sie sich unausstehlich verhalten. PS: Ich hoffe aufrichtig, dass Sie einen Scherz gemacht haben.
Wenn ihre Antwort irrelevant ist, warum würden Sie dann ein Meeting einberufen, um die Frage zu stellen? Eine erste Warnung sollte eine tatsächliche Warnung sein – keine rhetorische Frage.
@mwbl Weil das Ziel, es als Frage zu stellen, darin besteht, sie in die unangenehme Position zu bringen, in der sie darüber nachdenken und sofort eine Antwort geben müssen. Er hat ihnen bereits von den Namenskonventionen erzählt und sie haben es nicht "verstanden". Wenn Sie ihnen sagen, "Sie sollen keine dummen Namen in Ihrem Code verwenden", wird dies mit "Ja, richtig, der ach so saubere Code, über den wir sprechen" beantwortet. Die Praktikanten müssen den Unterschied zwischen Hochschule und Berufsumfeld erkennen.
"Können Sie bitte erklären, warum dieser Name gewählt wurde?" ist ein ziemlich passiv-aggressives Verhalten, wenn man deutlich sieht, dass es sich um einen Witz handelt. Ihr Ziel sind bessere Programmierkonventionen und nicht Ihre Autorität, hoffe ich.
@Boat Obwohl ich nicht für MaskedMan sprechen kann, besteht das Ziel hier sicherlich nicht darin, bessere Codekonventionen zu lehren: das ist nebensächlich. Ziel dieses Treffens sollte es sein, diesen Praktikanten zu verdeutlichen, dass ein Arbeitsplatz nach anderen Regeln spielt als ein Programmierkurs und dass ein solches passiv-aggressives Verhalten absolut nicht in Ordnung und oft ein karrierebegrenzender Schritt ist und für normale Mitarbeiter erforderlich wäre Sätze wie „letzte Warnung“ oder „packen Sie bitte Ihre Sachen“. Der wahre Wert von Praktika liegt in der Vermittlung von Soft Skills und der Anpassung an eine Bürokultur, nicht in technischen Fähigkeiten.
@Lilienthal, Nun, dann können Sie zum Beispiel einfach sagen "Es ist unangemessen, bei Namenskonventionen zu scherzen". Wenn Sie vorgeben, nicht zu verstehen, sagen Sie nur: „Ich bin der Boss und Sie sollten Ihren Platz lernen“. Es geht nicht um soziale Rollen, es geht nicht um dein Ego, es geht um Arbeitskonventionen und der Chef sollte in der Lage sein, dies konstruktiv zu kommunizieren. Nur weil der Praktikant sich kindisch verhalten hat, heißt das nicht, dass Sie dasselbe tun müssen.
@Lilienthal Ich wollte auf diese Zeilen antworten, als ich die Zeit fand, aber du hast es sicherlich viel besser ausgedrückt als das, was ich gesagt hätte!
@Boat Was genau ist hier kindisch daran, die Praktikanten zu fragen, warum sie sich nicht an die Regeln gehalten haben? Die Praktikanten sind nicht im Kindergarten, man sollte ihnen nicht den Eindruck vermitteln, dass sie in der Berufswelt verwöhnt werden. Der Vorgesetzte hat ihnen schon einmal gesagt, dass sie sich an die Namenskonventionen halten sollen. Es gibt keine solche Verpflichtung seinerseits, "sie beim ersten Mal scherzen zu lassen und die Regeln erneut zu erklären, bis sie aufhören zu scherzen". Es ist nichts Unkonstruktives daran, wenn ein Chef seinen Untergebenen sagt, dass sie ihre Arbeit machen sollen, er muss sie nicht babysitten, um die Arbeit zu erledigen.
@MaskedMan-仮面の男 Anzugeben, dass es nicht in Ordnung ist, Witze zu machen, ist völlig in Ordnung. Aber eine Erklärung zu verlangen und so zu tun, als ob Sie an der Antwort interessiert wären, ist nicht in Ordnung, denn in Wirklichkeit möchten Sie nur, dass sie antworten "weil ich dumm bin". Es ist dasselbe, als würde man für jeden Schreibfehler eine Erklärung verlangen: Sie wissen, dass es nicht dazu bestimmt ist, weil sie denken, dass es richtig ist, aber Sie tun so, als ob Sie es nicht wären. Sagen Sie ihnen einfach, dass Witze/Schreibfehler nicht in Ordnung sind, und werfen Sie sie raus, wenn sie ihr Verhalten nicht ändern, aber tun Sie nicht so.
@Boat Hmm, das liegt wahrscheinlich nur an einem Unterschied in der Arbeitskultur. In der mir bekannten Arbeitskultur nennt man das, was die Praktikanten dort gemacht haben, Insubordination. Ich lasse sie sehr locker , weil sie Praktikanten sind, und schlage vor, sie um eine genaue Erklärung zu bitten, weil sie darüber nachdenken und nicht nur zu dem Schluss kommen sollten, „wir sollten dem Chef nicht ungehorsam sein, weil der Chef es so gesagt hat“. Das Problem hier ist nicht, dass sie an sich „scherzten“, sondern dass sie die Anweisungen ihres Vorgesetzten völlig missachteten.
@boat "Ich bin der Boss und du solltest deinen Platz lernen". Ich denke tatsächlich, das ist eine der Lektionen, die die Praktikanten in dieser Frage lernen müssen.

Oh, ein Haufen Abzocke, eh?

Nehmen Sie einen funktionierenden Code und tun Sie etwas, um ihn absichtlich zu brechen. Führen Sie es dann durch einen Obfuscator, der alle Klassen-, Variablen- und Methodennamen in Dinge wie "a___1318798_" und "xy23_7a963" ändert; oder noch schlimmer, Variablennamen mit vielen Buchstaben O, I, Ziffer 0 und Ziffer 1 in ihnen. Machen Sie es sich zur Aufgabe, zu dokumentieren, was der Code tut, und beheben Sie das Problem.

Das wird das Herumalbern heilen.

Ich bin mir nicht sicher, warum diese Antwort abgelehnt wurde. Ich bin mir ziemlich sicher, dass diese "Zuweisung" das Problem der Namenskonventionen auf den Kopf stellt. Die Professionalität jedoch ... schade, dass es kein Rollback zu "Ich war ein Idiot für jemanden, der beeinflusst, ob ich eingestellt werde oder nicht" gibt
@TBear Dies würde mehr Zeit verschwenden, als bereits verschwendet wurde, wahrscheinlich ohne eine sehr nützliche Lektion zu erteilen, oder bestenfalls eine Lektion zu erteilen, die mit einer schnellen Erklärung leichter unterrichtet werden könnte. Obwohl ich es persönlich nicht abgelehnt habe, glaube ich, dass andere es deshalb getan haben.
Ich dachte das gleiche, habe es aber als Kommentar gepostet, da es wahrscheinlich keine gute Lösung für das Problem ist. Hängt stark von der Kultur des Entwicklungsteams ab und davon, ob Sie Ihre Praktikanten im Stil von Major Pain mit „Maggot“ ansprechen oder nicht.
Es hat mit ziemlicher Sicherheit eine Reihe von Ablehnungen erhalten (nicht von mir, das verspreche ich), weil es die Wahrnehmung der Übung als unseriös durch die Praktikanten nur erhöht .
Mit der Versionskontrolle wird dies in 30 Sekunden durch ein einziges Rollback behoben.
@DmitryGrigoryev du musst es ihnen nicht über Git geben;)
@BlackThorn Verantwortung zu übernehmen, sich zu entschuldigen und sichtbar zu versuchen, es besser zu machen, kann als Rollback dazu wirken.

Ich weiß, es ist wahrscheinlich keine so große Sache, aber es ist das erste Mal, dass ich den Praktikanten helfe, und ich würde gerne wissen, wie man mit einer solchen Situation richtig umgeht. Ihre Leistung während des Praktikums wirkt sich jedoch auf ihre Einstellungschancen aus, und Situationen wie diese können später eine Rolle spielen. Oder sollte ich ihnen etwas in dieser Richtung sagen, um sie motivierter zu machen, tatsächlich etwas zu lernen?

Wenn Sie bei Ihren Code-Reviews auf eine solche Albernheit stoßen, lachen Sie, beenden Sie die Code-Review und sagen Sie ihnen, dass sie wiederkommen sollen, sobald sie den Humor entfernt haben.

Ich gehe davon aus, dass sie nicht dumm sind und bereits wissen, dass der zu lange Name unangemessen ist, auch wenn sie darüber schmunzeln. Wenn nicht, erklären Sie einmal warum.

Hoffentlich verfolgen Sie ihre Leistung und können feststellen, wie oft dies geschieht.

Ich würde mit jedem von ihnen privat in einem offenen und ernsten, aber nicht strengen Ton ein Herz-zu-Herz-Gespräch führen, etwa so:

„Praktikant, ich habe den Namen Ihrer Witzmethode gesehen. Ich verstehe, warum Sie es getan haben, aber ich fand es selbst nicht so lustig. Also fällt mir ein, Sie zu fragen, was Sie hier tun? Was würden Sie tun? gerne erreichen?"

Wenn der Praktikant sagt, er sei nur zum Herumalbern da, dann sprich mit dem Management, um sein Praktikum zu beenden. Du verschwendest deine Zeit.

Wenn er sagt, dass er da ist, um zu lernen, dann sag so etwas:

„Mir ist klar, dass es schwierig sein kann, etwas ernst zu nehmen, von dem man weiß, dass es nicht in der Produktion verwendet wird. Aber bitte machen Sie sich bewusst, dass Sie sich nicht nur Zeit nehmen, sondern auch meine Zeit. Das Praktikum, das Sie gemacht haben Das Unternehmen stellt im Wesentlichen eine Art Vorstellungsgespräch dar. Das einzige, was davon abhält, dass es sich um eine reine Wohltätigkeit unsererseits handelt, ist die Hoffnung, gute Kandidaten zu finden. Es lohnt sich also, meine Zeit zu investieren, aber nur, wenn Sie es ernst meinen.“

„Wenn Sie es nicht ernst nehmen und so arbeiten können, als würden Sie wichtigen Produktionscode schreiben, wie können wir Sie dann richtig bewerten und entscheiden, ob wir Ihnen einen Job anbieten? Und selbst wenn wir Ihnen keinen Job anbieten, wenn Sie nimm es immer noch nicht ernst, wie sonst kannst du dir diese Fähigkeiten aneignen und in der Lage sein, unter der wertvollen Anleitung von jemandem mit mehr Erfahrung als du zu üben?"

„Wenn ich Sie wäre, würde ich mein Bestes tun, um dem Beispiel der Leute zu folgen, die Sie führen, die sich etwas wohltätig unrentable Zeit von ihrer Arbeit nehmen, um in Sie zu investieren. Denken Sie daran, dass Sie von diesem Praktikum profitieren werden ob Wir stellen Sie ein oder nicht! Ich persönlich würde es begrüßen, wenn Sie dies etwas ernster nehmen würden. Tun Sie es für sich selbst! Wenn Sie es nicht für sich selbst tun möchten, tun Sie es aus Respekt oder einfach nur aus Dankbarkeit für die Zeit Ich habe von meiner normalen produktiven Arbeit abgezogen, um in Sie und Ihre Zukunft zu investieren."

Es ist wahrscheinlich angebracht, das Verhalten selbst etwas direkt anzusprechen und warum Sie eine große Sache daraus machen. Sie könnten so etwas in Betracht ziehen:

„Für das, was es wert ist, wird diese Art von Aktion in der Unternehmenswelt als Respektlosigkeit oder sogar als Spott angesehen. Ich bin sicher, Sie haben es nicht so gemeint [auch wenn Sie das nicht glauben, sagen Sie es], aber Bitte befolgen Sie in Zukunft einfach meine Anweisungen, ohne bissige Dinge in den Code zu schreiben."

Wenn er das „Aus“ des Praktikanten sagt: „Oh, ja, ich wollte nicht respektlos sein“, kann er sein Gesicht wahren und die Beziehung auf die schmerzloseste Weise reparieren. Es ist nicht nötig, ein Geständnis zu erpressen, dass er es respektlos gemeint hat, oder eine große Entschuldigung zu sammeln. Hier geht es nicht um Power-over, sondern um erfolgreiches Praktikum.

Wenn das negative Verhalten nach all dem anhält, können Sie es direkter ansprechen. Es gibt keinen Grund, warum Sie einem Praktikanten nicht ein Leistungsziel geben können, so wie Sie es einem problematischen Mitarbeiter tun würden, oder eine andere Strategie anwenden, die Sie bei einem normalen Mitarbeiter anwenden würden. Denken Sie jedoch daran, dass die Praktikanten NICHT in der Arbeitswelt erfahren sind und eine Pause oder zwei erhalten sollten, während Sie sie sanft, aber bestimmt an die Standards der professionellen Arbeitswelt gewöhnen.

Kommentare sind nicht für längere Diskussionen gedacht; Diese Konversation wurde in den Chat verschoben .

Ich habe mit ein paar Jungs gearbeitet, die frisch von der Schule kamen. Sie taten so etwas nicht absichtlich, sondern weil sie der Meinung waren, dass es keinen Sinn machte, zu pedantisch zu sein. Code-Lesbarkeit oder Wiederverwendbarkeit machten für sie einfach keinen Sinn. Also war ich sauer, aber ich konnte keinen von ihnen tadeln, da ich nicht ihr Chef war.

Programmierer sind im Allgemeinen ein kluger Haufen und "weil ich es gesagt habe" ist selten ein ausreichender Grund, etwas zu implementieren, selbst wenn es die beste Programmierpraxis ist.

Ich würde den Code überprüfen und ihnen unbedingt sagen, dass der Humor fehl am Platz ist und ihre seltsamen Namenskonventionen ziemlich viel Zeit verschwenden. Für die nächste Aufgabe würde ich sie zweiteilen: die lustigen Typen auf der einen Seite, der Rest auf der anderen. Sie würden die gleiche Aufgabe erledigen, aber die lustige Gruppe sollte viel länger dauern, weil sie nicht den Best Practices folgen. Ich würde sicherstellen, dass diese Aufgabe komplex genug ist, damit sie viel Zeit verschwenden, wenn sie ihre Konventionen einhalten.

Sie können auch einen lustigen Kerl zuweisen, um den Code eines anderen lustigen Kerls zu debuggen. Ich glaube nicht, functionThatDudeToldMetoDefinedass es mit diesem Namen in die endgültige Version kommen würde.

In jedem Fall besteht die einzige Möglichkeit, Ihre Autorität zu erhöhen, darin, sie in Situationen zu bringen, in denen sie sich selbst beweisen, dass das, was Sie behaupten, wahr ist.

Ich denke, dass dieser Satz ein sehr guter Rat ist: "Der einzige Weg, Ihre Autorität zu stärken, besteht darin, sie in Situationen zu bringen, in denen sie sich selbst beweisen, dass das, was Sie behaupten, wahr ist." Wenn sie sich nicht an die Konvention halten, dann deshalb, weil sie ihren Wert nicht verstehen. Sie den Wert selbst erkennen zu lassen, wird ihnen wahrscheinlich helfen, die Konvention zu nutzen.
Du kannst sie nicht tadeln, sicher. Aber wenn Sie eine Codeüberprüfung durchführen, können Sie ihn zurücksenden und zurücksenden und zurücksenden. Und wenn es weitergeht, eskaliere es. Ihr Chef sollte auf jeden Fall eine Meinung zur Lesbarkeit und Wiederverwendung von Code haben, da sich dies direkt auf die späteren Zeitpläne seines Teams auswirkt. Und wenn sie einem Codierungsstandard nicht folgen können, werden Sie sie los. Kinder, die gerade aus der Schule kommen, kosten zehn Cent, und wenn sie nicht lernen, können Sie sie feuern und jemanden finden, der es kann.
@Graham Wenn der Arbeitsmarkt wie in den USA oder der westlichen EU ist, ist es einfacher, die "defekten" zu ersetzen. Dort, wo ich lebe, ist qualifiziertes Personal schwer zu bekommen, also hat man nicht so viele Möglichkeiten. Wenn sich herausstellt, dass Sie zu hart sind, würden die Leute nach anderen Optionen suchen.
„Programmierer sind im Allgemeinen ein kluger Haufen und „weil ich es gesagt habe“ ist selten ein ausreichender Grund.“ Das mag theoretisch stimmen, aber in der Praxis sehen wir genau das Gegenteil mit Programmierern, die dumme Bigotterie praktizieren wie „Emacs vs. Vim“, „Chrome vs. Firefox “, „C++ vs. Java“, „Windows vs. Linux“ usw. In vielen Fällen ist es vernünftig, sich mit möglichst vielen Tools vertraut zu machen und das richtige für die jeweilige Aufgabe auszuwählen, doch Programmierer bestehen darauf, alles damit zu machen ihr "bevorzugtes" Werkzeug, auch wenn es mit einem anderen Werkzeug besser geht und sie es wissen .
@ user27051 dann wieder, andere werden kommen, wenn sie hören, dass Sie sich an die richtigen Standards halten und Leute loswerden, die mehr im Weg sind als helfen ...

Die betreffenden Praktikanten verschwenden Ihre Zeit und Geduld. Ihre Zeit und Geduld sind kostspielige und begrenzte Ressourcen für das Unternehmen und die Praktikanten, die von der Investition des Unternehmens in sie profitieren, eine Investition, die durch die Ressourcen des Unternehmens begrenzt ist.

Ihre Bereitschaft, Unternehmensressourcen unnötig zu verschwenden, ist ein relevanter Teil ihrer Leistungsbewertung und kann zu einer vorzeitigen Beendigung ihres Praktikums führen, um Unternehmensressourcen nur für diejenigen Praktikanten auszugeben, die tatsächlich daran interessiert sind, zu lernen, wie man ein wertvoller, verantwortungsvoller und zuverlässiger Teil von wird dem Arbeitsplatz, der sowohl mit Aufgaben als auch mit Weisungen betraut werden kann.

Ich würde dies allen Praktikanten sagen, einen Beispielcode zeigen, seinen Autor nicht erwähnen, nicht mehr als 2 Minuten damit verbringen und, wenn der Code später behoben wird und ähnliche Vorfälle sich nicht wiederholen, ihn nicht noch einmal erwähnen.

Wenn der Warnschuss nicht beachtet wird, ist der nächste Schritt ein offenes Gespräch nur mit dem betreffenden Praktikanten und möglicherweise einem Vorgesetzten von Ihnen (stellen Sie jedoch sicher, dass er in Ihrem Boot ist). Dann müssen Sie entscheiden, ob Sie es den anderen Praktikanten schuldig sind, denjenigen zu entfernen, der ihre Chancen auf ein erfolgreiches Praktikum sabotiert.

Der Punkt bei der Einstellung von Praktikanten ist, dass Sie ihnen einige der Arbeitsplatznormen beibringen, die von Menschen mit Erfahrung verwendet werden. Dazu gehört meines Erachtens auch ein klares und direktes Feedback. Hinweise fallen zu lassen ist nie eine gute Managementstrategie und ich würde es für besonders wahrscheinlich halten, dass es bei diesen Praktikanten scheitert. Und obwohl dies als ernstes Problem behandelt werden sollte, wird von Praktikanten erwartet, dass sie solche Fehler machen. Eine Fehleinschätzung ist nicht dasselbe wie mangelnde Lernbereitschaft.

Es hört sich so an, als gäbe es hier zwei Hauptprobleme: 1) Sie sind respektlos und 2) Der Name der Funktion ist immer noch scheiße, obwohl er jetzt länger ist.

Sie dafür zu tadeln, dass sie herumalbern, wird sie wahrscheinlich nicht dazu bringen, Ihre Autorität mehr zu respektieren, also würde ich mich auf das Problem konzentrieren, als wäre es eine andere schlecht benannte Funktion. Ich würde nicht unbedingt dumm spielen und so tun, als ob ich nicht merke, dass es ein Witz ist, aber ich würde sie fragen, warum sie den Namen gewählt haben, den sie gewählt haben:

"Es scheint, als gäbe es in diesem Funktionsnamen einige überflüssige Wörter, die nicht helfen, zu erklären, was die Funktion tut."

Auf diese Weise ist es eine Lerngelegenheit für sie, was einen guten Funktionsnamen ausmacht, und Sie konfrontieren sie nicht direkt. Als zusätzlichen Bonus können sie zugeben, dass sie nur herumgespielt haben, und sich schämen, die Zeit aller verschwendet zu haben.

„Ich würde mich nicht unbedingt dumm stellen und so tun, als wüsste ich nicht, dass es ein Witz ist“, dieser Teil erfordert meiner Meinung nach eine weitere Erklärung, da der „irreverant“-Teil hier ziemlich wichtig zu sein scheint.
"Es scheint, als gäbe es in diesem Funktionsnamen einige überflüssige Wörter, die nicht helfen, zu erklären, was die Funktion tut." Das scheint der Punkt zu sein, an dem die Praktikanten ansetzen wollen convertGallonsToMilliliters. Ich empfehle Ihnen zu erklären, warum convertunklar ist und je länger man die zusätzliche Ausführlichkeit wert ist, anstatt zu versuchen, "ihr Verhalten zu handhaben". (Und wenn Sie für Präzision argumentieren und sie für Kürze, könnten Sie am Ende sogar auf solche Funktionsnamen stoßen gal_to_ml, die das Beste aus beiden Welten vereinen.)

Wenn Sie die Leute daran erinnern müssen, dass Sie das Sagen haben, dann waren Sie es nie.

Es wäre besser, einen Code-Walkthrough durchzuführen, bei dem der Entwickler seinen Code den Verantwortlichen erklären muss.

  1. Dadurch wird die persönliche Verantwortung für das Ergebnis des Projekts gestärkt
  2. Bietet sofortiges professionelles Feedback
  3. Geben Sie dem Entwickler ein Gefühl der Dringlichkeit für den Abschluss des Projekts

Nutzen Sie Ihre Führung als Teil des Teams, um die Standards Ihrer Organisation aufrechtzuerhalten. Helfen Sie dann den jüngeren Mitarbeitern, diese Standards zu erfüllen, und vermeiden Sie die Peinlichkeit, minderwertige Arbeit zu präsentieren.

Dieser erste Satz scheint dem Rest Ihres Beitrags nicht wirklich etwas hinzuzufügen. Übersehe ich etwas?

Natürlich müssen Sie sie dazu bringen, damit aufzuhören, aber ihnen einfach zu sagen, dass sie es tun sollen, zeigt möglicherweise nicht, warum.

Ich weiß, dass die Richtlinie mit 80 Zeichen pro Zeile keineswegs eine feste Regel ist, aber der Versuch, sich daran zu halten, ist eine gute Übung, daher ist es ziemlich dumm, einen Variablennamen mit 48 Zeichen zu haben.

Ich würde vorschlagen, ihnen zu sagen, dass sie versuchen, diese Richtlinie von nun an zu befolgen, aber ihnen auch nicht erlauben, die von ihnen gewählten Variablennamen zu ändern. Eine Art "Du hast dein Bett gemacht, jetzt leg dich hinein"-Ding.

Sie werden versuchen, ihnen eine neue Vorgehensweise einzuhämmern (vorausgesetzt, sie halten sich nicht bereits kurz), Praktikanten, die nicht verstehen, warum lange Variablennamen schlecht sind, werden es gleich herausfinden, und die "klugen" Praktikanten werden bald feststellen, dass sie nicht so schlau sind, wie sie dachten.

Für erfahrenere Programmierer ist es offensichtlich, warum convertToMillilitersBecauseIAmUsingSuchCleanCodees besonders schlecht ist, aber anstatt ihnen zu sagen "das ist schlecht", zwingen Sie sie, herauszufinden, warum. Ich wette, Sie werden auf viel weniger wortreiche Namen stoßen und mit etwas Glück auch weniger zukünftige Versuche, bissig zu sein.

Leider sind lange Namen bei modernen IDEs nicht annähernd so schmerzhaft wie früher.

Sagen Sie dem Täter einfach (persönlich oder per E-Mail), dass das Praktikum kaum ein geeigneter Ort für solche Witze ist und er es ernst nehmen muss, wenn er ins Berufsleben starten will.

Bitten Sie sie, den Code zu reparieren, oder (wenn Sie etwas Autorität zeigen möchten) einfach ihre Änderungen in der Versionskontrolle rückgängig zu machen.

Das muss nicht „One Size Fits All“ sein.
Alle Größen passen einige:

Jeder der vorgeschlagenen Ansätze kann großartig funktionieren und kann je nach den Umständen der beste Ansatz sein. Hier ist meine Antwort auf jeden der Ansätze, nach denen gefragt wurde:

Soll ich durch reagieren

  • darüber lachen ("Ja, es ist lustig, aber bitte entferne es")

Dies ist eine großartige Idee, wenn: Sie ein ausgezeichnetes Verhältnis zu diesen Kollegen haben, mit denen Sie sich gut angefreundet haben

  • nur höflich darum bitten, es zu entfernen

Dies ist eine großartige Idee, wenn: Sie direkt sein möchten, damit es keine Missverständnisse gibt

  • sagen, dass ich es nicht mag, wenn jemand meine Zeit verschwendet und er die Codeüberprüfung ernster nehmen sollte

Dies ist eine großartige Idee, wenn: Sie Ärger kommunizieren möchten und an einem autoritären Ansatz festhalten.

(Ich neige dazu zu glauben, dass Sie all diese Ansätze in einer nicht beleidigenden, höflichen, lustigen Art und Weise kombinieren können, die vermittelt, dass ein bisschen Ärger vorhanden ist. „So etwas muss aufhören, weil es mich einfach macht go [mock-scream] " könnte eine humorvolle Art sein, dies zu erreichen.)

Mir persönlich gefällt die freundliche Methode. Ich glaube an diese Art, Dinge zu tun. Ich gebe jedoch bereitwillig zu, dass es Zeiten gibt, in denen solche Ansätze weniger effektiv sind.

Aber was ist das Beste?
Ihre grundlegende Frage lautet: "Wie soll ich darauf reagieren?"

Im Grunde läuft diese Frage darauf hinaus, zu sagen: „Ich muss irgendwo hin. Soll ich ein Einrad, einen Pogostick, ein Fahrrad oder einen Bus benutzen?“

Jeder dieser Transportansätze kann am besten sein. Um die Frage zu beantworten, wie Sie reagieren sollten: Ihre beste Reaktion ist möglicherweise nicht meine beste Reaktion.

Dies ist ein wesentlicher Grund dafür, dass, obwohl die unterschiedlichen Antworten übereinstimmen, dass das Verhalten der Praktikanten nicht für Produktionsergebnisse geeignet ist, die unterschiedlichen Antworten unterschiedliche Ansätze zu begünstigen scheinen. Wie bereits erwähnt, haben wir möglicherweise keinen einheitlichen Ansatz, der für alle am besten funktioniert.

Wir haben es hier mit Menschen zu tun, was also in einigen Szenarien am besten funktioniert, funktioniert in anderen Szenarien möglicherweise nicht so gut. Einer der Schlüsselfaktoren sind Sie. Kannst du streng sein, ohne Brücken zu brechen? Können Sie sich mit ihnen anfreunden, indem Sie unbeschwert sind und dennoch genügend Compliance und Inspiration sicherstellen, um die gewünschten Ergebnisse zu erzielen? Was für mich am besten funktioniert, könnte für Sie schrecklich schrecklich sein. Letztendlich müssen Sie entscheiden, welchen dieser Ansätze Sie wählen sollen.

Flexibler Unterricht: Legen Sie sich nicht nur auf einen Ansatz fest.

Wählen Sie einfach die Methode, mit der Sie sich am wohlsten fühlen. Stellen Sie sicher, dass Sie es nicht übertreiben (schlechte/beleidigende Stimmung oder das Schaffen einer unangenehm bedrohlichen Umgebung, um streng zu sein).

Ganz gleich, für welchen Ihrer hervorragenden Vorschläge Sie sich entscheiden, weiterzumachen, behalten Sie die Ergebnisse genau im Auge.

Es ist sehr gut möglich, dass Sie eine Entscheidung treffen, die nicht wie erhofft funktioniert. Solange Sie keine größeren Probleme verursacht haben, kann dies sehr gut wiederherstellbar sein, wenn es positiv und schnell gehandhabt wird. Das ist ein Grund, warum Sie sich nicht zu viele Gedanken darüber machen sollten, die perfekteste Entscheidung zu treffen. Wenn die Dinge nicht gut laufen, kann Ihre Situation gut ausgehen. Menschen sind unterschiedlich und Lernen kann unvorhersehbar sein, und es muss keine Schande sein, wenn ein erster Ansatz geändert werden muss. Solange Sie sich schnell erholen, kann dies kein Problem sein.

Der Schlüssel ist, Änderungen vorzunehmen, sobald Sie anfangen, unerwünschte Ergebnisse zu finden. Erwarten Sie, dass Sie sich schnell anpassen müssen. Wenn ein Ansatz nicht funktioniert, seien Sie bereit, den Ansatz schnell zu ändern oder ihn sogar ganz aus dem Fenster zu werfen. Wenn das, was Sie tun, nicht funktioniert, stellen Sie fest, ob Sie wahrscheinlich kurz vor einem Durchbruch stehen oder ob Sie etwas anderes ausprobieren müssen. (Das Einholen von Feedback hilft bei dieser Entscheidung.) Wenn Sie etwas anderes ausprobieren müssen, dann tun Sie es. Machen Sie so lange weiter, bis Sie Arbeitsergebnisse erhalten.

Solange Sie schnell handeln (bevor sich langfristige Gefühle wie Bitterkeit breit machen), können kleinere Mängel im Vergleich zu den positiven Ergebnissen, die Sie insgesamt erzielen, leicht als unbedeutend beiseite geschoben werden. (Stellen Sie einfach sicher, dass die Probleme geringfügig sind, wenn die Dinge nicht perfekt laufen. Größere Fehler können etwas schwerer zu vergessen sein. Zum Beispiel kann versuchter Humor gefährlich sein.)

Wenn Sie zum Beispiel feststellen, dass sie anfangen, Sie zu hassen, die Umwelt zu fürchten usw., stellen Sie sicher, dass alle Missverständnisse geklärt werden. Versichere ihnen, dass du auf ihrer Seite bist. Gewünschtes Verhalten fördern. usw.

Vor zwei Jahren war ich in einer ähnlichen Situation wie die Praktikanten in Ihrem Unternehmen. Ich kann mir ein Szenario vorstellen, in dem ich etwas Ähnliches getan hätte. Ich denke, einige Praktikanten haben ein Problem mit Ihrer Autorität; pedantisch und/oder unprofessionell sein. Das liegt vor allem an einem Mangel an Respekt, den meine Generation gegenüber Älteren und denen in höheren Positionen hat. Ich würde die folgenden Methoden ausprobieren, um die Situation zu lösen.

  • Verdiene dir den Respekt der Praktikanten, indem du den "Anführer", "Alpha", überlistest.

  • Verwenden Sie den pedantischen Funktionsnamen als Lektion für alle, optimale Länge des Funktionsnamens: Goldlöckchenzone.

  • Weisen Sie auf einen Fehler in der Funktion "convertToMillilitersBecauseIAmUsingSuchCleanCode" hin und schlagen Sie eine Umbenennung in etwas Angemessenes (/Erniedrigendes) vor.

  • Nicht beachten, den Funktionsnamen ignorieren; Konzentrieren Sie sich auf die Personen, die lernen möchten.

Die Namen der unprofessionellen Praktikanten notiere ich mir vorsichtshalber.

Interessant. Ich bin eigentlich nur 3-4 Jahre älter als die Praktikanten, also behandeln sie mich nicht mit Respekt (obwohl ich viel mehr Erfahrung habe). Der Typ, der es gemacht hat, ist dort eigentlich eine Art "Alpha", also werde ich wahrscheinlich einfach den Namen der Funktion auf das Whiteboard schreiben und die Praktikanten fragen, ob sie den Namen für gut halten und wie sie ihn besser benennen würden. Der Name des Praktikanten wird notiert.
@Scramjet Ich mag die Whiteboard-Idee irgendwie. Ich wollte eine Antwort schreiben, in der Sie lächerliche, rhetorische Fragen stellen sollten, um den richtigen Namenspunkt nach Hause zu bringen. Etwas wie, Wow! Because of your "clean code" you can convert anything to millimeters?! I'm real curious how you convert 'Hello World' to millimeters!Andere zu fragen, was ihrer Meinung nach eine Funktion basierend auf dem Namen tut, wird definitiv die Wichtigkeit zeigen
"Andere fragen, was sie denken, was eine Funktion basierend auf dem Namen macht" xD Das gefällt mir.
@Scramjet Ich denke, ein Teil des Problems ist, dass sie Sie als Kollegen und nicht als Autorität sehen. Entscheiden Sie sich für einen aggressiveren und vor allem humorvollen Ansatz. Er versucht, auf Ihre Kosten einen Lacher zu bekommen, ein paar auf seine Kosten.
Das scheinen schreckliche Ideen zu sein. Ehrlich gesagt, als Nicht-Praktikant ist es die Rolle des Praktikanten, sich den Respekt der Person zu verdienen, die tatsächlich ihren Lebensunterhalt verdient, nicht umgekehrt. Wenn das OP könnte, würde ich vorschlagen, den Praktikanten zu entlassen, der den Kodex wegen unprofessionellen Verhaltens begangen hat.
Ich denke, Sie verwechseln eine Gruppe Erwachsener (über die das OP die Verwaltungsbefugnis hat) mit einem Rudel Wölfe ...

Als Profi seit fast 30 Jahren würde ich sagen, dass die hoch bewerteten Antworten meistens richtig liegen.

Als professioneller Softwareentwickler seit fast 30 Jahren sage ich jedoch, dass Codierungsrichtlinien fast immer zu streng sind . Schlimmer noch, oft wird dies von Leuten aufgegriffen, die sich mehr um ihre Autorität als um die Erstellung von lesbarem Code kümmern. Diese Art von passiv-aggressivem Verhalten von Nachwuchsingenieuren ist genau das, was man normalerweise sieht, wenn das passiert.

Das Einfügen dummer Dinge in Codekommentare oder sogar die Benennung von Bezeichnern ist wirklich eine altehrwürdige Tradition unter Softwareentwicklern. Hier ist ein Beispiel für eine durch Standards induzierte Protestbenennung aus meiner eigenen Jugendzeit (die 48 positive Stimmen erhielt).

Wenn es hier ein Problem gibt, sollte es legitime Lesbarkeits-/Wartungsprobleme mit dem Quellcode in Ihrer Umgebung geben. Ich sage nicht, dass die Top-Antworten hier falsch sind. Das sind sie nicht. Aber wenn Sie diese Art von Verhalten von mehreren Junior-Ingenieuren sehen, dann sollten Sie nach der Säuberung der Leichen wirklich prüfen, ob es einen tieferen Grund geben könnte, warum Ihre Kanarienvögel immer wieder sterben .

Das Endziel muss die Codequalität sein. Programmierrichtlinien sollten nur ihr Werkzeug sein, um ihnen dabei zu helfen, dorthin zu gelangen, erstellt von Entwicklern für Entwickler, nicht irgendein autoritäres Programm zum Schreiben von Programmen.

Soll ich durch reagieren

  • darüber lachen ("Ja, es ist lustig, aber bitte entferne es")
  • nur höflich darum bitten, sie zu entfernen
  • sagen, dass ich es nicht mag, wenn jemand meine Zeit verschwendet und er die Codeüberprüfung ernster nehmen sollte

Wie wäre es mit " Verstehen, warum sie das getan haben? "

Wenn jemand etwas tut, was Sie nicht erwarten oder wünschen, können Sie entweder darauf reagieren, um ihn dazu zu bringen, das zu tun, was Sie von ihm wollen, oder Sie können versuchen zu verstehen, warum er genau das getan hat.

Es könnte nützlich sein, zu verstehen, warum. Wenn sie von Natur aus verspielt sind, aber ihren Frust über etwas nicht ausdrücken können, kann jemand es so kanalisieren. Wir sind uns alle einig, dass dies keine positive Art ist, es zu kanalisieren.

Ein alternativer Ansatz

Was ist also ein positiver Weg, um Frustration und Verspieltheit zu kanalisieren? Ich habe in Unternehmen gearbeitet, in denen Leute manchmal 10 % der Zeit Projekte durchgeführt haben, wie zum Beispiel das Programmieren eines Mikrocontrollers, um ein Selfie mit einer DSLR zu machen. Sie hatten nicht nur freie Hand, sondern auch die Verantwortung, daraus ein versandfähiges Produkt zu machen. Es ging von einem eintägigen Hackathon zu Codebeispielen, die jetzt auf der Website des Unternehmens veröffentlicht werden. Die Leute können dieses Beispiel nehmen und es in eine Fernbedienung für Tiefseekameras verwandeln, die mit einem Knopfdruck eingeschaltet werden kann.

Mein Punkt ist, dass Streiche wie dieser ein Hinweis auf ungenutztes Potenzial sein können. Wenn Sie Praktikanten wünschen, die dem Standard entsprechen, den Sie in Ihrem Unternehmen haben, ist dieses Potenzial nicht für Sie und in diesem Fall sollten Sie erwägen, sie zu entlassen. Wenn Sie jedoch den Wert darin sehen, die Dinge aufzurütteln, bringen Sie diese Witzbolde dazu, mit ihren Streichen etwas Nützliches zu erschaffen. Letztendlich liegt es an Ihnen. Wer sollen diese Praktikanten sein?

Es hört sich so an, als hätten Sie ein sehr gutes Beispiel, um ihnen zu zeigen, warum die Verwendung dieser Art von Codierungskonvention selbst für kleine Projekte wie dieses unangemessen ist.

Du hast es gesehen.

Auch wenn ihr Projekt nicht direkt vom Unternehmen verwendet wird, soll es als Bewertung ihrer Fähigkeiten und teilweise als Lernerfahrung für diese Praktikanten dienen, die ihren Weg in Ihr Unternehmen finden möchten.

Ich würde nicht zu hart zu ihnen sein – schließlich ist dies nur eine Prüfung für sie – aber ich würde auf jeden Fall darauf hinweisen, dass solche Programmierpraktiken sie in Zukunft in Schwierigkeiten bringen könnten, besonders wenn ihr nächster Chef es nicht ist so geduldig mit ihnen wie Sie sind.

Aus gutem Glauben heraus sagt mir mein Bauchgefühl, dass die Praktikanten das getan haben, weil sie wirklich kein Problem mit Namen wie sehen können convert. Ich würde eine kleine Summe Geld wetten, dass die sarkastischen Namen nicht aus dem Wunsch heraus entstehen, rebellisch zu sein, sondern aus der Frustration, dass sie nicht wissen, wie sie auf einen besseren Namen kommen sollen, sondern nur auf einen längeren Namen. Und das hast du ihnen irgendwie gesagt, richtig ? Kurz schlecht, lang gut.

Wenn Sie möchten, dass sich diese Personen verbessern, müssen Sie einfach in der täglichen Besprechung besprechen, warum genau convert ein schlechter Name und convertInchesToCentimetersein besserer Name ist. Wenn Sie ein Beispiel aus Ihrer Erfahrung mit einer schlechten Namenswahl haben, die Probleme verursacht, wird ihnen das helfen. Dieses "Warum" wird ihnen von nun an erlauben, gute Namen zu wählen - ob diese guten Namen lang oder kurz sind.

Lassen Sie sie auch wissen, dass es in Ordnung ist, Sie oder ihre Kollegen um Hilfe zu bitten oder sich mit ihnen in angemessenem Rahmen zu beraten, dass dies kein Test ist, bei dem jeder alleine arbeiten muss, sondern eine Zusammenarbeit. (Ich hoffe, das stimmt!) Vielleicht ermöglicht es ihnen das, Fragen zu stellen und miteinander zu reden und Frustrationen frühzeitig zu lösen, anstatt darauf zu warten, dass passiv-aggressive Dinge wie diese in der Codeüberprüfung auftauchen.

Nur wenn ein solches Verhalten anhält, halte ich es für notwendig zu erklären, ja, dies ist keine echte Anwendung, aber diese Übung und die Stilrichtlinien sollten aus mehreren Gründen ernst genommen werden:

  • Es ist meine Zeit wert, diese Bemühungen mit Ihnen zu verbringen, wenn ich an "echten" Anwendungen arbeiten könnte, also geben Sie bitte auch Ihr Bestes
  • Diese Übung bereitet Sie darauf vor, an einem echten Projekt zu arbeiten, das ernsthaft ist und bei dem Sie Stilrichtlinien befolgen müssen
  • Anhand dieser Übung können wir entscheiden, wem von Ihnen ggf. nach Abschluss Ihres Praktikums Beschäftigungsangebote unterbreitet werden

Obwohl es nicht ganz falsch ist, denke ich, dass es das Verhalten wahrscheinlich zum Schweigen bringen wird, wenn man sie an dieser Stelle der Respektlosigkeit usw. beschuldigt, aber es wird ihnen auch nicht helfen zu verstehen, warum sie bessere Namen brauchen oder wie sie auf bessere Namen kommen. Wenn Sie diesen Weg einschlagen, werden Sie vielleicht feststellen, dass sie sich nur längere schlechte Namen einfallen lassen und Ihrem stählernen Blick ausweichen.

Ich bin auch nicht gut darin, Dinge zu benennen, aber der Name im OP ist etwas, das ich nie auswählen würde. Diese Antwort ist eine Ausrede für die Praktikanten; Sie sind auf dem College und wahrscheinlich in den Zwanzigern, sie wussten genau, was sie taten.
+1 für die Erwähnung, dass es durchaus sein könnte, dass sie das Konzept beschreibender Namen nicht verstanden und nur "längere Namen" verstanden haben. Sie werfen jedoch kein helles Licht auf sie.

Das finde ich erstmal gar nicht so schlimm . Sie haben einen Witz über ein Thema (Namenskonventionen) in den Code eingefügt, das sie wahrscheinlich nicht vollständig verstehen. Einige interne Witze in den Code einzubauen ist nichts Neues. Außerdem können sie den Code als "internes Blatt" betrachten.

Ich stimme auch nicht der Ansicht zu, dass sie Ihre Zeit damit verschwenden. Wenn sie einen Commit machen, nur um eine Methode umzubenennen, verschwenden sie Ihre Zeit, und die Änderung sollte abgelehnt werden. Aber wenn sie eine neue Methode brauchten und einen schlechten Namen wählten, wäre die Zeit für die Überprüfung bei beiden Namen ähnlich. Ich weiß nicht, ob Sie Pre-Commit oder Post-Commit überprüfen, aber wenn jemand Code genehmigt/zusammengeführt haben möchte, arbeitet er tatsächlich gegen sich selbst, da er einfach Roundtrips hinzufügt, um den Code tatsächlich zu akzeptieren .

Es ist auch trivial, mit falschen Namen negativ zu bewerten, ohne wirklich zu schauen, was der Code tut. Das Problem ist, dass Sie sich über diese Namen ärgern.

Nun, um auf die eigentliche Frage zu kommen, was zu tun ist, empfehle ich, darauf hinzuweisen, dass sie einige Probleme mit Namenskonventionen hatten, und sie zu bitten, die Arbeit der letzten Woche zu überprüfen, um zu sehen, ob sie Eigennamen verwendet haben, und zu überlegen, ob sie es verstehen würden leicht in ein paar Jahren / wenn sie neu zu diesem Projekt kamen. Lassen Sie sie einen kurzen Bericht über die Funktionen erstellen, die sie in dieser Woche hinzugefügt haben, und sie kurz begründen.

Idealerweise wäre das etwa eine Zeile pro Funktion, z.

convertGalToml: Konvertiert Gallonen in Milliliter. Camel Case wurde nicht für die Abkürzung Milliliter verwendet, um Verwechslungen mit Megalitern zu vermeiden.

Es wird erwartet, dass sie beim Überprüfen des Codes neue Probleme bemerken oder sich einen besseren Namen ausdenken, z. umbenennen convertGalTomlin convertGal2ml.

Ich vermute, Ihr Joker wird den Punkt verstehen und ihn stillschweigend umbenennen.

Der Punkt ist, Funktionsnamen sind Dokumentation. Obwohl es ein eher technisches Publikum ist als zB. B. dem Benutzerhandbuch, sollten sie sich wohlfühlen, ihre Wahl vor ihren Kollegen zu rechtfertigen.

Während das Verhalten der Praktikanten unprofessionell sein mag, ist es auch unprofessionell für das Management, nicht zu berücksichtigen, dass sie sich irren könnten. Eindeutig convertkann in vielen Kontexten zu kurz oder mehrdeutig sein, convertGallonsToMillilitersist aber viel zu lang für einen Bezeichnernamen. Anstatt willkürliche Anforderungen an die Ausführlichkeit von Namen allgemein zu stellen, sollten Sie Ihre Praktikanten herausfordern, zu rechtfertigen, wenn ein von ihnen gewählter Name wirklich mehrdeutig ist (was sie nicht können) und sich etwas Vernünftiges einfallen lassen, das die Lesbarkeit des Programms verbessert, anstatt es zu behindern es.

Das fühlt sich für mich wirklich wie ein Fall des allgemeinen Musters an: "Warum respektieren mich meine Untergebenen nicht?" Es geht wirklich darum, "was ist mit meiner eigenen Einstellung, die dazu führt, dass die Leute meine Position nicht respektieren?"

Namenskonventionen sind höchst subjektiv. Anstatt diese Antwort wie "OP, du liegst falsch" zu formulieren, solltest du dich vielleicht einfach auf die Tatsache konzentrieren, dass es sich um ein subjektives Thema handelt und dass eine Rechtfertigung von beiden Seiten und sie selbst etwas Besseres vorschlagen zu lassen, ein besserer Ansatz sein könnte ( obwohl dies bereits in anderen Antworten behandelt wird). Aber es ist fraglich, ob OP sie tatsächlich davon überzeugen könnte, sich an Unternehmensstandards zu halten (letztendlich sollte jeder Mitarbeiter in der Lage sein, seine individuellen Stilpräferenzen zu ignorieren, wenn sie mit Unternehmensstandards in Konflikt geraten).
Namenskonventionen sollten den Regeln im bestehenden Projekt folgen.
Daran sehe ich nichts auszusetzen convertGallonsToMilliliters. Ich sehe auch nichts falsch convertdaran, wenn es sich um eine allgemeine Konvertierungsroutine handelt. Ich sehe eine ganze Menge falsch mit zB cvtGtoM, cvtGals2Millis, und verschiedenen anderen abgekürzten Namen. Ich mag schöne lange Namen, die ausdrücken, was eine Routine tut - weil ich aus bitterer Erfahrung weiß, dass die Entwicklung nur einmal stattfindet, die Wartung jedoch ewig andauert und der Code, den Sie pflegen, möglicherweise Ihr eigener ist. :-)

Sie sind nicht ihr Manager, es spielt sogar keine Rolle, ob Sie sie interviewen oder nicht. Du bist ein Ingenieur wie ich,

Damit Sie wissen, was zu tun ist, sprechen Sie mit Ihrem Vorgesetzten und schlagen Sie dann eine Codeüberprüfung vor. Dann raten Sie ihnen, solchen Code nicht über ein System wie Code Collaborator zu schreiben. Sie müssen ihnen nicht einmal eine E-Mail schreiben oder mit ihnen interagieren oder diese Dinge persönlich nehmen. Führen Sie ein Bewertungssystem ein, das auf dieser Codeüberprüfung basiert. Versuchen Sie nicht, sie zu kontrollieren oder ihr Manager zu sein, oder versuchen Sie es mit Menschenführung. Das ist nicht deine Angelegenheit.

Sprechen Sie mit Ihrem Vorgesetzten und behalten Sie das Privileg, Commits nach einer Überprüfung abzulehnen oder zu genehmigen, für sich. Angenommen, jeder Praktikant hat anfänglich 10 Punkte, und er/sie sollte durch Ihre Einstufung 100 Punkte verdienen, und wenn er wirklich Ihrem Team beitreten möchte, wird er motiviert sein, dies zu erreichen. Um keine Punkte zu verlieren.

Wenn ich ein Praktikant war und unter Ihnen arbeite und Sie nur ein leitender Ingenieur sind, hasse ich es sogar, wenn Sie mein Personalmanagement übernehmen. Es ist NICHT Ihre Aufgabe.

Es klingt für mich, dass Sie zu weit gegangen sind und es außer Kontrolle geraten ist. Lernen Sie diese Lektion als Ingenieur. Sie sind ein Ingenieur, nicht ihr Manager, der von Menschen verwaltet wird.

Code-Reviews sind keine Personalverwaltung. Verwechseln Sie die beiden nicht.
Nein, ich wollte nie, dass Leute über Code-Reviews verwalten. In der OP-Frage erwähnte er, dass er Praktikanten hilft und sich an Code-Reviews beteiligt. Das hat also nichts mit Personalführung zu tun. Dies ist nicht der richtige Weg, um eine Codeüberprüfung durchzuführen. Ich behaupte nachdrücklich, dass diese Frage, wie man eine ordnungsgemäße Codeüberprüfung durchführt, auch nicht hierher gehört.
Code-Reviews sind keine Personalverwaltung. Verwechseln Sie die beiden nicht. das ist mein Punkt. Warum also Downvotes?
Sie sagen, dass das OP niemanden verwalten sollte, aber gleichzeitig sagen Sie ihm, er solle ein gamifiziertes Leistungsbeurteilungssystem einrichten. Aber ich schätze, der Hauptgrund für die Ablehnung ist der fragwürdige Hinweis, dass ein technisches Profil nicht funktionieren kann oder sollte.
Es ist ein gültiger Vorschlag, Personalmanager sollten sich bei Bedarf um das Personalmanagement kümmern.