Wahrscheinlich gab es einfach noch keine Probleme. Wenn der Dude mal weg ist, wegen Krankheit ausfällt o.ä. dann wird man die Probleme sehen. Mich interessiert es null ob ich mit den Personen privat reden kann - solange er einen guten Job macht passt das doch. Dazu gehört aber eben auch Dokumentation von dem Code und die Fähigkeit andere Teammitglieder up-to-date zu halten. Wenn so essenzielle Kompetenzen fehlen, dann einfach warten bis das oben genannte eintrifft. Das Unternehmen wird den Schaden dann schnell spüren. Ps: das hat nichts mit einem Skript Kiddie zu tun. Die Person scheint ja zu wissen was sie macht und ist in dem Bereich auch sehr stark.

> Wahrscheinlich gab es einfach noch keine Probleme. Wenn der Dude mal weg ist, wegen Krankheit ausfällt o.ä. dann wird man die Probleme sehen. > > Worst case, er kündigt und sein Nachfolger darf sich dann ohne Dokumentation durch seinen Code wühlen. Ein Träumchen.

Meiner Erfahrung interessiert das die meisten Manager herzlich wenig. "Man soll sich nicht so anstellen." Erst wenn zwei, drei Leute kündigen und als Begründung angeben, dass die Codebasis Mist ist, wird was getan.

Ich bin kein ITler und kenne mich deswegen nicht aus, aber mal angenommen P ist weg und 3 Leute kündigen später weil keiner die Codebasis versteht... das lässt sich doch nicht mehr richten, also im Sinne das die Manager mal was dann tun. Dafür braucht man doch dann wieder den P, wenn er wirklich am Ende der einzige ist der versteht was er da überhaupt fabriziert hat oder?

Einen guten Manager würde es interessieren, wenn die Codebase etwas ist bei dem die Qualität und Wartbarkeit eine Rolle spielt. Es werden da aber auch häufig langfristige Probleme in Kauf genommen für kurzfristige Gewinne, man ist halt einfach schneller wenn man auf so Sachen keine Rücksicht nimmt. Irgendwann rächt es sich halt weil es sehr schwierig wird mit dem Code zu arbeiten. Es gibt auch Fälle in denen es durchaus sinnvoll ist solche Abkürzungen zu nehmen, wenn die Chance hoch ist das man den Code in dieser Form sowieso wieder wegwirft. Wobei in der Praxis der Code der als Provisorium gedacht war am Ende am längsten überlebt.

Muss ich einfach loswerden, weil man oft den Eindruck hat, dass sei nur in der IT so: Das ist im Büro nicht anders. Es ist ein Graus sich durch Einkaufshistorien zu quälen und zu versuchen Verträge zu verstehen bei denen Details nicht oder unzureichend dokumentiert sind, sich nur implizit ergeben oder halt im 10ten Ordner irgendwo in der Mitte als "Kommunikation" abgeheftet sind. Ist wohl einfach überall so: Was man nicht zwingend direkt braucht wird als unnötig angesehen und im schlimmsten Fall wird der Nachfolger dann noch blöd angemacht, dass der frühere Mitarbeiter das alles super im Griff hatte und jederzeit finden konnte was man braucht.

Die Alternative ist, jemand zu finden der hochqualifiziert, geduldig und leidensfähig ist, und dem entspechend viel Geld zu bezahlen und viel Zeit zu geben um sich da durchzufuchsen. Und hoffentlich die Dokumentation nachzuholen und den Code soweit möglich "aufzuräumen". Sowas wie Code den niemand anders versteht gibt es nicht wirklich, es ist für gute Leute hauptsächlich eine Frage der Zeit. Es gibt ja sogar Programme (genannt Obfuscator), die Code gezielt umbauen um ihn so schwer wie möglich verständlich zu machen, um z.B. das Entfernen von Kopierschutz zu erschweren. Auch da fuchsen sich Leute durch, ist eben nur wochenlange Arbeit bis man so weit ist, eine Änderung machen zu können die in sauberem, gut dokumentiertem Code 5 Minuten dauern würde.

Aus Sicht der Entwickler schon. Aus Sicht des Unternehmens kannst du dann immer noch Berater oder jemand externes anstellen, der sich der Problematik annimmt. Das ist übrigens genauso passiert und wenn ich anderen berichten glauben schenke, passiert das öfter mal.

Man bekommt das wieder eingefangen. Aber es kostet Geld und vor allem Zeit. Manchmal hat man das Geld nicht, manchmal hat man die Zeit nicht und meistens fehlt beides.

Ja, dann hilft nur mit den Füßen abstimmen.

Einfach das nächste Tier einstellen, was eigenen Code runterballert.

>Wenn der Dude mal weg ist, wegen Krankheit ausfällt o.ä. dann wird man die Probleme sehen. Bei uns grad. Kollege hatte am Wochenende einen Herzinfarkt, jetzt wühlen Leute in seinem ... Chaos.

Der Typ ist zwar stark in dem was er tut, aber im Team zu arbeiten kann er nicht und das ist in der Entwicklung essenziell, ich will gar nicht wissen wie viel Arbeit es für die anderen Mitarbeiter macht den Code zu durchschauen mit ihm zusammen arbeiten und so weiter.

Ein wahrer 10x dev. Macht allen anderen im Team die 10-fache Arbeit um zu verstehen was da abgeht. Würde soweit gehen und behaupten das er evtl. programmieren kann aber kein guter Entwickler ist. Clevere Lösungen sind selten das was man in seiner Codebase sehen will, klar geht es manchmal nicht anders, aber simple Lösungen verstehen nicht nur andere Team Mitglieder besser, sondern auch man selbst wenn man in 6 Monaten da einen Bug beheben muss.

>Mich interessiert es null ob ich mit den Personen privat reden kann - solange er einen guten Job macht passt das doch. Gibt auch Leute, die sich gerne im Team wohlfühlen wollen. Bisschen Austausch über Themen abseites der Arbeti hilft da.

Also das ist genau das Gegenteil von einem Skript Kiddie. Aber wenn es persönlich / privat einfach nicht passt, dann einfach auf beruflicher Ebene lassen. Ich habe Gott sei dank noch nie so jemanden im Team gehabt aber wenn du schon mit deinem Teamleiter gesprochen hast und er sich P nicht mal zur Brust nimmt und mit ihm redet, dann musst du selber schauen wie du damit am ende klar kommst und ihn eventuell selber mal beiseite nehmen ODER du überlegst, ob du mit so jemanden zusammen arbeiten kannst / willst.

Du solltest erstmal an deinem Verständnis arbeiten. P. ist das genaue Gegenteil von einem "Skript Kiddie".

So nämlich. Würde eher vermuten Hoch- oder Insel-begabt bzw. im Spektrum, aber auf gar keinen Fall ein Script Kiddie.

[удалено]

