Hallo Haben einen neuen Kollegen bekommen. Er ist ca ein halbes Jahr da und programmiert jetzt ein Tool in Java. Jetzt habe ich mir mal seinen Code angesehen, da ich ihn nun unterstützen soll. Leider muss ich feststellen, dass er von objektorientierter Programmierung keine Ahnung hat. Er leitet einfach wild alles voneinander ab hat keine Struktur in seinem Programm. Das Programm ist dadurch sehr schwer erweiterbar. Wie soll ich reagieren? Eigentlich müsste es neu aufgesetzt werden... Soll ich mit ihm oder mit dem Chef sprechen. Oder sollte ich nichts sagen?
Mein heißer Tipp: Intensives Pair Programming mit TDD, da lernt ihr dann beide was bei.
Wenn Du keine offenen Worte verwendest, machst Du alles schlimmer. Du bestätigst quasi die Arbeitsweise deines Kollegen mit einer stillschweigenden Zustimmung. Es sammelt sich dann immer mehr unbrauchbarer Sourcecode an, den Du in schlimmsten Fall alleine am Hals haben wirst und darin wie in einem Sumpf versinken wirst. Jetzt hast Du die Möglichkeit, den Sumpf schon beim Entstehen trocken zu legen. Wenn Du Zeit verstreichen lässt, wird für Dich immer ungemütlicher werden. Die Entscheidung liegt aber ausschließlich bei Dir und ich muss zugeben, es gibt nur schlechte Lösungen, aus der aussuchen kannst. Von daher solltest Du die für Dich am wenigsten Schlechte aussuchen.
Ein offenes Wort unter Kollegen verbunden mit ein paar Fragen und vielleicht bis am Ende ja Du sogar schlauer.
Tom schrieb: > Wie soll ich reagieren? Sag es ihm einfach dass andere die das Programm um Funktionalitäten erweitern wollen Probleme haben werden und er dann wohl auch Probleme bekommt. Ich habe aber auch mal mit Java ein Programm geschrieben welches ich absichtlich so gestaltet habe dass dort keine unzähligen Objekte erzeugt werden und auch der Zugriff auf die Daten schneller erfolgt ist. Es gab jetzt die Möglichkeit das Programm aufgrund der beschränkten Rechenleistung des Systems unlaufbar, aber schön objektorientiert zu gestalten oder es so hinzubiegen dass es läuft. Es kommt immer drauf an, vielleicht ist das ja auch mit dem Chef abgesprochen, wenn du jetzt rumnörgelst und das Ars*hloch spielst wird dein neuer Arbeitskollege sich immer daran erinnern und es wird die nächsten 20 Jahre auf das Betriebsklima schlagen. Ich würde mich immer nett ran tasten, damit das Problem gelöst wird, aber möglichst niemand sauer aufeinander ist.
Tom schrieb: > Er ist ca ein halbes Jahr da Ich ahne Schlimmes. > da ich ihn nun unterstützen soll. Wirklich unterstützen oder die Leistung beurteilen? Kann auch sein das dein Chef dich da etwas missbraucht, weil er das Ende der Probezeit kommen sieht und dann entscheiden muss, ob Hold or Fire. > Leider muss ich > feststellen, dass er von objektorientierter Programmierung keine Ahnung > hat. Er leitet einfach wild alles voneinander ab hat keine Struktur in > seinem Programm. Na, einem Newbie wird das nicht gerade leicht gemacht. Kennt vielleicht Java nicht so gut und mit den Kenntnissen einer anderen Programmiersprache oder nur rudimentären Programmier- kenntnisse wird der Code halt nicht so professionell. Welches Niveau tatsächlich im Haus üblich ist, hat ihm vermutlich auch noch keiner gezeigt. Mir ging es da mal vergleichbar. Man kann nur das verlangen, was man an Vorgaben macht und die scheinen bei euch noch nicht kommuniziert worden zu sein. Jetzt hast du den schwarzen Peter und musst dich entscheiden: Helfen oder Opfern. Die Frage ist nur was du jetzt machen willst? Wenn du nie Hilfe benötigst, dann kann es durchaus mal passieren das eine Fehlentscheidung sich mal für dich umkehrt. Manche nennen das ganz lapidar Schicksal. > Das Programm ist dadurch sehr schwer erweiterbar. Wie > soll ich reagieren? Eigentlich müsste es neu aufgesetzt > werden... Soll ich mit ihm oder mit dem Chef sprechen. > Oder sollte ich nichts sagen? Wieviel Zeit hast du denn dafür? Würde die Zeit reichen, die kommunikativen Defizite auszugleichen? Bedenke, dass dein Schützling sich argumentativ auch beim Chef wehren kann. Da kann das ganze im Worst-Case für dich zum Bummerang werden.
Ist der Kollege lernwillig und kritikfähig? Inkompetent sein ist OK, nur inkompetent bleiben ist ein Problem. Hat das bisher keiner gemerkt? "Hallo, frischer Informatik-Bachelor, hier ist dein PC. Programmier mal das X-Tool und geh keinem auf die Nerven, hier hat keiner Zeit für dich." Ich würde jubeln, wenn jemand mit mehr Erfahrung auf meinem Arbeitsgebiet meinen Code läse und halbwegs konstruktiv zerpflückte und mich in eine bessere Richtung leitete; das ist in meinem derzeitigen Umfeld leider nicht üblich. Andere wären beleidigt.
Tom schrieb: > Hallo > Haben einen neuen Kollegen bekommen. Er ist ca ein halbes Jahr da und > programmiert jetzt ein Tool in Java. Jetzt habe ich mir mal seinen Code > angesehen, da ich ihn nun unterstützen soll. Leider muss ich > feststellen, dass er von objektorientierter Programmierung keine Ahnung > hat. Er leitet einfach wild alles voneinander ab hat keine Struktur in > seinem Programm. Das Programm ist dadurch sehr schwer erweiterbar. Wie > soll ich reagieren? Eigentlich müsste es neu aufgesetzt werden... Soll > ich mit ihm oder mit dem Chef sprechen. Oder sollte ich nichts sagen? Zunächstmal ist das alles SEIN Problem. ER muss ein funktionierendes Programm erschaffen und ggf. später Erweiterungen oder Änderungen darin vornehmen. DEINE Vorstellung eines sauberen Programmierstils muss nicht unbedingt die einzige gültige Wahrheit sein, vielleicht kommt er ja mit seinem Stil besser klar und hält deinen Stil für unübersichtlich. Vielleicht ist sein Programm sogar schneller und kompakter als es deine Lösung wäre. Dann bist DU derjenige der lernen sollte.
Tom schrieb: > Soll > ich mit ihm oder mit dem Chef sprechen. Oder sollte ich nichts sagen? Das musst du selber beurteilen. Bist du fachlich weisungsbefugt oder nicht? Sogar wenn, ist er zum Beispiel ein Kuki, Miki oder Liki kannst du dir böse die Finger verbrennen. Usw. Besteht die Gefahr, dass du später selber seinen Müll wegräumen musst, könnte es sich lohnen den Chef unauffällig und nebenbei auf das Problem hinzuweisen. Grundsätzlich rennst du gegen die Organisationsprobleme deines Arbeitgebers bei der Softwareentwicklung an. Bei euch dürfen einsame Helden offensichtlich mehr oder weniger unbeaufsichtigt über einige Zeit ohne Qualitätskontrolle vor sich hin tippen. Nur ganz kurz was zu OOP. Das unterliegt Moden. Wenn der Informatiker sich langweilt zieht er sich eine neue Regeln aus dem Arsch und treibt sie als neue Sau durchs Dorf. Aktuell wir Vererbung verdammt. Daher wäre ich mit einer Aussage wie der macht alles falsch sehr sehr vorsichtig.
Frage(n), Was ist das für ein Kollege und wieviel Berufserfahrung hat er? Für welche Position bzw für was ist er ein eingestellt worden? Wieviel Einarbeitungszeit gab es? Habt Ihr nicht so eone Art "Mentoring-Programm" für Neulinge? Warum hat man Ihn 6 Monate rumwuseln lassen ohne etwas zu sagen, gab es keine Meetings oder sonstige Kommunikation? Wenn man einen Neuling so ins kalte Wasser wirft wie du das geschildert hast, sollte man sich nicht wundern wenn soetwas passiert. Blue
Tom schrieb: > Soll > ich mit ihm oder mit dem Chef sprechen. Klar, solche Leute müssen noch in der Probezeit raus.
Dr. A. Fissur schrieb: > Klar, solche Leute müssen noch in der Probezeit raus. Der Zug ist abgefahren, da er ja ein halbes Jahr da ist, laut TO. ;) Ich frag mich hier sowieso: Warum wird ein neuer Mitarbeiter gleich mal direkt zum Einzelkämpfer befördert und warum schaut erst nach sechs Monaten jemand auf seine Arbeit? Das klingt für mich so als ob die Firma keine Struktur hat, nicht der MA.
Leute, gebt euch keine Mühe, die Story ist sehr wahrscheinlich wieder Erstunken und Erlogen. Ich glaube mich dunkel zu erinnern, dass der selbe Sachverhalt schon mal vor längerer Zeit gepostet wurde. Der TO meldet sich auf die Antworten gar nicht mehr und Heiner postet da so eine Nachricht, dass man davon ausgehen kann, das er uns hier wieder vorgeführt hat und der TO ist. :(
Wenn die einzige Anforderung lautet "Schreib ein Tool was XY tut" und er schreibt ein Tool was XY tut ist die Aufgabe gelöst. Wenn bestimmte messbare Kriterien eingehalten werden sollen habt ihr sie ihm sicher mitgeteilt und die Einhaltung kontrolliert, ... und nein "Erweiterbarkeit" ist kein messbares Kriterium Ansonsten habt ihr ihm doch sicher einen erfahrenen Softwarearchitekten zur Seite gestellt, der sich das prinzipielle Konzept ausgedacht hat, oder? Ach nein, natürlich nicht. Tja wenn ihr von professioneller Softwareentwicklung keine Ahnung habt und ihm keine vernünftigen Aufgaben stellt und es nicht überwacht wird, dann trifft den Kollegen keine Schuld.
D. I. schrieb: > dann trifft den Kollegen > keine Schuld. Nur, wer richtet darüber? Der alte Arbeitgeber, sofern es mal so kommt, wird gegenüber dem neuen Arbeitgeber(über Arbeitszeugnis und Direktkontakt) kaum zugeben, dass die Firma gepatzt hat. In manchen Firmen herrscht das reinste Neandertalertum. Größe und Stärke ist kein Kriterium, wie in Firmen intern gearbeitet wird. Hab es oft selbst erlebt.
Wäre ich der angekackte Kollege würde ich darlegen wie die Sache aussieht und dann weitersehen. Kommt ja auch drauf an was für ein Tool und so weiter, ... so write-once-never-touch-again sachen habe ich selbst schon genug entwickelt, aber die dienen/dienten einfach nur zur Steigerung des Arbeitskomforts und waren nicht produktrelevant. Bei Sachen wo es um etwas geht sind meistens mehr als eine Person involviert und da gibt es entsprechend Monitoring und Anforderungen und mind. ein Architekten der das große Ganze im Auge behält.
D. I. schrieb: > "Erweiterbarkeit" ist kein messbares Kriterium Oh doch, das ist es schon seit mindestens 30 Jahren. Bzw. seit mindestens 30 Jahren weiß man wie. Es machen nur sehr wenige, weil es nicht ganz einfach ist, Zeit und Geld kostet und eben nicht mit einem Klick auf ein Knöpfchen getan ist. D.h. man denken muss. Ganz grob ist das Vorgehen zum Messen von Erweiterbarkeit: * Erweiterbarkeit im jeweiligen Kontext definieren Beispiel: Erweiterbarkeit = Kosten der Modifikation eines Systems durch hinzufügen von Teilen so das es Vorgaben erfüllt. Je nach Kontext muss man dabei weiteren Gehirnschmalz reinstecken um Dinge wie Modifikation, Kosten, Vorgaben in greifbarer Form zu definieren. * Sich ein oder mehrere Skalen definieren Beispiel: Die Kosten in Mannmonaten um Programm A mit einer Erweiterung vom Typ X, der Größe Y mittels des Mechanismus Z zu versehen. Beispiele für Parameter: X: Menüpunkt im GUI Y: 1 Z: verwendetes GUI-Framework Wer kann wählt A, X, Y, Z prototypisch. Wer es nicht kann, und dass sind sogar meist die besseren Skalen, schneidet die PArameter auf das jeweilige System oder Teilsystem zu. * Randbedingungen definieren Beispiel: Programmierer der mit der Software (nicht) vertraut ist, das GUI-Framework (nicht) kennt, oder prototypischer Kunde, Student, usw. So, und jetzt wird es ernst, jetzt muss man sich überlegen wann und wie man wirklich die Messung ausführt. Dabei ist das Nichtmessen durchaus ein mögliches Ergebnis der Überlegung. Zum Beispiel, weil es gerade andere Prioritäten gibt, weil man schon einmal gemessen hat und sich an der Stelle in der Software nichts geändert hat, usw. Beim Messen kommt einem so neumodisches Zeug wie Scrum entgegen. Old-Scool wäre regelmäßig einen Programmierer auszugucken, der eine definierte prototypische Erweiterung vornimmt, am besten immer die gleiche (mit dem Problem des Lerneffekts). Hingegen, bei Scrum kann man zum Beispiel nach einem Sprint durch die abgearbeiteten Userstories gehen, alle an die man die Skala anlegen kann rausuchen und z.B. die jeweiligen Programmierer nach der benötigten Zeit fragen. Fertig, Erweiterbarkeit gemessen. Bleibt die Frage, taugt die Messung was? Fehlschüsse gibt es immer, du musst halt wissen, was du sehen möchtest. Wenn es dir im konkreten Fall nicht genau genug ist, dann darfst du mehr Geld in die Messung stecken. Aber denk daran, der Abstand zwischen Sonnensystemen wird auch nicht auf den Meter genau vermessen. So, jetzt bin ich mal gespannt, ob die erfahrenen Ingenieure diese Methode des Software-Engineerings erkennen oder ob es nur großes Geschrei von irgendwelchen Kindern gibt.
Unter "Kollege macht alles falsch" hätte ich mir jetzt aber schon mehr erwartet als dass er OPs Meinung nach nicht programmieren kann...
Kommt halt immer auf das Niveau an. Ich dachte auch, ich könnte halbwegs gut Embedded C. Neuen Job angetreten - oh Schreck, als direkten Vorgesetzten (und Merge-Verantwortlichen) einen relativ aktiven Kernel-Modul Verantwortlichen. Sternchen eines Pointers klebt nicht am Variablennamen? Reject. Scope eine Variable zu groß? Reject. Selten so eine steile Lernkurve gehabt. Aber die Peitsche tut mir gut.
Man muss aber dazu sagen, das die Kritkschleife bei max. einer Woche liegt.
Jay schrieb: > Ganz grob ist das Vorgehen zum Messen von Erweiterbarkeit: > > * Erweiterbarkeit im jeweiligen Kontext definieren Du gehst stillschweigend davon aus, dass schon bekannt sei was mal erweitert werden soll. Häufig genug ist das aber nicht unbedingt vorhersehbar. Jedenfalls, wer sich im Pflichtenheft eine Anforderung "Das Tool, System, etc. soll einfach erweiterbar sein." an die Backe nähen lässt, ... nun ja.
kaeseschnitzel schrieb: > Kommt halt immer auf das Niveau an. > > Ich dachte auch, ich könnte halbwegs gut Embedded C. Neuen Job > angetreten - oh Schreck, als direkten Vorgesetzten (und > Merge-Verantwortlichen) einen relativ aktiven Kernel-Modul > Verantwortlichen. Das muss nichts heißen. > > Sternchen eines Pointers klebt nicht am Variablennamen? Reject. Scope > eine Variable zu groß? Reject. Er pocht auf die Einhaltung von Coding Guidelines und achtet scheinbar auf grundlegende Prinzipien, das ist vernünftig und im Wesentlichen wahrscheinlich auch sein Job. So sollte es sein, wenn es aber keinen mit entsprechender Expertise im Team oder der Firma gibt, kommt halt Murks raus.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.