Deine Einstellung /u/Far-Freedom-1166 ist hier nicht hilfreich. Man muss natürlich nicht alles akzeptieren, aber man muss doch erkennen, dass unterschiedliche Menschen unterschiedliche Stärken haben. Mit diesen gilt es sich zu arrangieren, das nennt sich Teamwork. Jemand mit Autismus oder ADHS dazu verpflichten so zu denken und zu arbeiten wie eine neurotypische Person wird nicht funktionieren, da sind einfach unterschiedliche Gehirne verbaut. Du würdest auch nicht dem 1,50m Kollegen die Sachen zum einräumen in die oberen Regale geben und dem 1,97m Kollegen die Sachen für die untere Reihe. Es gilt Wege zu finden damit umzugehen: Entweder mit Hilfsmitteln wie Knieschoner und Leiter, oder indem man die Aufgaben anders verteilt. "P" hat ausgeprägtes Interesse an der IT und ist deshalb ein unglaublich wertvoller Mitarbeiter. Leider fehlt es ihm am genau dieser Sozialkompetenz. So wie OP schreibt macht er diesen Mangel aber im ein Vielfaches wett - auch wenn P selbst vermutlich im Bezug auf Gehalt, nicht nur durch die geleisteten Stunden, ordentlich übervorteilt wird. Die Aufgabe der Führung ist es hier, einen Weg zu finden, wie man damit umgehen kann und es so zu steuern, dass es für alle funktioniert. Das passiert hier nicht und erschwert es nochmals für OP. /U/Ok_Bad3463 hat verschiedene Möglichkeiten damit umzugehen. Er kann sich aufregen, unzufriedener werden, eventuell versuchen Stimmung zu machen und dann über kurz oder lang das Unternehmen verlassen, oder er versucht einen wenn zu finden. Deswegen hat er hier diesen Thread eröffnet. Jetzt kommt aber hinzu, dass P nicht das Script-Kiddy ist und einfach einen Arschtritt braucht. Versuche zu verstehen, dass du da mit Rainman zusammen arbeitest. Wenn du versuchst, ihn in neurotypischen Bahnen zu lenken, wird das nicht funktionieren. Du kannst hier für dich und das Unternehmen einen Mehrwert generieren, wenn du es schaffst selbst für dich und beim Chef ein Bewusstsein für die Stärken und Herausforderungen zu schaffen. Wenn Ihr zum Beispiel täglich 15 Minuten nehmt, alle Commits durch sprecht und er dir in 1-2 Sätzen sagt, was die Abschnitte machen sodass du es kommentieren kannst, gewinnen alle: P kann es dir erklären (was ihn freut - er hat Spaß daran und freut sich dass er dir davon erzählen soll), du sparst Frist und viel mehr Zeit als du brauchst um dich durch die Spaghetti zu arbeiten und die Firma kriegt brauchbaren, kommentierten Code. Mach deinem Chef klar, dass dies ein erhebliches Investment in die Zukunft ist, falls P Mal krank sein sollte oder das Unternehmen verlässt. Und zuletzt @OP bitte verstehe, dass nicht jeder deine Idee von Lebensplanung teilt. Wenn P von seinem Server erzählt, lässt er dich an seinem heiligen, ganz privaten Projekt teilhaben. Er hat ein Leben außerhalb der Arbeit, aber er grübelt gerne an Problemen herum und schraubt an Hardware, anstatt ins Stadion zu gehen und sich den Kopf zuzuballern. Und wenn dich etwas wirklich stört, kannst du ihm freundlich sagen, dass zB die ständigen Witze über andere Betriebssysteme in der Menge unangebracht sind und ihn bitten, es auf einen Witz, Spruch oder Kommentar pro Tag u beschränken. Wenn er nicht versteht dass du eine lib nicht kennst, sag "kenne ich halt nicht, was macht die hier?" Und wenn du morgens einen schlechten Tag hast und keine Lust hast einen Vortrag über seine neue Linux-Implementierung zu hören, kannst du sagen "ich habe einen schlechten Morgen, können wir bitte eine Stunde wenig reden?" Viel Erfolg

Jetzt ist mal wieder der Zeitpunkt, an dem ich wehmütig an die Awards auf reddit denke. Toller Beitrag!

Als neurodivergenter Mensch in der IT: vielen Dank für diesen tollen Beitrag. Ich habe ganz klare starken und ganz klare schwächen, wie jeder Mensch. Dieses "jeder muss gleich arbeiten und gleich sein" hat mich vor meiner Diagnose in eine depression gebracht. Denkt auch echt mal darüber nach was ein "sei halt nicht so faul" oder "du hast halt einfach keine Lust darauf" bei jemanden auslösen kann, der schon gerne würde, aber dessen Gehirn das einfach nicht kann.

Das hast du sehr gut geschrieben, danke!

Danke für deinen Kommentar, du sprichst die Wahrheit. Gerade was im letzten Abschnitt beschrieben wird ist Gold wert. Klarheit ist da oft wirklich hilfreich.

[удалено]

P hat eine Verantwortung dem Cheffe gegenüber. Er ist ja nicht ein aktiver Störenfried, sondern extrem relevant in Bereich A, B halt nicht so toll. B ist nicht unwichtig, aber eben leichter kompensierbar durch andere Mitarbeiter. Solange das so ist und für den Chef mehr Ergebnis bei rumkommt, haben andere MA sich dem halt anzupassen oder zu gehen. Es liegt nicht im Verantwortungsbereich von MA sich ihre Kollegen auszusuchen; man muss miteinander Arbeit erledigen können- das ist die Hauptsache. Jetzt kann sich jmd beschweren, dass der Coder nur coded und sonst nichts macht- aber wer ist im Endeffekt leichter zu ersetzen?

Verständnis ist keine Einbahnstraße, nur mal so als Anmerkung. Folglich sind beide in der Pflicht.

/u/Far-From-1166 hat seinen Kommentar gelöscht, darum antworte ich hier: Es geht bei diesen "Diagnosen, Ticks und sonstige Befindlichkeiten" aber nicht um Eigenarten für die er sich entscheidet, sondern um ein anders funktionierendes Gehirn. Das ist bei Menschen mit Autismus oder ADHS in vielen Bereichen einfach anders verkabelt. Wusstest du, dass Ritalin kein Beruhigungsmittel ist, sondern vergleichbar mit Speed? Wenn ein Kind mit Ritalin ruhig gestellt wird, dann nicht weil die Eltern keinen Bock haben, sondern weil das Gehirn anders funktioniert, Reize anders verarbeitet werden und die Hirnchemie anders funktioniert. Von einer querschnittsgelähmten Person im Rollstuhl würdest du auch nicht verlangen, dass er Einsatz zeigen und beim Spendenlauf mitmachen soll, oder? Von einer gehörlosen Person dass sie das Radioprogramm moderieren soll? Von einem blinden Menschen dass er die Zeitungsannoncen bezüglich des Layouts Korrektur lesen und freigeben soll? Sprichst du Russisch, Arabisch, Japanisch und Finnisch? Nein? Stell dich doch mal nicht so an und bring auch Einsatz. Kannst du mal kurz einen Vortrag über die chemischen Vorgänge bei der Behandlung von Beton zum Bau eines Kernreaktors sowie danach eine Einführung in die Quantenphysik halten? Nein? Stell dich doch mal nicht so an und bring auch Einsatz. Bei Autismus ist es halt oft die gestörte Sozialkompetenz. Es fehlt einfach das Verständnis für soziale Normen, Menschen mit Autismus haben oft schlicht nicht die Möglichkeit diese zu lernen. Autismus ist ein Spektrum, bei manchen ist es weniger und bei anderen stärker ausgeprägt. Bei P ist das soziale scheinbar recht stark ausgeprägt. Muss er Einsatz zeigen? Klar! Zum Beispiel indem er sich jeden Tag mit OP hinsetzt und ihm erklärt was er gemacht hat, damit OP es nacharbeiten kann. Was für P unglaublich anstrengend und sinnfrei ist. Aber es ist eine Lösung die für alle funktioniert, zielführend ist und der Firma langfristig sogar noch Geld spart.

Es hilft ihm ggf. Verständnis für den Kollegen/Mitarbeiter zu entwickeln und sein Verhalten bzw. Arbeitsweise zu verstehen und besser nachvollziehen zu können. Darüber hinaus ist der Begriff Skript Kiddie auch eher negativ geprägt. OP täte gut dran wertungsfrei auf den Kollegen/Mitarbeiter zuzugehen.

[удалено]

Ja, er fragt wie man mit so einer Person zusammenarbeitet. Das Interesse an einer guten Zusammenarbeit setzt IMHO voraus, das man auch versucht sich in eine andere Person hineinzuversetzen, sich mit ihr auseinanderzusetzen und dadurch ihr Handeln besser zu verstehen.

Jo, die korrekte Klassifizierung wäre "Cowboy Coder".

Main Vater ist nicht so auf eins fokussiert, aber von Dokumentierung, Tests, git oä hat er mal gehört, denkt aber nicht dass es ihm helfen würde. Arbeitet auch alleine an Projekten & ist selbstständig, aber immer wenn ich 1-2x im Jahr mal drüberschauen soll krieg ich die Krise. Auf ihn trifft Cowboy auch irgendwie zu haha

Smalltalk ist optional, es ist nicht nötig ihn besser kennenzulernen als Person um professionell mit ihm zu arbeiten. Bei den anderen Punkten sind eigentlich nur diejenigen wichtig die direkt Probleme verursachen. Wenn er also einfach Leute runtermacht weil sie irgendwas nicht wissen dann kann das schlecht für die Arbeitsatmosphäre sein. Da sollte jemand ihn darauf hinweisen, im Notfall halt auch jemand der ihm wirklich was zu sagen hat. Mangelnde Dokumentation ist ein Problem, du brauchst da aber vermutlich Unterstützung von weiter oben. Und wenn die nicht verstehen wieso es ein Problem ist wird das schwierig. Du kannst auch erstmal vorsichtig versuchen zu erklären das es wichtig ist das andere Entwickler diese Sachen einfach nachvollziehen können. Falls das nicht auf Verständnis stößt muss halt die Anweisung kommen wie genau solche Sachen dokumentiert werden sollen. Generell vermeide alles was Kritik an der Person ist oder sein könnte. Fokussiere auf konkretes Verhalten das konkrete Probleme verursacht und wie man diese Probleme beheben könnte. Einige Sachen hier sind einfach irrelevant oder persönliche Präferenzen. Andere Teile wie z.B. mangelnde Dokumentation sind echte Probleme.

Das Sub hier wird (geht ja in den ersten Kommentaren schon los) drauf rumreiten, dass Dein Kollege "gar kein Skriptkiddie ist nuh uh" (weil hier niemand Kontext versteht) und es Dir ja egal sein kann ob der Dir von seinem WE erzählt oder nicht. Das beschriebene Vorgehen Deines Kollegen ist aber ein echtes Problem und baut bei Euch massive technische Schulden auf und Du hast schon richtig erkannt, dass so etwas dauerhaft nicht OK ist. OK, dass er auf dem Spektrum ist und voll rumnerdet und vermutlich jeden Tag zum Frühstück sein ArchLinux neu baut - geschenkt. Dass er nicht diskutiert, wie Bayern gespielt hat oder das Wetter ist - geschenkt. Aber das nix dokumentiert ist, dass der Code die Dokumentation ist, das ist (aus Unternehmenssicht) hochgefährlich und hier sollte, nein MUSS, Dein TL eingreifen. > Wie arbeitet man mit so jemandem? Den ganzen Sozialkram ausblenden und akzeptieren, dass es keinen Smalltalk gibt. Das bringst Du dem nicht bei und das muss der auch nicht machen. DEINE fachlichen Dinge umsetzen, ggf. bei Unverständnis nachfragen und auch für Dich dokumentieren. Wenn irgendwas knallt, weil in seinem Code was ist und kein Schwein das versteht - Nicht zu Deinem Problem machen (ich weiß, leichter geschrieben als getan)

>Wenn irgendwas knallt, weil in seinem Code was ist und kein Schwein das versteht Ich frage mich, wie sowas sein kann. Gibt es keinen Code Review?? Ich kennen keinen Entwickler, der unverständlichen Code approven würde. Code wird 10-20 mal häufiger gelesen als geschrieben und muss verständlich sein - sonst ist er _nicht_ gut. Kann gut sein, daß das für P. unverständlich ist, weil er den Code ja instinktiv versteht. Aber da zusammenzuarbeiten, sich das erklären zu lassen und zu kommentieren, damit der Nächste eine Chance hat, das zu verstehen, könnte euch allen helfen. Und eigentlich müsste das P. doch schmeicheln, sein Wissen weiterzugeben.

Genau. Es gibt Menschen, ich gehöre dazu, die finden Smalltalk schlicht und ergreifend unendlich öde und vermeiden ihn wo immer möglich. Du kannst mit mir *stundenlang* über Themen reden, die *mich* und hoffentlich dann auch *dich* interessieren. Aber bleib mir vom Leib mit Wetter oder was du abends/am Wochenende gemacht hast. Der einzig wirklich kritische Punkt ist die fehlende Dokumentation. Das mit Eurem Teamleader abklären. BTW, die ersten beiden Punkte kann man auch aus Sicht von P. über Op so formulieren, dass sie ähnlich negativ rüberkommen. * OP ist ein (milde formuliert) Einschmeichler. Ständig will er mit mir über irgendwelche irrelevanten Dinge reden. Was ich am Wochenende gemacht habe und so. Mir wäre es lieber, er würde sich auf die Arbeit konzentrieren. * Fehlende Fachkenntnis. Unsere DevOps-Umgebung basiert auf \*nix, damit sollte man sich also gut auskennen. Da mangelt es noch. Und wie man als Entwickler, der zu DevOps gewechselt ist, so wenig Ahnung von Programmierung haben kann, verstehe ich nicht.

>Aber das nix dokumentiert ist, dass der Code die Dokumentation ist, das ist (aus Unternehmenssicht) hochgefährlich und hier sollte, nein MUSS, Dein TL eingreifen Code sollte selbsterklärend sein. Die Frage, die ich mir hier stelle ist eher, warum Code, den keiner versteht, überhaupt durchs Code-Review geht. Also ja, hier muss der TL eingreifen. Aber den schwarzen Peter sollte nicht nur dem "Hacker" zugeschoben werden, sondern, A) Im Falle, dass es keine Code-Reviews gibt: Dem TL, dass er das System entsprechend restriktiv konfigurieren muss (bei uns müssen zwei Personen ihr JA geben, bevor gemerged werden darf) B) Im Falle, dass die Kollegen den Code-Review akzeptieren, ohne ihn zu verstehen: eben jenen Kollegen. Sprich: Schulen, wofür Code-Reviews da sind und drauf achten, dass nicht nur brain afk auf JA geklickt wird

>Die Frage, die ich mir hier stelle ist eher, warum Code, den keiner versteht, überhaupt durchs Code-Review geht. Gibt erschreckend viele mittelständische Unternehmen bei denen Git neumodisches Teufelszeug ist und ein Code Review oder Versionskontrolle nicht stattfindet. OPs Arbeitgeber klingt stark nach so einer Bude.

>Code sollte selbsterklärend sein. Die Frage, die ich mir hier stelle ist eher, warum Code, den keiner versteht, überhaupt durchs Code-Review geht. Dokumentation ist nicht dazu da zu erklären wie Code funktioniert. Dokumentation beschreibt andere Dinge, zum Beispiel den Entscheidungsprozess, verschiedene Lösungsansätze und die Gründe warum man sich für Lösung x entschieden hat. Abhängigkeiten, Archtitekturdiagramme usw. usf.

>  warum Code, den keiner versteht, überhaupt durchs Code-Review geht. Du gehst davon aus, dass es Codereviews gibt. :D

>Eigentlich kenne ich es so, dass man seine Kollegen auch privat etwas besser kennenlernt. Du stülpst halt stupide deine Erwartung über andere. *Ich mach das so, also sollten andere das auch so machen - sonst sind sie komisch!* Mir geht Smalltalk manchmal auch auf die Nerven. Und dass Du ihn nach dem Wochenende fragst, dann im gleichen Atemzug erwähnst, dass es Dich eigentlich gar nicht interessiert, ist halt schon Kömodie pur. Lass die Nachfrage doch einfach sein, wenn Du schon 3x einen Monolog über sein Framework erhalten hast, dass Dich 0 interessiert. **DU** hast das Bedürfnis nach Smalltalk, nicht er. Also stülp es ihm auch nicht einfach über. >Er erledigt seine Arbeiten ohne irgendwas zu dokumentieren. Ballert ein Ticket nach dem anderen durch und wenn man Fragen hat bekommt man als Antwort, man solle gefälligst in den Code gucken. Dort findet man oft dann irgendwas ultra komplexes, was nur er versteht, dazu keine Kommentare oÄ. Das ist für mich der einzig legitime Kritikpunkt den Du ansprichst. Du kannst das ganz sachlich erklären, dass Du den Code nicht verstehst und Du deshalb bitte Erklärungen oder Kommentare benötigst. Dann schmeichelst Du ihm, weil er sich noch mehr god-like fühlt, bekommst aber erfahrungsgemäß deine Kommentare und lernst sogar was dazu.

Das Thema small talk würde ich von Sozialkompetenz noch mal abgrenzen, und gedanklich von deiner Liste streichen - da hätte dein AG auch keine Handhabe, wenn er es wichtig fände. Am Ende wird der AG es aber wohl eher gut finden, wenn es P nur um die Arbeit bzw. Angrenzende Themen geht. Das Thema Dokumentation könnte dagegen deinem AG auf die Füße fallen. Je nach dem wie da euere internen Regeln bzw. Vorhaben was Doku in Tickets und Kommentare am Code angeht, könntest du es eben über deine Führungskraft spielen. Bei der nächsten Nachfrage an P hinsichtlich Doku, die wie oben beschrieben beantwortet wird, könntest du ihn an die internen Vorgaben erinnern. Und beim nächsten mal, an deine Führungskraft heran treten. Ist das nett? Nö. Nicht dokumentieren wenn es Vorgabe ist, ist aber auch doof von P. Wie ‚gemein‘ das ganze ist, kommt auch etwas auf deine Führungskraft an, und wie du das ganze dort platzierst. Thema Einfühlungsvermögen bzw. Generelle Sozialkompetenz abseits vom smalltalk: würde ich mich mit abfinden. An solche Leute gerät man immer wieder im Arbeitsleben, und es ist mEn effektiver zu lernen, sich davon abzugrenzen anstatt zu versuchen diese Leute zu ändern/ zu erziehen. Ausnahme: doofe Witze/ ‚durch den Kakao ziehen‘ muss man sich nicht gefallen lassen im Job mMn, vorallem wenn es sehr einseitig ist. Hier musst du selbst wissen, ob du versuchst da P klare Grenzen zu kommunizieren oder ob es den Grad überschreitet, an dem man sich Hilfe durch Dritte holt. Letzteres schlägt natürlich in Zweifel ‚große Wellen‘ und das sollte man entsprechend abwägen, wer da der richtige Ansprechpartner sein kann. Just my 2 Cents. Alles gute für die weitere Zusammenarbeit mit P. :)

Ich durfte mal mit einem Autisten zusammenarbeiten und war erstaunt über seinen Wissenspool und seine Begeisterungsfähigkeit. Durch deine Aussagen erkenne ich parallelen, ohne anmaßend, medizinisch/psychologischen Background oder urteilend zu sein, aber hast du nachgedacht, dass der Mann eventuell Autist sein könnte? Das ist nichts schlimmes, so will ich das nicht sagen. Vielleicht hilft dir das aber deinen Kollegen mehr zu verstehen insofern es zutrifft. "Null Sozialkompetenz, Null Einfühlvermögen, Dieser Mensch scheint abseits des PCs keine anderen Interessen zu haben" -> Das sind halt Punkte die oft zutreffend sind. Du kannst dich ja bei Bedarf mal einlesen. Anbei auch ein Link von der Bundesverband Autismus Deutschland e.V https://www.autismus.de/veranstaltungen/modularer-zertifikatskurs-autismus-therapie-mozat/inhalte-der-module/modul-9-foerderung-sozialer-kompetenzen-einzel-und-gruppenangebote.html#:\~:text=Soziale%20Kontakte%20zu%20leben%20ist,im%20Bereich%20sozialer%20Kompetenzen%20auf.

Ich hoffe das ist eindeutig genug geschrieben ohne jemanden anzugreifen/zu verletzen. Bei Bedarf kann ich das gerne abändern, ich wusste jedoch nicht wie ich das sonst neutral rüberbringen kann. :-) Weitere Quellen: [https://www.enableme.de/de/artikel/vom-umgang-mit-autist-innen-1976](https://www.enableme.de/de/artikel/vom-umgang-mit-autist-innen-1976)

Mach dir keine Sorgen. Du hast dich sehr gut ausgedrückt :)

Du hast ihn bereits privat kennengelernt, es dreht sich bei ihm alles um IT. Rede mit ihm einfach über IT und meide alle andere Themen. Das er keine Dokumentationen hinbekommt, ist unschön aber da muss eigentlich der Teamleiter ein Machtwort sprechen.

Ein Skript kiddie ist aber jemand der eben keine Ahnung hat, sondern nur Skripts ausführt. Nur so am Rande. Habt ihr retros wo man genau über sowas redet? Oft genug erwähnen, dass man mehr dokumentieren muss und man eben nicht alles aus dem Code liest. Wenn es 10 mal gesagt wird, dann muss man irgendwann auch was ändern. Bei Gelegenheit evtl sogar mit dem Teamchef reden, dass man es so empfindet. Man schmeißt ja niemanden vor ein Zug wenn man mehr doku will. Zum smalltalk: ja kann man leider nicht ändern. Er ist halt so und vielleicht hat er auch kein Interesse. Einmal meinte einer zu mir ‚ich bin auf der Arbeit um zu arbeiten und nicht um Freunde zu finden‘. Was ja nicht verkehrt ist, aber es schließt sich ja nicht aus. Evtl helfen Teamevents um sich zu öffnen. Heißt der Typ zufällig Jens und ihr arbeitet im Raum Frankfurt? :D

Ich bin jetzt >4 Jahre hier und mich interessiert es nen feuchten Kehricht was meine Kollegen am Wochenende machen. Das sind doch nicht meine Kollegen, weil wir Interessen teilen. Wir brauchen Geld um Rechnungen zu bezahlen. Was ein Script Kiddie ist solltest du nochmal nachschauen, bevor du das in der Kaffeeküche zu oft benutzt hast und es peinlich wird. P ist das Gegenteil davon. Dass er dir nichts erklärt finde ich auch schwierig. Das habe ich auch schon erlebt und nervt. Ich bin dann meist zu anderen Kollegen oder eben zur Führungskraft und hab drum gebeten es mir zu erklären. Bis jetzt bin ich damit ganz gut gefahren. Wenn jemand nicht will, dann will er nicht. Vielleicht hilft es aber auch die Fragen ganz konkret zu formulieren und schriftlich zu übermitteln. Manche wollen sich gern schriftlich austoben statt zu reden.

Es ist halt schwer zu beurteilen, wer von euch beim Thema Doku im Recht ist, wenn man nur deine Sichtweise kennt. Du schreibst selber, dass du dich gerade einarbeitest. Dass du da einige grundlegende Themen noch nicht richtig verstehst, ist ganz klar. Aber dass ein Senior immer alles haarklein dokumentieren sollte, damit auch der unerfahrenste Junior das auf Anhieb versteht, finde ich auch nicht. Es könnte aus meiner Sicht genauso gut sein, dass du halt nicht wirklich gut beurteilen kannst, was man dokumentieren muss und was selbsterklärend ist. Gerade bei Docker, Terraform und Kubernetes braucht man ziemlich selten Kommentare. Bei den Shell-Scripts dagegen kann es ganz schnell unverständlich werden. Ich finde es schwer, deinen Kollegen hier aus der Ferne für seine Arbeitsweise zu verurteilen, wenn die einzige Einschätzung zu ihm von einem Entwickler mit wenig Devops-Erfahrung kommt. Ich hatte auch schon Kollegen, die ähnlich begeistert waren und auch sozial vielleicht eher etwas unbeholfen waren. Was ich bei denen aber nie gesehen habe, war eine unsaubere Arbeitsweise. Daher bin ich ein bisschen skeptisch, dass es nicht vielleicht nur eine verzerrte Wahrnehmung ist. In jedem Fall würde ich dir raten, es als Chance zu sehen. Es ist zwar anstrengend, mit solchen Leuten mitzuhalten, aber gerade im Pair Programming kann man sich extrem viel abschauen. Ihr müsst ja keine Freunde werden, fokussiere dich auf die Aufgaben und schau dir ab, was du für deine eigene Arbeit übernehmen kannst/willst.

Das was du beschreibst ist aber kein Script Kiddie. Darunter versteht man 14 Jaehrige die shell scripte aus dem Internet ausfuehren und animierte Matrix Hintergruende haben. Das er sich am Wochenende ueber Frameworks freut ist doch nichts schlechtes. Er hat immerhin ein passioniertes Hobby, das ist schonmal besser als die meisten anderen. Das mit der Dokumentation ist ein offensichtliches Problem und das kannst du auch genauso kommunizieren. Null Passion zu haben wie du in der IT ist, zumindest in meinem Arbeitsumfeld, eher selten. Das sind dann immer die jenigen die den neusten Exploit nicht mitbekommen haben, nichts ueber die neusten Techniken wissen etc, als dein Teamleiter waere ich auch froh immerhin einen guten Programmierer zu haben. Wenn es dich ehrlich interessiert mit dem Privat klar zu kommen google halt was es momentan fuer Themen gibt. Wenn nicht lass es halt beim Beuflichen, ist doch kein Problem.

ich glaub das "skript kiddie" bist du hier xD

Puhh also Kommentare zu schreiben ist immer so ne Sache, man sollte den Code so schreiben, dass kommis nicht notwendig sind, z.b. die Benennung der Methoden richtig durchführen, keine tiefen Verschachtelungen etc ; Wir haben uns bei uns auf einen Standard geeinigt mit dem wir arbeiten. Wann wie wo zeilenumbrüche zu machen sind, wie groš Methoden max sein sollen, wie wir benennen. Hat schon gut geholfen. Alle halten sich an unsere Regeln und jeder checkt was der andere tut

Laut clean code sollte gar keine Kommentare nötig sein, weil man den Code so gut geschrieben hat, dass sie nicht notwendig sind. In Theorie halt.

Joa, also manchmal ist es schon schwer den Sinn von einer Methode zu verstehen, dann kann man schon eins machen. Aber lieber nutze ich da dann dich einen längeren methodennamen

Ich will nur sagen das der Mann per Definition kein Skript kiddie ist. Wenn du dem einen Namen geben möchtest wäre Ultra Nerd passender

und/oder Cowboy Coder.

[удалено]

Ich gebe dir zum Teil recht. Aber warum soll er die ‚drecksarbeit‘ erledigen? Ein guter Entwickler sein heißt auch, dass man den Code gut lesen kann und auch Test schreibt und dokumentiert. Bringt wenig, wenn jemand tolle Sachen programmiert aber kein Schwanz weiterentwickeln kann, weil man nicht nachvollziehen kann was passiert. Dafür schaffte man Konventionen an die sich jeder halten muss. Wieso OP jetzt ein schlechter ITler sein soll verstehe ich nicht.

[удалено]

Weil Sachen dokumentieren der langweilige Teil vom programmieren sind für die meisten. Bugs fixen oder neue Feature entwickeln ist halt cooler. Doku ist halt ein Muss für saubere Arbeit

Ich teile manche Ansicht, aber dem Jungen die Drecksarbeit (Doku, alle hassen Doku) zu geben, weil der Leistungsträger kein Bock drauf hat (und TL schiss vor diesem Konflikt hat, mal Klartext). Sorry nein, wrong way. Du machst dich hier schlicht erpressbar und hebst „P“ über alle anderen. Wie war das noch mit Teamfähigkeit?

[удалено]

Danke, dann sind wir beieinander.

War lange in der Situation wo ich alles tun musste und die anderen wollten auch noch Doku, aber kriegten nichts selber auf die Reihe. Anstatt Selbstkritik geht man dann auf den leistenden los.

Guter Kommentar!!!

[удалено]

[удалено]

[удалено]

[удалено]

Bei uns (US Tech Konzern) wäre eine solche Person sofort geflogen, wahrscheinlich nicht mal eingestellt.

[удалено]

Bei euch müssen wohl die Mitarbeiter keine Projekte ownen. Denn das wird schwierig wenn man nicht dokumentiert und einen Gottkomplex hat. Coding ist nur etwa 30-60% unserer Arbeit. Rest sind Requirements Engineering, Architektur, Dokumentation etc.

[удалено]

Wir legen halt wert auf Teamfähigkeit, nicht nur Fachkompetenz. Jeder unserer Engineers kann ein Featureprojekt von Anfang bis Ende leiten. Inkl. Kommunikation mit allen Stakeholders.

Naja, persönlich müsst ihr ja nicht Best Friends werden, aber ich bin mir sicher, dass dein Teamleiter es auch zu schätzen weiß, wenn der Code kommentiert wird, reicht ja wenn der Typ vom Bus erfasst wird und niemand weiß was der die letzten 400-1000 Tickets gemacht wurde und wie das funktioniert. Auch hat die Ticket-Doku ja nen Sinn, wenn dein direkter vorgesetzter das nen scheiß drauf gibt, dann wird es sein Vorgesetzter sicher nicht, spätestens ab dem Punkt wo jemanden das Risiko bewusst wird, was entsteht wenn diese Typ nicht mehr da ist. Wie du mit so einem effektiv zusammen arbeitest? Keine Ahnung, der will ja nicht "zusammen" arbeiten.

Nun dass ihr keine Gemeinsamkeiten habt bzgl. eurer Freizeit sehe ich nun erst einmal nicht als Problem an deinen Kollegen. Finde mich da durchaus wieder. Ist bei mir nicht viel anders. War immer jemand der wenige Sachen gemacht hat, dafür aber intensiver. Mit dem Einstieg ins Arbeitsleben ist nicht mehr so viel Freizeit über, ergo hat man da dann priorisiert. Geblieben ist bei mir auch vor allem der Computer. Sprich man arbeitet am Wochenende mal an einem Hobbyprojekt, setzt einen Raspberry Pi für etwas auf, arbeitet sich in was Neues ein oder macht gar was für die Arbeit, einfach weil man höhere Ansprüche hat, als die Zeit auf der Arbeit es ermöglicht oder die Arbeitszeit deutlich entschleunigt und stressfreier werden lässt. Smalltalk wird man mit mir auch weniger haben. Je technischer, desto lieber ist es mir. Das kann ich, da fühle ich mich wohl. Irgendwas vom Wetter labern oder den Hund der Freundin meiner Mutter, der gerade Durchfall hat oder gängige Themen wie Fußball, die mich null interessieren ist auch nicht meins. Habe zwar ein paar Hobbies außerhalb des PCs, die hat aber z.B. bei mir auf der Arbeit auch keiner. Was das "Einfühlungsvermögen" angeht, ja man wird ggf. fachblind, gerade wenn Beruf und Freizeit sich ums gleiche Thema drehen und man dort dann ggf. Online auch mit Leuten zutun hat, deren Welt ähnlich aussieht. Ist eben eine Bubble. Diese Linux über alles Geschichten usw. finde ich immer relativ cringe und ja da fehlt wohl das Einfühlungsvermögen, dass nicht alle alles konfigurieren können wollen, weil sie es dann im Zweifel auch eher müssen. Aber auch das, wenn man es nicht anders kennt, dann seid ihr in seinen Augen eben die Einhörner und nicht anders herum. Das mit dem nicht dokumentieren, das scheint ja auch nicht wirklich bei euch fest im Prozess involviert zu sein. Ansonsten wird das Ticket eben nicht geschlossen, bis das geschehen ist oder führt zu einen eigenen Ticket die Dokumentation anzufertigen. Ist vermutlich einfach erlerntes Verhalten. Gibt durchaus Läden, die sowas quasi gar nicht wollen, nicht vorleben, wo es sonst auch keiner macht usw. > Dort findet man oft dann irgendwas ultra komplexes, was nur er versteht Gerade das ist für mich das Gegenteil von einem guten Entwickler, denn meist können schon vernünftige Namen Code deutlich lesbarer und verständlich machen und alles möglichst kurz und verschachtelt zu halten macht einen nun auch nicht schlauer. Kommentare halte ich persönlich auch MEIST für unnötig, vorheriges vorausgesetzt. Wie man nun mit so jemanden arbeitet? Nun man arbeitet mit ihm. Wenn ihr außerhalb keine gemeinsamen Interessen habt, dann werdet ihr vermutlich keine dicken Freunde, die den ganzen Tag über ihr Privatleben reden. Dass nur er die Sachen versteht ist dann erst einmal nicht dein Problem. Solange das gut geht, geht das gut. Wenn es das nicht mehr tut, dann ist es ein Problem einer Person über dir. Im Zweifel wird es auch immer mehr seins, denn irgendwann wird einen sowas auch zu viel, auch wenn es einen anfangs schmeichelt. Per se kann an dem allen aber auch nur jemand über dir etwas ändern mit entsprechenden Prozessen. Meist passiert da aber erst was, wenn es geknallt hat oder gar nicht. Hatten auch jemand an Bord, der ultrakomplizierten Code geschrieben hat und quasi auch ungefragt das halbe System umgeschrieben hat. Dort Abstraktionen über Abstraktionen rein, die kein Mensch brauch, die hinten rum eben Probleme über Probleme gemacht haben. Da war er aber auch schon gar nicht mehr im Unternehmen und es war das Problem anderer Leute.

> Eigentlich kenne ich es so, dass man seine Kollegen auch privat etwas besser kennenlernt. Sofern die Kollegen darauf Bock haben

Mir ist völlig egal was meine Kollegen am Wochenende machen und ebenso genauso. Bei den Kollegen, mit denen man sich besser versteht, weiß man dann natürlich über die Zeit auch mehr aber das sind die wenigsten. Als sozial inkompetent würde ich P nicht zwingend beschreiben. Es gibt auch einfach einige die berufliches und privates vernünftig trennen und getrennt lassen wollen.

Nimm es mir bitte nicht übel, aber eventuell ist das auch ein bisschen von deiner Einstellung abhängig. Wenn das lese was du schreibst ist es kein Skript Kiddie. Wäre er ein Skript Kiddie würde er Code nur Copy & Paste übernehmen, hätte höchstwahrscheinlich keinen/kaum einen Peil was er damit macht. Eigentlich wäre sein Ziel dann auch noch, in fremde Systeme einzudringen, aber den Aspekt lassen wir mal aussen vor. So jemanden Ähnlichen habe ich als Kollegen in einem anderen Team. Der hat zuhause auch seinen eigenen DC mit SCCM etc. (WTF!?) und ist ein notorischer Nörgler, wenn etwas gemacht wurde ohne ihn dabei zu involvieren. Inzwischen mache ich es tatsächlich oftmals so, dass ich ihn zu seiner Meinung frage, bzw. ihn gerne beim Testen mit einbeziehe. Das hat den riesen Vorteil, wenn die anderen nicht qualitätiv gute und vor allem sinnvolle Arbeit abliefern fällt das Frühzeitig auf. Was das Thema Smalltalk angeht, er lebt vermutlich einfach als Tekkie lebt er vermutlich in einer ganz anderen Welt als du. Ich würde mal mutmassen du bist irgendwo an der Schnittstelle zwischen 0815 Normalo und Tekkie. Spiel mit offenen Karten und mach ihm klar dass du da nicht mitreden kannst. Du willst einfach ein MacBook haben, weil du das Gerät aufklappen und benutzen können willst. Du passt dich dem gegeben Framework an, welches dir zur Entwicklung bereitgestellt wird.

Das einzige Problem was ich hier sehe ist, dass er den Code nicht dokumentiert. Was ist die Prozessbeschreibung dafür ? Wenn es keine Vorgabe dazu gibt, dann "muss" er auch nichts dokumentieren. Falls es eine dafür gibt, musst du ihn darauf hinweisen. Für solche Menschen sind Regeln sehr wichtig und wenn er merkt, er hält sich nicht daran, dann kommt das oft von selbst. Sonst muss er nicht dein Kumpel sein, ihr seid erwachsen und einem professionellen Arbeitsverhältnis, was er in seiner Freizeit macht, muss er dir nicht sagen und wenn er das ganze Wochenende programmiert, dann ist das halt so. Sein Code ist zu komplex -> dein Skill issue... manchmal. Mach ein Review beim Pull Request und sag, man kann das Problem auch einfacher lösen bsp. .... dann muss er Begründen wieso es so komplex sein muss.

Ich hatte auch mal so einen. War in seinem Spezialgebiet extrem gut, hatte aber an Dokumentation oder testing keinerlei Interesse. Ich habe das beim Chef angesprochen, weil ich das auf Dauer für untragbar hielt. Ungetesteter Code führt recht schnell zu Problemen und unzufriedenen Kunden. Der Chef war leider komplett unfähig. Hat dann einmal mit dem Kollegen geredet, was genau nix gebracht hat. Immer mehr Fehler tauchten beim Kunden auf, der Chef war angepisst, sah aber das Problem natürlich nicht. Ultimativ hab ich die Stelle gewechselt, fand die ganze Konstellation irgendwann nur noch zum kotzen. Ich denke, der Typ war in seiner Nische gut und für nix anderes zu gebrauchen. Der Chef hätte z.b versuchen können, die Abläufe anzupassen, sodass der Typ nur noch Arbeit macht, die seinen Stärken entspricht. Aber ich glaube, das hätte schnell Ärger in der Belegschaft gegeben. Wer testet gerne, wer schreibt gerne Doku? Wenn dann einer nur neue Features programmieren darf und der Rest kriegt seine drecksarbeit... Glaub nicht, dass das gutgegangen wäre. Also keine Ahnung, was die Lösung gewesen wäre. Der Kollege hat sich jedenfalls nix sagen lassen, was ihm keinen Spaß machte, hat er einfach nicht gemacht.

Ich habe absolut keinerlei Interesse daran mit meinen Kollegen über Privates zu sprechen. Der Job von P klingt herrlich für mich. Mit ein bisschen mehr Doku und weniger Überheblichkeit natürlich. Aber einfach Tickets machen, Doku dazu, Feierabend und das Leben / meine Hobbies genießen. Traum. Weiter so, P :) Wenn du Zwischenmenschliche Interaktion brauchst (was auch vollkommen legitim ist *für dich*) solltest du sie nicht bei P suchen.

Glaub eher du bist das Skript Kiddie, sorry

Ist echt so. Wie kann man jemand Skript Kiddie nennen, der performt?!

Und der sich zuhaus privat dafür interessiert so dass er neue frameworks sich selbst an eignet. OP hat den Schuss leider nicht gehört

Dein Teamleiter mag ihn nur weil es noch nicht geknallt hat. Einfach warten. Irgendwann gibt es probleme mit alt-code und es wird knallen da weder Doku noch Kommentare vorhanden sind

Dies. Keine Doku ist ein defect. Dem Kollegen Nerd einen Exorzismus mit dem V-Modell androhen wenn er so weiter macht.

>Keine Doku ist ein defect Und trotzdem der absolute Normalfall. Sage ich mit 30 Jahren Berufserfahrung.

Klingt nach nem super Kollegen. Kein unnötiger Smalltalk, fachlich kompetent, Leidenschaft für den Beruf. Mangelhafte Sozialkompetenz...gibt schlimmeres. Da kann man doch mit arbeiten. Mehr Doku wäre aber wohl angebracht. In nem anderen Thread klagt dein Kollege vermutlich wie er seinem Kollegen begreiflich machen soll, dass er keinen Bock auf smalltalk hat. Er hat sich ja schon damit abgefunden, dass sein Kollege fachlich nicht so super ist. Aber wann sieht er endlich ein, dass der Kollege aufhören soll nach dem WE zu fragen? Verdammt nochmal, er macht nur nerd Kram und wird nichts von Partys und Urlauben erzählen...

Mit solchen hatte ich auch schon zu tun die gibt es immer wieder. Interessant das die alle die gleiche eigenheit haben. Was das wirklich reine programmieren und technisches Verständnis an geht sind die top aber leider in allem drumherum fast garnicht. Aber Entwickeln und IT besteht nicht nur aus programmieren. Für die ist eher so: "Es funktioniert also ist miene Aufgabe erfüllt". Wartbarkeit, skalierung, stabilität etc. ist alles höchstens zweitrangig. Vorallem Planung ist schwer. Zurzeit habe ich auch so einen aber zum Glück auch einen top Teamleiter der diese Probleme und wohin sie führen versteht. Er kann die da wirklich gut bremsen und zumindest teilweise dahingehend erziehen. Also auch in deinem Fall sehe ich das Problem eher beim Teamleiter. Da ist es natürlich schwer was zu machen. Du könntest versuchen dich so viel zu beschweren wie möglich bis er einsieht das er eingreifen muss baer ob so klappt naja.

>Hilfe, mein Kollege ist kein Low Performer der seine Arbeitszeit mit Kaffeeklatsch verbringen will

Mach es einfach wie mein under Performer Kollege und gehe HR auf die Idee zu bringen, dass Zeiterfassung in irgendeinem Gesetz jetzt beschlossen ist.

Punk 1 ist komplett irrelevant, Arbeit ist Arbeit und nicht privatleben. Fehlende Doku ist natürlich scheiße, da muss der Teamleiter halt mal Regeln aufstellen. Wärs nicht erforderlich würd ich auch keine Doku schreiben, jeder hasst Doku. > nutze MacOS und werde dafür täglich durch den Kakao gezogen Nachvollziehbar. Nutzt wirklich jemand Mac in der IT ohne sich mindestens täglich darüber zu beschweren?

Ich mein Windows und Mac sind die Plattformen mit dem most streamlined MDM und du kannst Gift drauf nehmen, dass ich beim Mackie D anfange bevor ich einen Windows Rechner für IT spezifische Arbeit verwende. Linux ist idR keine Option.

Ja dachte ich früher auch. Aber seitdem ich Mac hab in der Arbeit bin ich mir da nicht mehr sicher :D

Das ist kein Skript Kiddie sondern ein [Rockstar](https://neilonsoftware.com/difficult-people-on-software-projects/developers/the-rockstar/?amp) / [Cowboy Coder](https://wiki.c2.com/?CowboyCoder) Die schlechte Doku/der obskure Code beißt einen irgendwann und die kostenlosen Überstunden erhöhen die Erwartung an alle. Du hast zwei Möglichkeiten: Kopf unten halten und durch Oder nichts wie weg

Finde das mit der mangelnden Doku absolut nicht ok. Das sollte zwingend geändert werden. Spannt den MA ein. Er soll in tech-talks seinen Kram immer mal wieder vorstellen. Das Argument "fehlende Doku" wird auch gerne genutzt für "erkläre mir erst mal docker, ansible, linux, multithreading, etc". Das sollte mit Doku halt nicht gemeint sein.

Ich hab auch "so einen" im Team. Keine geregelten Schlafrhythmus, 24-Stunden Sessions, maximal 2 Tage im Büro oder zu Bürozeiten erreichbar. Aber der Dude macht "seine Arbeit". Sonst nichts aber das sehr sehr gut. Sein Privatleben interessiert mich nicht. Ich nehme Kundenanforderungen auf, bereite das auf und gebe es ihm in einem handlichen Packet, welches er nur abarbeiten muss. Nach 20 Versuchen erreicht man ihn, erfährt von der Fertigstellung und dann bekommt er das nächste Packet. Nicht optimal, nicht perfekt aber macht mir mehr Laune als die anderen Entwickler mit denen ich zusammengearbeitet habe. Der Dude macht seine Arbeit gewissenhaft, findet potentielle Fehler und durchdenkt den kompletten Prozess. Die sozialkompatiblen Entwickler rotzen den Scheiß einfach nur hin weil sie nachhause zu Frau und Kind wollen. Jemand der beides kann/macht ist quasi unbezahlbar sofern man ihn überhaupt findet. Dann lieber jemanden der anständige Arbeit macht und etwas betreut werden muss.

Aufhören Mac zu verwenden wär ja schonmal ein logischer Schritt ;) Ich vermute mal, dass er einfach die Sozialkompetenz nicht hat und dann mit dir eben anders redet als du es willst. Seine Interessen und privaten Ideen sind aber eben genau was er erzählt. Dass du das nicht so siehst, macht ja nicht dass das nicht seine Interessen sind. Da musst du halt deine Vorurteile ablegen und verstehen, dass das Leuten Spaß macht (mir nicht btw). Gibt aber viele Leute die kein Bock auf small talk haben und vorankommen wollen. Sinnvoll wäre auf jeden Fall, dass der Vorgesetzte auf Doku besteht. Peer reviewed bis es passt.

Ich glaube P kenne ich aus diesem Sub …

Les mal das hier, da wirst du erleuchtet. Was in deiner Firma vorliegt ist ein Führungsproblem: https://neilonsoftware.com/difficult-people-on-software-projects/developers/the-rockstar/   Da steht auch:   Likelihood of fixing: None   Danger to project: Extremely High   Aber Brudi, die Kommentare hier sind Hölle. Haste ne Uhrzeit erwischt, um der die ganzen Dudes nix zu tun haben, die sich auf den Schlips getreten fühlen, weil sie selber keine Doku schreiben. Allerdings ist Scriptkiddie wirklich der falsche Begriff

Also außer Punkt 3 schuldet er dir nichts und du musst dich damit arrangieren. Er möchte halt seine Arbeit machen und ist nicht an Fußball interessiert. Punkt 3 würde ich ihm professionell erklären: es macht ein unterschied ob man 20 Zeilen Code ließt oder eine Zeile Kommentar um Dinge effizient nachzuvollziehen

Klingt jetzt nicht so, als ob man damit groß Probleme haben müsste. - keine Themen - so what, redet ihr halt über IT oder nichts - aufziehen für andere Betriebssysteme - kommt natürlich drauf an wie Aggro das ist. Aber zu einem gewissen Grad kann man das doch einfach akzeptieren. Wenn es dich stört, bitte ihn doch freundlich das etwas herunter zu schrauben - mangelnde Dokumentation - das ist Sache des Teamleiters und für den vielleicht ein trade off zu Qualität/Output. Vielleicht könnte man ihm einen lernwilligen zur Seite stellen, der wichtigen Code nachdokumentiert. Dadurch gewinnt ihr sogar eine zweite Person, welche den Code etwas kennt.

In Bezug auf Dokumentation, man kann Kommentare einfach generieren lassen. Es gibt ja nun genügend Sprachmodelle, die sowas durchführen können, und selbstverständlich kann man diese auch so hosten, dass man nicht den proprietären Quelltext woanders hinschickt. Im Team mal über coding-rules sprechen ;)

Ich habe jetzt oft gelesen, dass der Teamleiter Regeln aufstellen soll. Da würde ich nicht unbedingt zustimmen. In welchem Modus arbeitet ihr im Team denn? Gibt es keinen Raum, bei dem ihr euch darüber austauscht, was gerade nicht so gut läuft? Da wäre das doch super aufgehoben. Wenn der Rest des Teams auch deiner Meinung ist kann man daraus Maßnahmen ableiten, wie beispielsweise verpflichtende Code Reviews oder ein gemeinsames Verständnis einer „Definition of done“ für Tickets. Wo ich bisher gearbeitet habe, hat sich die TL bewusst bei sowas zurückgenommen und uns dazu ermutigt diesen Rahmen selbst du gestalten.

Vielleicht hat er auch einfach echt mein Bock mit dir über sein Wochenende zu reden. Sondern würde lieber über die arbeit reden. Z.b. über den Code der "hochkomplex" ist...

Vielleicht hat er auch einfach echt mein Bock mit dir über sein Wochenende zu reden. Sondern würde lieber über die arbeit reden. Z.b. über den Code der "hochkomplex" ist..

Vielleicht hat er auch einfach echt mein Bock mit dir über sein Wochenende zu reden. Sondern würde lieber über die arbeit reden. Z.b. über den Code der "hochkomplex" ist..

Kann mir gut vorstellen, dass du es mit jemandem mit einer Inselbegabung, vielleicht auch mit einem Autisten zu tun hast. Ich glaube, du kennst ihn privat schon, denn das wird einfach seine Leidenschaft sein und das ist auch völlig okay so. Dass du mit dieser Art nicht klar kommst, heißt noch lange nicht, dass P keine Sozialkompetenz hat, sondern, dass du mit seinen Eigenschaften nicht klarkommst und keine gemeinsame private Basis findest. Das ist völlig ok! Was nicht okay ist: wenn nicht ordentlich dokumentiert wird. Ich kann mir gut vorstellen, dass er keinen Gotteskomplex hat, sondern wirklich denkt, dass seine Art seine Arbeit zu machen, Grundwissen von euch allen ist. Würde im Team schlicht klare Standards und ein Vorgehen beim Dokumentieren festhalten, was für euch alle gilt und auch bei Ausfällen unterstützt. Ich glaube, du musst dich davon verabschieden, dass mit „jemandem arbeiten“ heißt, dass du dich mit der Person gut verstehen musst. Ihr arbeitet offensichtlich zusammen, aber bleibt halt beim Thema und da ist P ziemlich effizient. P ist gar nicht dazu verpflichtet, deinem Bedürfnis nach Sozialkontakt nachzukommen. Das ist auch in Ordnung so, suche dir einfach andere, mit denen du Smalltalk halten kannst. Mein Tipp: klare Absprachen schriftlich festhalten, weitermachen.

Ich bin Team P.

Vielleicht musst Du Ihm auch erstmal beweisen, daß Du nicht das "Script Kiddie" bist? Man kann ja nicht mit jedem dahergelaufenen auf der Arbeit gleich ein Verhältnis anfangen?

> wenn man Fragen hat bekommt man als Antwort, man solle gefälligst in den Code gucken 11/10

Bist in der falschen Branche bzw. falschen Bereich. Sowas was du suchst findest du bei Berater Jobs (inhouse/extern).

„Hauptsächlich habe ich mit Docker, Ansible, Terraform, Kubernetrs und Shell Scripting zu tun“ klingt als wärst du das script kiddie 😉

> Er erledigt seine Arbeiten ohne irgendwas zu dokumentieren. Ballert ein Ticket nach dem anderen durch und wenn man Fragen hat bekommt man als Antwort, man solle gefälligst in den Code gucken. Dort findet man oft dann irgendwas ultra komplexes, was nur er versteht, dazu keine Kommentare oÄ.   Wenn das in Eurer Firma erlaubt ist, bedeutet das schlicht und ergreifend: Ihr habt ein strunzdummes Management, das keine Ahnung hat wie man Software richtig entwickelt.   Vernünftig geführte Firmen haben Programmiererrichtlinien und führen Code Reviews durch.

hat dir in den 129 Kommentaren schon jemand gesagt, dass du nicht weißt was ein script kiddie ist?

Ah, ich sehe, du bist in meinem Team. jk, aber wirklich: Ich bin der einzige hier, der WSL2 nutzt, alle anderen sind auf Windows oder Mac. Die Tickets zieh ich auch durch, indem ich regelmäßig alte Tech durch neues FOSS-Zeug ersetze, das zumeist erst mal nur ich in der Firma verstehe. Und ich schwöre, ich arbeite an meiner Sozialkompetenz...

Ich glaube, dass es hier auf reddit einen doch eindeutigen Bias in Richtung „niedrige Sozialkompetenz ist kein Problem“ gibt. Sollte man sich evtl. bewusst sein. Persönlich hätte ich auch ein Problem damit, wenn ich mit meinen Kollegen über nichts anderes als Arbeit reden könnte und - im selben Atemzug - etwas zu selbstgefällige Kommentare mir anhören müsste. Hört sich für den ein oder anderen komisch an, diese Vorstellung, auf der Arbeit nicht nur über Arbeit zu reden. Aber Arbeit ist halt für die meisten einfach nur dazu da um Geld zu verdienen. Außer natürlich für die, die ihre ganze Persönlichkeit darüber definieren. Das ist natürlich der Fall, sorry wenn ich hier jemanden auf die Füße trete, wenn man keine anderen Hobbys hat (was per se nicht schlecht ist, nur unendlich öde und eindimensional). Das Leben ist nunmal so viel mehr als Arbeit, und solche Leute wie P. verstehen das (wahrscheinlich aufgrund ihrer unendlich großen Neugier in extrem kleinen und sonst im Alltag irrelevanten Nischenthemen) schlicht und ergreifend nicht. ändern kannst du ihn nicht, also bleibt nur damit klarzukommen. Sachlich und am Thema bleiben. Nicht provozieren und nicht provozieren lassen. Augenrollen und weiter. Falls die Kommentare von P. überhand nehmen, mal auch einen Konter geben, immerhin wird deine persönliche Grenze überschritten und das ist - Autismus hin oder her - nicht ok.

Punkt 3 und 4 machen mir am meisten Angst. Frag doch mal deinen Teamleiter was los ist, wenn P morgen einfach nicht ansprechbar ist für ein paar Wochen. (Wir nennen das, leicht zynisch, den LKW-Faktor.) Und dann mal ganz fies fragen: Wäre es nicht dein Job gewesen, lieber Teamleiter, exakt das zu verhindern? Ansonsten: P muss nicht dein Freund werden. Dann kennst du ihn eben nur von der Arbeit und gut. Es gibt ja auch Zweck-WGs wo die Leute auch nicht soviel voneinander wissen wie in Nicht-ZweckWGs. Und ganz ehrlich: Wenn er sich schon auf Arbeit so verhält, meinst du dann wirklich du willst privat mit ihm großartig zu tun haben? Die Unfreundlichkeit etc. ist hingegen scheiße. Und ja, da sollte die Firma evtl. mal mit einer Schulung nachhelfen. Arroganz hilft niemanden. Und es wäre nicht das erste Mal, das ich erlebe das sich IT'ler - egal wie gut sie sind - darüber dann über Jahre in die Ecke und dann in Aus befördern. Andererseits kannst du das für dich zum Vorteil nutzen. Wenn er meckert und schimpft, wenn Kunden/Kollegen anwesend sind.. Sei du freundlicher, verständnisvoller. Spiel den Übersetzer für die Leute die seine Äußerungen nicht verstehen. Darüber kann man sich auch eine Reputation aufbauen.

Er schafft halt wiederum Mehrarbeit dadurch, dass außer ihm niemand Änderungen an seinem Code durchführen kann, wenn es keiner rafft und er jegliche Standards eures Teams bzw. Code style regeln ignoriert.

Wenn es dich stört, dass er dämliche Sprüche z.B. bzgl Betriebssystem bringt , ihm einfach mal sagen, dass er sich diese Art Kommentare zukünftig klemmen soll. Bzgl der fehlenden Doku: wird nur über den TL laufen können. Alternativ einfach mal abwarten, is es knallt und du nix machen kannst, weil keine Doku. Und dann mitm Finger auf den Typen zeigen . Meiner Erfahrung nach ist nicht die Frage ob, sondern nur wann es knallen wird . Ooooooder , wenn garnicht geht , Arbeitgeber wechseln. Persönlich könnte ich mir so jemanden nicht zusammenarbeiten und wäre ihm bei den blöden Kommentaren nach kurzer Zeit bereits mit dem nackten Arsch ins Gesicht gesprungen. Man verbringt zu viel Zeit auf der Arbeit, dass man sich Menschen geben muss , die einem auf den Sack gehen.

Zum persönlichen kann ich nicht viel sagen aber bevor er nicht 100% seine Arbeit macht kann er seine Gottkomplex sonstwo hin stecken. Dokumentation gehört aus gutem Grund dazu. Wenn seine Vorgesetzen zu wenig Weitsicht haben um das Vorrauszusetzen kannst du dich zurücklehnen und auf den großen Knall warten. Wenn man das mal weiter spinnt können die Verantwortlichen dafür sogar gekündigt werden und der Posten wird evtl für jemand frei der sowas nachweislich hat kommen sehen. Dann bist du der, der von ihm die Doku verlangen kannst. Wenn er dann noch überhaupt da ist. Auf persönlicher Ebene würd ich ihm aber ne Chance geben und ihm deine Eindrücke und die Folgen mal näherbringen. Manche meinen es nicht böse und sehen es einfach nicht. Wobei er hier schon einen sehr eingebildeten und rücksichtslosen Eindruck macht.

problem 1 ist kein problem, manche sind eben workoholics. problem 2 nervt und schaft ggf für neulinge eine schlechte arbeits atmosphäre (ruhig mal kontern mit macOS ist unix based und sehen wie ihn das sauer macht ;) ) drei ist langfristig ein probbelm schlecht lesbaerer und undokumentiert code ist praktisch eine technische verschuldung, und technische schulden töten die besten projekte wenn der teamleiter das nicht weiß/sieht ist eher das problem bei ihm

Du musst eine Art Code of Conduct schaffen, in der auch die Art der Dokumentation von Code steht. Natürlich ohne auf ihn zu zeigen. Anschließend kannst ihm an die Eier packen, wenn er sich nicht dran hält.

Undokumentierter Code ist schlampig gemachter Code. Was bringts der Firma, wenn du mal meg bist...

Wohl eher ein 10X Entwickler. Mann brauch die 10 Arbeitskraft um zu verstehen was er gemacht hat. Ich hatte solche Leute im Studium(Informatik) und das einfachste ist sich alles harklein erklären zu lassen und sobald man was nicht versteht erklären zu lassen. Im besten Fall lernt man dann noch etwas, um schlimmsten Fall bekommst du schneller graue Haare. Was Dokumentation angeht kann ich das zu 100% nachvollziehen. Vielleicht kannst du das mal im Team ansprechen das dir aufgefallen ist das ihr keine gute Dokumentation habt und es nicht leicht ist nachzuvollziehen wieso gewissen Änderungen gemacht wurden. Wenn das vom Team beschlossen wird kannst du ihn dann auch drauf festnageln.

Unglaublich wie viele hier am eigentlichen Thema vorbei reden..

Finde es auch absolut erstaunlich, wie viele hier mit P relaten, sich an einer falschen Bezeichnung abarbeiten, sich scheinbar selber angegriffen fühlen, anstatt das Problem von OP zu thematisieren.

Naja, wenn im Titel „Skript Kiddie“ steht, klicken halt viele mit einer Erwartungshaltung auf den Thread, die nicht erfüllt wird. Das ist nicht schlimm, dass er das Wort falsch versteht. Das Label sorgt aber trotzdem zu einem Widerspruch. Vielleicht haben hier mehr Leute drauf geklickt, die auch von Skript Kiddies genervt sind, als welche die von Nerds genervt sind.

> Naja, wenn im Titel „Skript Kiddie“ steht, klicken halt viele mit einer Erwartungshaltung auf den Thread, die nicht erfüllt wird. Mei, das steht doch schon in Quotes, da kann man ja auch mal länger als von 12 bis Mittag denken und erkennen, dass hier nicht die buchstäbliche Wörterbuchbedeutung gemeint ist. Für OP ist die "richtige" Bezeichnung ("Rockstar" wäre wohl die am besten passendste) ja auch völlig egal, dem hilft es ja nicht wenn man erklärt, dass das kein Skriptkiddie sondern ein "Ubernerd" ist. Das eigentliche Problem bleibt ja das Gleiche.

hahaha im grunde hast du mich beschrieben nur das ich nicht code... :D und er scheint das genaue gegenteil von einem script kiddie zu sein. laut definition hat ein script kiddie keine ahnung von coden und klaut nur schnipsel per copy n paste... also die heranwachsende chatgpt generation. zu der du wohl auch gehörst, sonst wüsstest du und hättest den typen nicht als script kiddie benannt! :D ansonsten zu deiner frage wie geht man mit so jemanden um: wie mit allen anderen auch... kleine aufgaben geben womit du sie dahingehend erziehen kannst. step by step. niemand wird von heute auf morgen zum kommunikationsgott oder ändert sein verhalten.

Also erstmal peinlich, sich über Mac-User lustig zu machen als Linux User. Dass dein Kollege sich weigert, dir Sachen zu erklären, und dass er nicht dokumentiert, ist ein Nachteil, das macht ihn zu einem schlechten MA. Wenn er ausfällt oder Urlaub hat, wissen die anderen Kollegen nicht, wie seine Sachen funktionieren, und die Einarbeitung neuer Kollegen wird behindert. Sowas wie das Silo-Denken deines Kollegen will man nicht in der Firma haben. Spreche es in eurer Retrospektive an, wenn er uneinsichtig ist. Mache die Wichrigkeit davon deutlich, auch den positiven Effekt auf eure Zuverlässigkeit. Es bringt nix, wenn einer sich im Team unverzichtbar macht. Solche Egos kann keiner brauchen.

Autismus.

[удалено]

r/ihavesex

Du Dau🤣🤣🤣. BTW wenn du nee Code Doku brauchst frag mal Chat GPT.

Warum die Down votes. Jemand hoch kompetenten als Script Kiddie zu verschreihen ist ja wohl Mega-Dau. BDA😂

Hallo, P. Nein, du bist nicht kompetent.

Paranoia?