Hallo Experten! Bitte entschuldigt, dass ich diesen Text in dem relativ spezialisierten GCC-Forum poste, obwohl er auch in die Kategorien "Ausbildung und Beruf" oder "offtopic" passen würde. Ich glaube aber, dass hier fachlich versierte Leute mitlesen, deren Meinung ich besonders schätzen würde. Mir ist in den letzten Tagen etwas passiert, was mich extrem frustriert hat und mich darüber nachdenken lässt, ob ich mir eine Tätigkeit als Ingenieur in der Elektronik- oder Softwareentwicklung nicht besser ganz einsparen sollte und auf etwas stress-ärmeres wie Gärtner, Hausmeister oder 1-Euro-Jobber umsteigen sollte. Leider kann ich die Sache nicht als Einzelereignis einordnen und schnell vergessen, weil es bei früheren Arbeitgebern schon einmal ähnliche Vorfälle gab. Auch kann ich es nicht ganz kurz abhandeln. Es hat was von "Frust von der Seele schreiben", jedem der Zeit und Lust hat, es zu lesen, sei schon mal gedankt. Ich bin E-Technik-Ingenieur mit so ungefähr 5 Jahren Berufserfahrung und hatte bislang viel (wenn auch nicht nur) mit Mikrocontrollern zu tun. Früher 8051 und PIC, zwischendurch mal eine ganze Zeit Atmel AVR. Seit neuestem auch kleinere Projekte mit ARM-Kern-Prozessoren. Ich muss aber zugeben, dass ich letztere Architektur nur relativ oberflächlich kenne; hab mal an was einer kleineren Schaltung mit STM32 (mit)entwickelt und bei einer Firma ein Schnupper-Praktikum gemacht, die soetwas wie Linux-Unterstützung und -Toolchains für die größeren ARMs anbietet, die in Smartphones und Tablett-PCs verwendet werden. Leider hatte ich es nicht immer einfach, Arbeitgeber zu finden - hab zwar eine relativ passable Diplomnote, durch diverse Vorfälle aber auch einen etwas belasteten Lebenslauf (Gesundheitsprobleme - Stress mit den Nerven). Umso froher war ich bis vor kurzem, als mir ein Unternehmer/Inhaber eines Ingenieurbüros ein bezahltes 4 wöchiges Praktikum anbot, mit eventueller späterer Übernahmemöglichkeit. Die Firma stellt u. a. Industriesteuerungsgeräte her, eines der Produkte basiert auf einem SoC mit ARM-Kern. Dazu dann viel industriespezifische Peripherie mit auf der Platine (mehrere Feldbusse und RS323, Ethernet, CAN und so ähnlicher Kram). Um es vorwegzunehmen, dass Praktikum ging nur über ganze 7 Tage, dann wurde ich vom Inhaber mit lauten, wüsten Worten hinauskomplementiert (Dass er sich die Blöße gab, direkt so einen Tonfall zu wählen, möchte ich jetzt nicht zum Thema des Postings machen - aber schon verblüffend, dass es Leute mit so einer Kinderstube bis zum Unternehmensinhaber gebracht haben). Jetzt zum eher fachlichen Teil: Mir wurde für die ersten Tage des Praktikums die Aufgabe gestellt, an einer Testsoftware weiterzuentwickeln, mit der die Platinen des Industriesteuerungsgerätes auf Fehlerfreiheit getestet werden sollten. Also LEDs mal leuchten lassen, Taster einlesen, I2C mal testen, den AD-Wandler die Betriebsspannungen messen lassen, SDRAM und seriell angebundenes Flash-Eprom testen, Daten zwischen zwei verbunden seriellen Schnittstellen hin- und herschieben, Ethernet-Schnittstellen anpingen. Wie gesagt weiterzuentwickeln, die Software war schon von einem Kollegen begonnen worden, war aber noch nicht komplett. Die Testergebnisse wurden noch nicht in günstiger Form dargestellt, es war nicht klar was bei nicht-erfolgreichen Tests eigentlich passieren sollte. Dann sollten auch noch andere Software-Teile angefügt werden (Programmierung des Boot-Flashs über SD-Karte etc. etc.). Das sollte also die Aufgabe für die nächsten Tage sein. Anfangs kam ich ganz gut klar. Es gab eine kleine (Vor)Aufgabe zum Einstieg, mal das serielle Flash, das eine variable Größe haben konnte, mit einer Art autodetect-Algorithmus zu testen, anstatt mit per #define zur Compilezeit fest eingestellten erwarteten Größe. Ging ganz locker, hab schnell die Unterroutine gefunden, die vom main{} Programm aufgerufen wurde, etwas Code eingefügt und es ging. Auch einen loopback-Test zwischen zwei seriellen Schnittstellen, der angedacht, aber noch nicht implementiert war, habe ich zügig hinbekommen. Dann fing es an etwas schwieriger zu werden: Mir war klar, dass man für eine variablere Auswertung der Testergebnisse letztendlich so etwas wie eine nebenläufige Progammierung braucht ("Kein Tastendruck vom Einlese-Pin detektiert weil Lötstelle defekt" -> Timer läuft ab -> Fehlerflag gesetzt -> nächster Punkt im Testablauf). Ich fing also an, mich für die Benutzung der Hardware-Timer des ARM-Cores zu interessieren. Da fing es schon an etwas komisch zu werden. Ich war dabei, mir eine pdf-Datei mit dem Datenblatt des SoC herunterzuladen. "Warum sind Sie denn auf der Internetseite von [Hersteller des SoC], das brauchen Sie doch gar nicht!", sagte ein Kollege unfreundlich, der mir über die Schulter auf den Browserbildschirm schaute. Also versuchte ich mal im bestehenden Code zu schauen, wo Timer benutzt werden und da evtl. anzusetzen. Beim Lesen im Code kam mir aber immer mehr komisch vor - lauter deklarierte und definierte, aber nie ausgewertete Variablen, nie aufgerufener Code, Timer wurden zwar für irgendwas initialisiert, getimte Sachen wie LED-Blinken dann aber mit Runterzählschleife umgesetzt. Auch sehr viel mit #if 0 komplett totgelegter Code, sogar viele komplett unbenutzte Dateien im Projektverzeichnis. Ich wollte zumindest die unbenutzten Variablen mal sehen und ggf. löschen können und schaute mir die Compiler-Warneinstellungen genauer an (ach so, der benutzte Compiler war GCC für ARM-Target unter einer Windows-Entwicklungsumgebung). Sie lauteten -w, disable all warnings. Na super. Ich habe das dann geändert auf -Wall -Wextra, quasi alles relevante anzeigen. Der Kompiliervorgang sah nun etwas anders aus, hunderte, wenn nicht mehrere hunderte 'warning'-Ausgaben rasselten durch. Darunter nicht nur eher harmlose wie die nie benutzten Variablen, sondern auch Sachen wie Funktionen, als int foo(void) definiert waren, deren Implementation dann aber nicht mit return <value>; verlassen wurde, sondern einfach in die }-Klammer gelaufen wurde. Natürlich hochinteressant, wenn dann vom Rückgabewert der weitere Programmablauf abhängt! Ganz klar waren auch viele wirklich harmlose Meldungen dabei wie die nicht ganz korrekte Einbindung von include-Dateien oder implizite Funktionsdeklarationen. Die haben die ganze Ausgabe aber so zugekleistert, so dass ich eher auf eine schnelle Bereinigung hingearbeitet habe, um die kritischen Punkte besser sehen zu können. Ich würde auch nicht sagen, dass die Arbeit des Kollegen stümperhaft war, er hat sogar bestimmte Konventionen eingehalten wie die konsequente ungarische Notation von Variablennamen. Auch auf die Verwendung von 'goto's oder setjmp()'s hat er verzichtet. Sein Code funktionierte ja auch - es gab eine plausible Benutzerausgabe, die suggerierte, die Hardware würde jetzt getestet. Ob die Tests jedoch auch das getestet haben, was sie vorgaben zu testen, fand ich beim Lesen des Codes dann eher zweifelhaft. Es gab dann eine Projektbesprechung, bei der ich angemerkt habe, dass bei dem bestehenden Code noch nicht alles 100%ig in Ordnung sei und dass wahrscheinlich einige Anpassungsarbeiten notwendig werden würden. Die Kollegen sagten mir jedoch, dass der Code nach einer firmeninternen Codierungsrichtlinie erstellt worden wäre. Diese wäre verbindlich und dürfe nicht variiert werden, weil die Steuerungsgeräte später in Bereichen wie etwa der Bergbau- und Bahntechnik eingesetzt würden, in den die funktionale Sicherheit garantiert werden müsse. Was schon codiert wäre, müsse also als - wörtlich - "gottgegeben" hingenommen werden. Mir wurde eine Word-Datei ausgehändigt, die diese Codierungsrichtlinie enthielt - unter anderem die oben genannte ungarische Notation von Variablennamen. Eine weitere Forderung lautete, die Anweisungen "system" und "register" seien zu vermeiden, da die Umsetzung jeweils compilerabhängig sei. Seitdem geht mir die Frage im Kopf herum, in welchem C-Dialekt es nochmal das "system"-Schlüsselwort gab ... Zwei Tage später gab es eine weitere kurze Projektbesprechung unter Hinzuziehung des Firmeninhabers. Dort wurde sehr kritisch bemerkt, dass ich dem Zeitplan deutlich hinterhinge und auch unnötige Zeit mit dem Studium von Datenblättern verbracht hätte. Der ursprüngliche Autor des Codes sagte, ein Praktikant, der in eine Firma will, müsse sich doch darum bemühen schnelle Zwischenergebnisse zu präsentieren. Der Chef gestand ein, dass der Code des Testprogramm schon gewissermassen mit der "heissen Nadel" gestrickt worden wäre. Er hätte die Weiterarbeit an diesem Code aber gerade bewusst als Aufgabe für mich ausgewählt, weil er auch testen müsse, inwieweit ich teamfähig wäre und eine mir gestellte Aufgabe zuverlässig erledigen könne. Ich habe zu diesem Zeitpunkt dann meine "interne Aufgabenstellung" variiert und gedacht, ich könne die Sache dem Chef mal in Ruhe erklären, etwa indem ich ihm in einer vorher-nachher Situation am Rechner die Sache mit den abgeschalteten Warnungen vorführe und dann zum Vergleich meinen bereinigten Code, der keine Compilerwarnungen mehr produziert. Man hätte ja bestimmt mit irgendeinem Tool die Zahl der von mir geänderten Zeilen ermitteln können und wäre auf eine ganz ordentliche Zahl gekommen. Auch ein reiner Größenvergleich zwischen einem "aufgeräumten" Projektordner, in dem der mit #if 0 totgelegte Code und die unbenutzten Dateien komplett entfernt sind und der Ursprungssituation hätte einen ganz guten Eindruck hinterlassen. Grobe Schätzung von mir: 30-35% des Dateivolumens wären übriggeblieben. Irgendwo habe ich mal etwas davon gelesen, dass derjenige ein guter Programmierer ist, der sich um die Reduktion von Komplexität bemüht. Ich malte mir aus, vielleicht doch noch einen positiven Eindruck hinterlassen zu können. Ich wurde dann jedoch - früher als ich dachte - in das Büro des Chefs gebeten. Gerade als ich den Nachteil der abgeschalteten Compilerwarnungen vorbrachte, rief der Chef mir aufgeregt entgegen: "Darüber brauchen wir uns keine Sorgen machen. Wir setzen hier in der Firma seit Jahren das Tool "lint" ein, das ermöglicht uns problemlos Überprüfungen nach wichtigen industriellen Standards". Ich erwiderte, dass aber Compilerwarnungen meistens auf grundlegendere Sachen hinwiesen, manchmal sogar auf einen potentiellen Denkfehler. Im Hinterkopf hatte ich, dass 'lint' eher Sachen anmeckert, die laut C-Standard erlaubt sind - soetwas wie beispielsweise "fallthrough"-Konstruktionen bei switch-case-Anweisungen. "WAAAS, SIIEE wollen mir hier etwas sagen, wo ich doch seit 21 Jahren ein wirtschaftlich erfolgreiches Unternehmen führe!!!!!!". Schon mal Danke fürs bis hierhin lesen. Wie es dann weiterging, kann sich sicher jeder vorstellen. Kündigung, "Wir können keine Quertreiber im Team gebrauchen", Lohnsteuerkarte bekomme ich dann per Post. Das Problem ist nur, ich weiss wirklich nicht was ich für Schlüsse aus solchen Vorfällen ziehen soll. Natürlich geht mir die Kritik, völlig unproduktiv zu sein, nicht spurlos an mir vorbei. Auch weiss ich nicht, wieviele "Ergebnisse/Funktionalitäten" man als Entwickler in einem Zeitrahmen vorweisen muss. Gibt es da Richtlinien nach dem Motto: ET/Informatik-Absolvent muss dies und das in vorgegebener Zeit schaffen. Absolvent mit Berufserfahrung dann so-undso viel mehr? Hab ich noch massiven Nachholbedarf? Kann mir jemand gute Skripte/Bücher empfehlen? Wo kann ich demnächst einen Arbeitgeber finden, der gut zu mir passt? Automotive-Industrie? Soll ja stressig dort zugehen. Kleine Firmen? Sicher typisch für Fälle wie oben. Große Firmen? Sind sicher bürokratisch, das kann ja auch nervig sein. Vielleicht doch besser umsatteln auf Gärtner oder Dachdecker. Fragen über Fragen. Wer gute Antworten weiss, dem danke ich jetzt schon. DrNo
:
Verschoben durch Admin
Hallo, ich denke nicht, daß es ein Problem von dem Praktikant ist. Das hört sich nach einer unstrukturierten, sonderbaren "Bastelbude" an, wo man sich bisher immer so durchgewurschtelt hat. Zum Inhaber: Den stellt keiner ein, er gründet die Firma, und daher kann er einen Charakter vom allerfeinsten haben - oder halt nicht. Punktum. Ich glaube, das Problem liegt seitens der Firma! Nicht entmutigen lassen, die Ansätze im Text sind doch sehr professionell gedacht, weiter so!
Gut Ding will Weile haben! Brauchst dir nicht die Schuld zu geben, du hast doch versucht das Beste draus zu machen von dem, was dir vor die Füße geworfen wurde. Die meisten Leute, die dir wie dieser Chefe kommen, stellen sich Programmänderungen immer so einfach vor, aber wenn der besstehende Code schon nicht ordentlich ist, wird alles Hinzustückeln zu Pfusch. Nicht entmutigen lassen, du weißt, was du kannst. :-)
> Das Problem ist nur, ich weiss wirklich nicht was ich für > Schlüsse aus solchen Vorfällen ziehen soll. Nicht alle Firmen taugen was. > Mir wurde für die ersten Tage des Praktikums die Aufgabe gestellt, > an einer Testsoftware weiterzuentwickeln, Unternehmen suchen Leute mit Fertigkeiten (ob er die linke Schraube ins rechte Lager schrauben kann) und nicht mehr mit Ausbildung (E-Techniker, kennt auch den theoretischen Hintergrund, muss Werkzeuge ggf. erst benutzen lernen). > Wo kann ich demnächst einen Arbeitgeber finden, der gut zu mir passt? Woanders. Du musst halt mehrere ausprobieren. Obwohl ich dir in der fachlichen Schlussfolgerung "dass man nebenläufige Progammierung braucht" nicht unbedingt zustimme (es wird so oder anders gehen, ohne daß ich eine Wertung abgeben möchte was im Fall besser wäre), ist der Zustand des vorhandenen Programms sicher schlecht. Weniger für die Funktion, es hat ja wohl funktioniert, was bis dahin funktionieren sollte (die Funktion, die keinen int zurückgab, wird nicht unter Verwendung des Rückgabewerts aufgerufen worden sein) als eben für die Wartbarkeit. Es könnte aber sein, daß der Zustand nicht so kritisch war wie du ihn anführst, beispielsweise unbenutze Variable durchaus benutzt wurden, nur halt in einem Bereich der gerade mit #if 0 auskommentiert wurde. Aber ich nehme an, das war auch nicht das Problem, nicht für dich bei der Einarbeitung, und auch den Leuten dort hätte man es locker beibringen können und im Laufe der Zeit verbessern können. Aber es wird ein Problem bei der Kommunikation gegeben haben. Die Art, in der dir die Firma und du der Firma was mitgeteilt haben, wird nicht zusammengepasst haben. Aus welchem Grund sei dahingestellt, aber man sollte daran denken, daß Leute selten unmotiviert irgendwie merkwürdig sind, sondern oft nur auf etwas reagieren. > Hab ich noch massiven Nachholbedarf? Am ehesten wohl im Umgang mit Leuten. Wenn man als "Quertreiber" und nicht "Bereicherung um neue Ideen" wahrgenommen wird, hat was mit deiner eigenen Vermarktung nicht geklappt.
DrNo schrieb: > Hab ich noch massiven Nachholbedarf? Kann mir jemand gute Skripte/Bücher > empfehlen? Du hast massiven Nachholbedarf im Abstumpfen, wenn du in einer Branche ueberleben willst, die Pfusch zum Standard erhoben hat. Der Kommentar "Aber es laeuft ja." sagt doch schon alles. Ich kann dir leider wenig Hoffnung machen, die Firma, in der du gluecklich werden kannst, gehoert zu den Ausnahmen.
> Woanders. Du musst halt mehrere ausprobieren. Klar. Weiß aber nicht, in welche Richtung. Die Firmen, in denen ich bislang war, waren alle eher kleine Bastelbuden. Nur bei der Firma mit den Linux-Toolchains hatte ich den Eindruck, dass die Mitarbeiter vom Denken her ganz gut strukturiert waren. Ich hab halt Riesenangst vor den "Reibungsverlusten", Umzug in eine neue Region, was machen wenn es dann nicht klappt, nächste "Lücke im Lebenslauf"? Dort, wo ich jetzt wohne, gibt es eh nur kleine Firmen. > > Obwohl ich dir in der fachlichen Schlussfolgerung "dass man nebenläufige > Progammierung braucht" nicht unbedingt zustimme (es wird so oder anders Man hätte sicher nicht zwangsweise nebenläufige Programmierung gebraucht. Es hätte einem aber Flexibilität gegeben. Die Firma hatte noch andere Produkte mit demselben Hauptprozessor, aber etwas variierter Hardware, z. B. paralleles statt serielles Flash. Der Timer hätte dann dafür gesorgt, dass auch bei einem "steckengebliebenen" Test die Testroutine noch sinnvoll weiterläuft. Das Programm wäre dann möglicherweise ohne Anpassungen auch für eine andere Hardware geeignet gewesen. Dass es leicht variierte Hardwareprodukte gab, war auch der Grund, dass der Sourcecode mit wechselweise rausgenommenen #if 0 #endif übersät war. Also dachte ich, die Benutzung von Timern hätte mir "freie Bahn" verschaffen können, um in punkto Vereinfachung/Verbesserung der Übersichtlichkeit was tun zu können. Mein Problem ist wohl, dass ich manchmal erst an die "Kür" denke und dann an die "Pflicht". > Am ehesten wohl im Umgang mit Leuten. Wenn man als "Quertreiber" und > nicht "Bereicherung um neue Ideen" wahrgenommen wird, hat was mit deiner > eigenen Vermarktung nicht geklappt. Vermarktung und Bereicherung klingen so positiv. Als mir der Kollege sagte: "Warum gucken Sie in das Datenblatt vom Prozessor XYX, das brauchen Sie doch jetzt nicht!", hätte ich (innerlich) am liebsten gesagt: "Hören Sie mal Herr Kollege, nach dem Datenblatt des Chips, der gerade vor einem liegt, zu fragen, ist NIEMALS etwas ehrenrühriges, genauso wie man auch IMMER nach einem Glas Wasser oder einem Papiertaschentuch fragen darf." Wenn ich das so gesagt hätte, hätte ich wahrscheinlich am zweiten Tag gehen können anstatt am siebten. Ich kann also nur destruktiv sein. Ich glaube mittlerweile, dass es kaum einen Chef gibt, der sich den Sourcecode, den jemand gut modifiziert/vereinfacht/erweitert hat, tatsächlich anschaut und dafür Anerkennung zollt. Es zählt nur "was ist zu irgendeinem Termin fertiggeworden". Dieser Wunschtermin liegt seitens der Chefs natürlich in der Vergangenheit, also "gestern". Da in der E-Technik mittlerweile fast jede Aufgabe per Software oder Algorithmus gelöst wird und sich die Probleme, die ich habe, auf unangenehme Weise wiederholen, glaube ich, dass ich den Beruf wechseln muss.
Also ich denke das du nichts grundlegendes falsch gemacht hast. Leider gibt es genug kleinere bis mittlere Firmen wo die höheren Etagen von manchen Dingen überzeugt sind, die man als Entwickler nicht unbedingt nachvollziehen kann. Auch sind manche obere Etagen davon überzeugt zu wissen, wie man entwickelt, obwohl sie dies schon seit Jahren nicht mehr aktiv getan haben und/oder an veralteten Umsetzungen festhalten. Ich bin auch Entwickler und würde bei deinen Schilderungen genauso handeln. Ich habe eine entsprechende Sorgfaltspflicht und verpflichtet richtig und sicher zu entwickeln und alle Warnungen abschalten gehört verboten. Die Begründungen sind fadenscheinig und gehen an der Realität vorbei. Ich bin zwar kein Ingenieur wie du, aber du hast eine ingenieurstechnische Sorgfaltspflicht zu erfüllen. Und dazu gehört es u.a. das du verantwortlich bist für das was du entwickelst als gesamtes und du kannst es bestimmt nicht mit deinem Gewissen vereinbaren, wenn du weisst das die Software aus Fehler- und Problemstellen besteht. Ich weiß aber selbst aus Erfahrung, dass Änderungen in vorhanden Strukturen durch zu setzen. Vor allem als neuer bzw. Praktikant hat man da kaum eine Chance, gerade sowas wie "wurde schon seit Jahren so gemacht und läuft" ist eine Parade-Aussage. Viele ältere Arbeitnehmer ist man ein Konkurrent und du sägst an deren Stühlen, wenn du alles umstösst, was doch jahrelang funktionierte. Du kommst mit OOP oder vielleicht alle Warnungen als Errors zu interpretieren und das löst bei alten Hasen Panik aus, weil das alles neumodischer Kram ist den niemand braucht... Gerade wenn eine solche Software bei Bahn- oder Bergbaubetrieben eingesetzt wird, dann sind hier strenge Coderichtlinien Pflicht. Es ist fraglich wie eine solche Software vom AG abgenommen wird, wenn alle Warnungen ausgeschaltet sind. Wenn von Software Menschenleben abhängen, dann muss die Software besser sein als fehlerfrei und das nachweislich. Da wäre Interpretation von Hinweisen als Fehler das Mindeste. Und Programmierrichtlinien sind wichtig und sollten von daher auch gut definiert sein. Die NASA hat z.B. einen guten Styleguide. Ok, also grundlegend: ich bin zwar bei weitem nicht so (aus)gebildet wie du, kann dir aber definitiv sagen, dass ich es genauso gemacht hätte und nicht sogar noch drastischer interveniert hätte. Aber bei solchen unbelehrbaren Vorgesetzten kann man sich wirklich nur sagen: Schuld eigene. Gerade als Haftender Inhaber einer Firma bzw. als Verantwortlicher muss man auch Führungsqualitäten beweisen, z.B. Vorschläge anhören und sich eingestehen, dass man für bestimmte Bereiche Spezialisten in der Firma hat, die es auch mal besser wissen (und auch ihre Aussagen verantworten müssen). Wenn man aber stur nur seine eigene Meinung akzeptiert, dann zeugt das davon, dass man keine Mitarbeiter akzeptiert, welche nicht nur "Ja" und "Amen" sagen. Just my 2 Cents...
Abhaken und die nächste Firma suchen. Was du da erzählst ist natürlich schon extrem. Aber damit wir uns nicht misverstehen: Solche Code-Leichen hat jede Firma im Keller. Der Unterschied ist nur, dass normalerweise die Entwickler von diesen Leichen wissen und du schulterzuckend zur Kentniss nehmen musst, das da eben so ist. Gerade wenn eine Code-Basis historisch gewachsen ist, ist so etwas fast unvermeidlich. > Ich habe zu diesem Zeitpunkt dann meine "interne Aufgabenstellung" > variiert und gedacht, ich könne die Sache dem Chef mal in Ruhe > erklären, etwa indem ich ihm in einer vorher-nachher Situation am > Rechner die Sache mit den abgeschalteten Warnungen vorführe Das war ganz schlecht. Damit hast du eine Menge Leute vor den Kopf gestossen, deren Wort wesentlich mehr zählt als das des Praktikanten. Den Chef interessiert das nicht. Der will nur etwas was sich verkaufen lässt. Du hättest mit deinem direkten Vorgesetzten reden sollen, ob du 2 oder 3 Stunden Zeit kriegst um da mal etwas aufzuräumen. Den toten Code lass drinnen, aber unbenutzte Variablen rausschmeissen hättest du können. Die fehlenden Returnwert wären klammheimlich noch mitgegangen. Nicht zuviel auf einmal ändern! Auch wenn das jetzt makaber klingt, aber damit kann man sich eine Menge Ärger einhandeln. Du kannst davon ausgehen, dass es für fast jeden Fehler irgendwo einen Workaround gibt, der genau auf diesen Fehler angewiesen ist. Stellst du den Fehler ab, funktioniert der Workaround nciht mehr. Und dann hast du ein Problem, weil du erst mal die Stellen finden musst die ebenfalls bereinigt werden müssen. Bei solchen Sachen musst du behutsam vorgehen. Du musst versuchen die Leute in kleinen Schritten zu erziehen. Die haben seit Jahren nichts anderes mehr gesehen, als ihren eigenen Stuss und wissen zum Teil gar nicht, welchen Unsinn sie da veranstalten.
Thomas K. schrieb: > Also ich denke das du nichts grundlegendes falsch gemacht hast. Leider Danke für die unterstützenden Worte! > Gerade wenn eine solche Software bei Bahn- oder Bergbaubetrieben > eingesetzt wird, dann sind hier strenge Coderichtlinien Pflicht. Es ist Ich habe auch gar nichts gegen Coderichtlinien im allgemeinen, finde es sogar praktisch, wenn man nicht mehr die "ganz freie Auswahl" bei der Codegestaltung hat. Man hat klare Vorgaben, braucht nicht mehr so lange nachdenken, was jetzt die beste Lösung ist und kommt insgesamt schneller voran. Nur fand ich die Argumentation der Kollegen irgendwie fragwürdig. Die Software sollte ja nicht draußen in einer Anwendung laufen sondern nur dazu dienen, die Platine intern zu testen. Merkwürdig fand ich auch, dass man die schon sehr fein einstellbaren Möglichkeiten von GCC nicht nutzen wollte, stattdessen sollte es das 'lint'-Tool dann bringen. Nur denke ich, dass es sich mit der "Strengheit" der Überprüfung so verhält, dass sich 'lint' viel strenger einstellen lässt, also auch Sachen bemängelt werden können, die laut ANSI-C-Standard explizit erlaubt sind. Nur heißt das ja auch im Umkehrschluss: ein Programm, bei dem es GCC-Warnungen nur so hagelt, wird sich schwerlich erfolgreich durch eine 'lint'-Prüfung bringen lassen.
> Das war ganz schlecht. Damit hast du eine Menge Leute vor den Kopf > gestossen, deren Wort wesentlich mehr zählt als das des Praktikanten. > Den Chef interessiert das nicht. Der will nur etwas was sich verkaufen Schon klar, aber da hatte ich irgendwie ganz großes Pech mit der Situation! Der Kollege (ursprünglicher Autor des Codes), der mich betreuen/einarbeiten sollte, war aufgrund eines Krankheitsfalles in der Familie nur halbtags/stundenweise in der Firma. Für das behutsame Vorbringen konstruktiver Kritik war deshalb kaum Zeit da. Als Vertretung wurde dann der Kollege beauftragt, der beanstandet hatte, dass ich ein Datenblatt lese. Der war so unfreundlich, dass ich mich entschieden hatte, mit dem gar nicht mehr zu reden. Später gab es dann noch eine Situation, in der ich gefragt hatte, wo in der Firma die Kabelbinder aufbewahrt werden. Ich hätte einen gebrauchen können, weil bei einem Ethernetkabel die Verriegelungsklinke abgebrochen war und der Stecker immer aus der Buchse rutschte. Durchs Anbinden ans benachbarte Kabel hätte man das schnell fixen können. Seine Gegenfrage: "Wozu brauchen SIE denn bei Ihrer Arbeit einen KABELBINDER???" Ich habe dann gehofft, dass der Chef besser drauf ist. War er aber nicht. Alles umso ärgerlicher, weil ich glaube, dass ich mich mit dem "behutsamen Aufräumen von Code" eigentlich ganz gut auskenne. Ich sollte in einer früheren Firma mal zusätzliche Funktionen in einen Controller einbauen, dessen Programmspeicher eigentlich voll war. Ich habe dann die Codegröße durch schrittweises Aufräumen und Optimieren von 8K auf 6,5K bekommen, so dass die Funktionen noch hineinpassten.
> dass es Leute mit so einer Kinderstube bis zum Unternehmensinhaber gebracht haben So jemand kann sich in einem Angestelltenverhältnis nicht halten (sollte zumindest so sein). Der hat gar keine andere Wahl, als sich seine eigenen 'Sklaven' zu halten. > das brauchen Sie doch gar nicht!", sagte ein Kollege unfreundlich, Sieht für mich so aus, als wenn ihm der Chef schon lange auf die Nüsse geht und er seinen Frust an Dir (schwächstes Glied der Kette) auslässt. So ein A*schl*ch hatte ich auch mal - und habe nach 10 Wochen gekündigt. > Der Kompiliervorgang sah nun etwas anders aus, >hunderte, wenn nicht mehrere hunderte 'warning'-Ausgaben rasselten durch. Da hab ich ein 'déjà vu' - mein letzter Arbeitgeber, bei dem ich den befristeten Vertrag auslaufen lies. Un Cheffe hatte mich ernsthaft gefragt, ob ich noch weiter für die Firma tätig sein wollte. > deren Implementation dann aber nicht mit return <value>; verlassen > wurde, sondern einfach in die }-Klammer gelaufen wurde. Hmmmm... wenn die Funktion nicht im Rückgaberegister des ARM zurückgibt, nimmt die aufrufende Funktion dann nicht einfach den Wert in diesem Register und wertet ihn aus? Was dann wohl gaga sein dürfte. > Ob die Tests jedoch auch das getestet haben, was sie vorgaben zu testen Vorne hui, hinten pfui ;) > in welchem C-Dialekt es nochmal das "system"-Schlüsselwort gab Als Schlüsselwort gar nicht. Im Harbinson Steel steht: " The function system passes its string argument to the operating system's [k]command processor[/k]. Kenn ich nur von Unix (vermutlich auch in Linux so). > ich weiss wirklich nicht was ich für Schlüsse aus > solchen Vorfällen ziehen soll Weiß nicht, wie alt (wegen "Lebenserfahrung") Du bist, aber hak es einfach ab. Solche Idioten gibt es überall und die meisten begegnen im Arbeitsleben mindestens einem davon. Ich bin 1,5 von dieser Sorte begegnet. Dafür entschädigt der jetzige Job wieder :) > Hab ich noch massiven Nachholbedarf? Von meiner Seite ein ganz klares NEIN. Da haben eher Deine Exkollegen Nachholbedarf. Kann ich sagen, weil ich ähnliches in gedämpfter Form und mit Rückendeckung eines neuen Kollegen in der HW auch erlebt habe. > Kleine Firmen? Sicher typisch für Fälle wie oben. Teils, teils. Kann man vorher nicht wissen... > Große Firmen? Sind sicher bürokratisch, das kann ja auch nervig sein. Konzerne vielleicht eher bürokratisch. -> Wir suchen momentan einen SW-Entwickler (Bodensee Region). Gruß, Arne
Arne schrieb: > Kenn ich nur von Unix (vermutlich auch in Linux so). DOS+Win ebenso (natürlich mit anderem Inhalt im String) > ...Bodensee Region... Schade.
Aber ansonsten sehe ich es genauso: Es gibt viele miese Firmen, das ist halt eine davon. Da muß er einfach weiter nach einer Perle suchen.
>>Die Firma stellt u. a.Industriesteuerungsgeräte her, eines der Produkte >>basiert auf einem SoC mit ARM-Kern. Dazu dann viel industriespezifische >>Peripherie mit auf der Platine (mehrere Feldbusse und RS323, Ethernet, CAN >>und so ähnlicher Kram). is das ne firma nähe frankfurt/M ?? mal so aus eigenem interesse ^^
> Ich glaube mittlerweile, dass es kaum einen Chef gibt, der sich den > Sourcecode, den jemand gut modifiziert/vereinfacht/erweitert hat, > tatsächlich anschaut und dafür Anerkennung zollt. Also mein Chef nimmt sich die Zeit gewährt Lob und übt auch konstruktive Kritik. Da brech ich mir keinen ab zu sagen "Ja, da hast Du recht. Mache ich anders." In Deinem zweiten Post erkenne ich, dass Du Dir schon wieder gedanken, um Dein konkretes Handeln in dieser Bude machst - Du klemmst Dich wieder hinter den Sourcecode. Schalt ab - lass gut sein! Zur Beruhigung: In PC-Lint gibt es auch eine Anweisung, die Lint komplett abschaltet. Sowas soll dem Hörensagen in einem anderen Forum mal jemand benutzt haben, damit Lint klaglos über seinen Code rennt. Flog irgendwann auf und soll eine Abmahnung zur Folge gehabt haben! Weiss nicht, ob es stimmt, aber -w im GCC fällt in dieselbe Kategorie.
Klaus Wachtler schrieb: >> ...Bodensee Region... > Schade. Also ich finds schön hier: See, Alpen, keine Schwerindustrie, gutes Klima, gemäßigte Lebenshaltungskosten (wenn man nicht See/Alpenblick von der Terrasse haben will, oder in einer der Touri-Magneten - Überlingen z.B. - wohnen will).
Arne schrieb:
> -> Wir suchen momentan einen SW-Entwickler (Bodensee Region).
Geht es etwas genauer?
Junge Junge, Du musst mal lernen, die Dinge auf den Punkt zu bringen, also auf das Wesentliche zu reduzieren. Das koennte Dir wirklich helfen. Und das Formatierungsmittel "Absatz" solltest Du Dir ebenfalls mal einverleiben. Hab den Text nicht ganz gelesen (zu lang), aber wenn der Chef so ein Arschloch ist willst Du ja dort auch nicht arbeiten. Demnach hast Du kein Verlust, brauchst Dich auch nicht aufregen. Michael
gasst schrieb: > is das ne firma nähe frankfurt/M ?? > mal so aus eigenem interesse ^^ Nein. Die Firma befindet sich im Südosten NRWs, wo ich auch wohne. Ich hab immer in NRW gewohnt, mal im Norden, mal ganz im Südwesten. Mein ganzer Familien- und Freundeskreis wohnt (verteilt) im Raum NRW. Ich find es prinzipiell schön hier. Ein Umzug käme für mich eventuell schon in Frage. Ich habe nur eben vor der Tatsache Angst, dass man vorher nicht weiss, auf was für eine Firma man treffen wird. Da ich bei nervlicher Belastung schnell Probleme mit der Gesundheit bekomme, ist mein Grundtendenz eher "auf Nummer sicher gehen". Vielen Dank an alle Poster für die Unterstützung und das "Reindenken" in meine aktuelle Problemlage!!! Falls jemand eine interessante Firma weiss, bei der ich mich bewerben könnte, nenne ich mal meine Email-Adresse hier: Leon73@gmx.de
Michael G. schrieb: > Junge Junge, Du musst mal lernen, die Dinge auf den Punkt zu bringen, > also auf das Wesentliche zu reduzieren. Das koennte Dir wirklich helfen. Ich weiss dass, dass der Text saulang ist. Hab schon ne Menge weggelassen. Ich dachte ich muss aber wenigstens einmal die wesentlichen Stationen nennen und das ging schlecht kürzer. Frust von der Seele schreiben, so hab ich es ja angekündigt. An dem Absätze-Setzen arbeite ich noch! Nix für ungut!
Wenn 3 Entwickler an einem Projekt arbeiten, dann hast Du bestenfalls die Produktivität von 2, weil einer voll für die Kommunikation draufgeht. Bei Teamentwicklung gibt es immer Reibungsverluste, das ist nunmal so. Wenn man im Zeitplan hinterher hinkt, ist es keine gute Idee, das auf die jahrelange Arbeit anderer Mitarbeiter zu schieben. Entweder Du findest rein objektive Gründe oder Du konzentrierst Dich auf die Dir gegebene Aufgabe und nichts weiter. In nem Teamprojekt werden ja immer Schnittstellen definiert. Wenn Deine Schnittstelle Unklarheiten hat, dann fragst Du eben nach. Der Code außerhalb Deiner Aufgabe und deren Schnittstellen interessiert Dich (erstmal) nicht. Du schreibst nur Deine Module und Deine Header, um sie in das bestehende Projekt einzubinden. Und wenn man es richtig gut machen will, schreibt man zu seinem Modul noch eine Testsuite, um die Funktion und Fehlerfreiheit nachzuweisen. Naturgemäß werden nämlich die Fehler immer erst in nem anderen Modul gesucht, wenn das Projekt nicht funktioniert. Anhand der Testsuite kann man dann auch prüfen, ob das Modul vielleicht nur falsch aufgerufen wurde. Peter
So etwas habe ich bei uns auch bereits gesehen -- allerdings von der anderen Seite....... An deiner Stelle würde ich mir mal einige Bücher über Projekt- und Zeitmanagement durchlesen. Da gibt es immer auch Hinweise, wie man Prioritäten setzt, wann man "Mut zur Lücke" haben muß und ähnliches. Beispiele : M. Burkhardt :Projektmanagement -- Leitfaden für die Planung, Überwachung .... H.-D. Litke : Projektmanagement -- Methoden, Techniken, Verhaltensweisen B. Scheurer : Intelligentes Projektmanagement B. Klose : Projektabwicklung
@DrNo Wie hier schon gesagt wurde, so etwas muss man unter Umständen sogar hinnehmen obwohl es weder in deinem Sinne noch dem des Chefs ist. @peda > Wenn man im Zeitplan hinterher hinkt, ist es keine gute Idee, das auf > die jahrelange Arbeit anderer Mitarbeiter zu schieben. > Entweder Du findest rein objektive Gründe oder Du konzentrierst Dich auf > die Dir gegebene Aufgabe und nichts weiter. 100% ACK Arne schrieb: > -> Wir suchen momentan einen SW-Entwickler (Bodensee Region). Hallo Arne, wenn du dich hier anmeldest könnte man dich per PN kontaktieren. Gehts um Festanstellung? Dann evtl. an jobs@mikrocontroller.net wenden. Grüße, Edson
Peter Dannegger schrieb: > In nem Teamprojekt werden ja immer Schnittstellen definiert. Wenn Deine > Schnittstelle Unklarheiten hat, dann fragst Du eben nach. Der Code > außerhalb Deiner Aufgabe und deren Schnittstellen interessiert Dich > (erstmal) nicht. Es ist natürlich schön, wenn ein System nach diesen klaren Entwurfskriterien aufgebaut ist, d. h. die Kollegen schon nach diesem System gearbeitet haben und man dann seine eigene Arbeit demselben System folgend einbauen kann. Ich hatte nur den vagen Verdacht, dass ein solches System gar nicht erst begonnen worden war. Wirklich nur den Verdacht, aufgrund der allgemeinen "Unaufgeräumtheit" des Codes. Dann bin ich auf die Idee gekommen, nur mal zu Anzeigezwecken die Compiler-Warnungen einzuschalten, nur um grob zu gucken, wie es um die Code-Qualität bestellt ist. Verlauf der weiteren Eskalation: siehe oben.
DrNo schrieb: > Ein Umzug käme für mich eventuell schon in Frage. Ich habe nur eben vor > der Tatsache Angst, dass man vorher nicht weiss, auf was für eine Firma > man treffen wird. Da ich bei nervlicher Belastung schnell Probleme mit > der Gesundheit bekomme, ist mein Grundtendenz eher "auf Nummer sicher > gehen". Musst ja nicht gleich umziehen. Für die Probezeit lohn t es sich auch ein kleines Zimmer zu mieten und die alte Wohnung zu behalten, dann hast Du immer ne Alternative, das schont auch die Nerven. gruß Tom
@DrNo: Hätte ich eine Firma, ich würde dich sofort einstellen. Du versucht die Dinge gut und richtig zu machen und das ehrt dich sehr. Ich kann gut nachempfinden, was du da durchgemacht hast und kann dir sagen: Es ist nicht dein Fehler. Derart "festgeklopfte Meinungen trotz völliger Ahnungslosigkeit" sind glaube ich weit verbreitet. Es ist leider so, dass Leute die eine "inneren Anspruch" haben etwas gut zu machen, da draußen leider die meisten Probleme bekommen. Angepaßte Mitläufer die zu allem Applaus spenden was im Chefzimmer ausgebrütet wurde fahren in aller Regel am Besten. MaWin schrieb: > Am ehesten wohl im Umgang mit Leuten. Wenn man als "Quertreiber" und > > nicht "Bereicherung um neue Ideen" wahrgenommen wird, hat was mit deiner > > eigenen Vermarktung nicht geklappt. Würde sagen nein. "Quertreiber" heißt übersetzt: "War anderer Meinung als der Chef". Man kann allerdings daran arbeiten seine Ideen "besser zu verkaufen".
Hi, also ihr SW-Entwickler seit schon ein extremes Pfusch-Volk das ist echt unglaublich und ich meine nicht die Jenigen die den Code verbessern oder am besten sofort gut schreiben sondern die die Workarounds machen. Ich gebe euch einen Tip niiiieeeemals sicherheitsgerichtete Systeme programmieren ihr gefährdet Leben damit. Für so einen Mist muss man auf die Hände schlagen.
DrNo schrieb: > Seitdem geht mir die Frage im > Kopf herum, in welchem C-Dialekt es nochmal das "system"-Schlüsselwort > gab ... Posix, alias IEEE 1003.1-{Jahreszahl} Ob ich in so einer Firma hätte anfangen wollen, kann ich dir nicht sagen, schon allein ein Bestehen auf "konsequenter Nutzung der ungarischen Notation" wäre mir vermutlich abschreckend genug gewesen. ;-) Die Dinge, die in der Firma schief laufen, sind ja offensichtlich genug, dazu muss man nicht viel sagen. (Allerdings kann ich nicht glauben, dass ein lint all die Dinge durchgehen lassen würde, die der Compiler da als Warnungen ausspuckt.) Dir wäre allerdings als Tipp noch mitzugeben, ein wenig diplomatischer vorzugehen. Hätte möglicherweise in dem Laden auch nicht geholfen (wenn es schon suspekt ist, dass ein Ingenieur das Datenblatt des Herstellers liest, naja), aber vielleicht ja woanders. Als jemand, der da "von außen" in so einen Laden reinkommt, wirst du natürlich erstmal argwöhnisch beguckt, insofern muss man da wohl einen Spagat finden zwischen der (berechtigten) Kritik auf der einen Seite und dem termingerechten Abliefern der gewünschten Ergebnisse zum anderen. Wenn du nämlich deine Ergebnisse trotzdem noch bringst, dann ist denjenigen, die vermuten, dass du nur meckern und nicht arbeiten willst, erstmal der Wind aus den Segeln genommen. Vergiss die soziale Komponente nicht: deine Kollegen solltest du zu deinen Verbündeten machen, nicht zu deinen Feinden. Die haben die miese Codequalität oft nicht verbockt, weil sie unfähig waren, sondern weil die Randbedingungen sie dazu getrieben haben.
Richard S. schrieb: > An deiner Stelle würde ich mir mal einige Bücher über Projekt- und > Zeitmanagement durchlesen. Da gibt es immer auch Hinweise, wie man > Prioritäten setzt, wann man "Mut zur Lücke" haben muß und ähnliches. Klar, man muss auch so manche Ungereimtheit auch mal übergehen können. Ich glaube nur, dass das Ausmaß dieser Lücke so gravierend war, so dass ich eigentlich einen "Vollabbruch" des Projektes hätte anstreben müssen ("Kann ich so nicht, bin in dieser Firma nicht richtig"). Das habe ich mir aber am zweiten Tag des Praktikums so nicht getraut. Stattdessen habe ich mir überlegt, dass die Lücke ja eigentlich eine "negative Lücke" ist, also nichts was fehlt, sondern etwas was zuviel ist. Unbenutzte Variablen, nie aufgerufene Funktionen, totgelegter Code, sogar Dateien, die im Editorfenster als Teil des Projektes dargestellt werden, aber gar nicht ins das Executable gelinkt werden. Löschen geht ja schnell, habe ich mir gedacht, dass kann ich notfalls auch im Alleingang machen. Macht sogar richtig Spaß, wenn das Projekt dabei schrittweise immer kleiner und übersichtlicher wird. In die Nesseln gesetzt habe ich mich mit dieser Idee wohl trotzdem. Danke für die Buchtipps!
ungarische Notation und dann Compilerwarnungen ausschalten aiaiai was für eine Augenwischerei! Scheiss auf ungarische Notation, dafür mit 2 Compilern crosschecken, dass Code portabel ist. Wenn Chef so ist, dann kannst froh sein nur 7 Tage ihn sowas ertragen zu müssen. Einen Punkt habe ich aber noch: Wenn Code für verschiedene Platformen geschrieben wird, stehen im Header und C-File hunderte von verschachtelten #if's. Das rechtfertigt kein "Aufräumen" für ein ganz bestimmes Projekt. Das Ganze wird historisch gewachsen sein, vielleicht soll es so in der Vergangenheit unternommene Ideen dokumentieren.
Naja, aber #if 0 gehört normalerweise auch nicht permanent in irgendwelchen Code, zumindest nicht unkommentiert.
Also ich hab schon mehrere Charaktere im meiner Laufbahn kennen gelernt. Den überbezahlten Kollgegen der seit 20 Jahren den gleichen Mist macht ohne jemals etwas in Frage zu stellen, den überforderten Vorgesetzten der Angst vor jedem kompetenten "Untergebenen" hat und entsprechend Allergisch reagiert, und den Neulig/Praktikant/Newbie der die Weißheit mit den Löffeln gefressen hat und alles besser weis. Insbesondere mit letzteren hatte ich letztens wider zu tun. Und warscheinlich hat die Phase wohl jeder mal durchgemacht. Es gibt halt ein paar Leute, die kommen zu einem Projekt... (das schon ein paar Jahre lang läuft) und kommen aus dem Kritisieren nicht mehr aus. "ohman.. so so ein Käse... -lösch-, nene.. wie mann man das nur so machen -del-del-del-..." etc. ohne wirklich von tuten und blasen eine Ahnung zu haben. Alles mal Prinzipiell madig machen. Diese hab ich genauso gefressen wie die anderen beiden Charaktere. GRUNDREGEL für Neu/Quereinsteiger. Wenn was Komisch/Fehlerhaft aussieht, DANN HAT DAS IMMER EINEN GRUND. Und der Grund ist NICHT immer Inkompetenz. Dem Neulig obliegt es festzustellen was der Grund sein könnte. Insbesondere wenn die Kollegen eigentlich Kompetent sind, ist Vorsicht geboten. Wenn man wenig Berufserfahrung hat, neigt man dazu etwas zu vereinfachen. Wenn man selber noch nicht richtig aufs Maul gefallen ist, kann man da nicht wirklich mitreden. Ein paar Mögliche Gründe für "merkwürdige/fehlerhafte" Codes/Lösungen * Die "Lehrbuchmeinung" sieht zwar viel logischer aus, aber nach 2 Wochen hat jemand gemerkt das es so einfach nicht funktioniert. Zu 90% funktionierts, die letzten 10% machen eine Krücke draus. Entsprechend wurde eine andere evtl. für den externen Betrachter "Falsche" Lösung verwendet. Erkennt man meist daran das die Kollegen die sich mit dem Thema schon länger beschäftigen erstmal grinsen und irgendwann anmerken "hamma alles schon versucht". Gerade mit diesem Phänomen hab ich oft zu tun. Insbesondere bei Problemlösungen die auf den ersten Blick unlogisch klingen, weil sie viel Detailwissen voraussetzten das dem externen Betrachter fehlt. Das hab ich auch schnell gelernt, weil ich selber schon darauf reingefallen bin. "Das muss doch einfacher gehen"... nach 3 Tagen... "ahja... jetzt is mir klar warum der das so gemacht hat." * Zeitdruck. Ein Firma muss im wirtschaftlichen Rahmen arbeiten. Ich kann mich da nicht wie in der Uni hinsetzen und Tage und Wochenlang an diversen Passagen rumfeilen. Insbesondere die letzten 20% der Perfektion kosten oft 80% der Zeit. Irgendwann muss man einen Strich machen und sagen... genug... die Funktion wird erfüllt. Weiter gemacht wird wenn mal zeit ist (also nie :) ) Es widerstrebt mir persönlich weil ich ein 100%ler bin. Aber Wirtschaftlich ist das völlig nachvollziebar. Und dabei kommen halt teilweise unschöne, aber funktionierede Sachen raus. Das heist nicht, das die Autoren nicht drauf gehabt hätten, sondern einfach das irgendwann der Chef gesagt hat... ende... läuft. * Kompromisse. Oft kommen solche Krücken auch durch Kompromisse zu stande. Das können Vorschriften für verschiedene Länder, Unterschiedlicher Kenntnisstand der Kollegen oder schlichtweg der oben genannte Zeitfaktor sein. Es hilft halt nix wenn sich nur Kollege X mit dieser art der Programmierung auskennt. Wenn das ganze im Team funktionieren soll, ist halt ab und zu der kleinste gemeinsame Nenner nötig. Auch wenns das nicht so schön wird. Und da gibts noch mehr Gründe. Aber erst wenn wenn man sich die alle vor Augen geführt hat, kann man an den letzten Grund denken. * Die habens einfach nicht drauf. Aber das kommt eigentlich eher selten vor. Mein Fazit dazu... wenn man neu in ein Projekt oder eine Firma kommt, muss man erst mal würdigen was die Kollgegen bisher an Zeit und Schweiß investiert haben. Unabhängig von der Qualität. Und wenn an dann Ungereimtheiten ausgräbt muss man erstmal abklähren was die Gründe dafür sein können. Wenn man frisch dazukommt, kann man nicht alles wissen. Und wenn man dann was verbessern will, muss man auch psychologisch geschickt vorgehen. Wenn man die Gründe kennt Verständniss zeigen (Zeitmangel, GehtNichtAndersKrücken, etc.) und auch auf die Kollegen hören und miteinbeziehen. Das geht AUCH wenn die relativ wenig Ahnung haben oder schlichtweg Pfeifen sind. Schon alleine wenn man frägt warum das so gemacht wurde und im gleichen Satz mit einbringt "sieht nach spezieller Vorschrift/Zeitmangel/Problematischer Funktion aus" sugeriert man dem Kollegen/Chef das man was zum verbessern entdeckt hat, sich der allgemeinen Problematik aber bewust ist. Dieses deutet auch auf einen gewissen erfahrungsschatz hin. Zu dem Text was du obengeschrieben hast... ich hab leider nicht jeden Satz komplett gelesen. Aber du brauchst dich ned wundern das du rausgeworfen wurdest. Du machst ein Projekt deiner "Kollegen" madig (die das schon jahrelang machen), beschäftigst dich ungefragt mit Dingen die dir nicht aufgetragen waren, und meinst das du aus dem Stand heraus alles besser kannst wie die vorhanden Leute. Ich mein.. mehr versauen kann man sichs ned. Währ ich der Chef hätte mir das alles folgendes Bild vermittelt. => Der Kerl hat sogut wie keine längere Praxis & Projekterfahrung, keinen Teamgeist und weicht schnell vom Thema ab und verschwendet Rechourchen. Währst du geschikt vorgegangen hättes deine Arbeit gemacht und die "Bonusgeschichten" nebenbei (Mittagspause, Zuhause, etc). Pünktlich dein Ergebniss abliefern, noch einen draufsetzten mit einer Fleißarbeit die du evtl. sogar in Zusammenarbeit mit den Kollegen nebenbei aufgezogen hast. Sowas kann man Anfangs schon mal machen (soll aber nicht zur Gewohnheit werden). Nimms nicht zu persönlich, aber die Medailie hat immer 2 Seiten. Deswegen hab ich das jetzt auch mal von der 2ten Seite beleuchtet. Es kann auch sein das in der Firma schlichtweg nur lauter "inkompetente Ätztypen" (siehe Klasse 1 und 2 oben) waren. Dann hast wenigstens keine Zeit verschwendet.
Jörg Wunsch schrieb: > dazu muss man nicht viel sagen. (Allerdings kann ich nicht glauben, > dass ein lint all die Dinge durchgehen lassen würde, die der Compiler > da als Warnungen ausspuckt.) Nö, ich eben auch nicht. Weiter oben hat ja jemand vermutet, man könne das 'lint'-Tool auch so konfigurieren, dass es nur noch pseudomäßig arbeitet, also alles "absegnet". Seine Existenzberechtigung hat das Tool dadurch, dass es auch wahlweise so einstellbar ist, dass es STRENGER ist als der Compiler in seiner "strengsten" Einstellung. Vielleicht ist mein Wissen da ja nicht korrekt (ich habe es nur aus Wikipedia).
DrNo schrieb: > Nö, ich eben auch nicht. Weiter oben hat ja jemand vermutet, man könne > das 'lint'-Tool auch so konfigurieren, dass es nur noch pseudomäßig > arbeitet, also alles "absegnet". > Seine Existenzberechtigung hat das Tool dadurch, dass es auch wahlweise > so einstellbar ist, dass es STRENGER ist als der Compiler in seiner > "strengsten" Einstellung. Wobei ich sagen muss, das ich das so auch noch nie erlebt habe. Der Regelfall in den meisten Firmen ist: Der Compiler wird auf höchsten Warninglevel (oder maximal eine Stufe drunter) eingestellt UND der Code muss in dieser Einstellung ohne Warnungen compilieren. Wenn der Compiler das unterstützt, wird auch die Einstellung "treat warning as error" aktiviert. lint ist schön und gut. Aber Voraussetzung dafür ist, dass zunächste der Compiler ohne Warnungen durchkommt. Ich kann mir das eigentlich nur so erklären, dass der lint per Konfiguration mundtot gemacht wurde, dem Chef eine schöne Hochglanzbroschüre über lint hingelegt wurde und ansonsten haben die Entwickler gemacht was sie wollten, da der Chef (als Kaufmann) davon sowieso keine Ahnung hatte bzw. die Sinnhaftigkeit hinterfragen könnte.
Jörg Wunsch schrieb: > Naja, aber #if 0 gehört normalerweise auch nicht permanent in > irgendwelchen Code, zumindest nicht unkommentiert. Ja, man sollte schon erwarten dürfen dass dafür irgendwo ein #define angelegt wurde. Es ist ja auch nicht immer so, dass ein besonderes Testprogramm etc., das man nur während der Entwicklung einsetzt, als zusammenhängendes Codestück vorliegt. Wenn man dann aus den ganzen "#if 0" die Richtigen manuell heraussuchen muss, braucht man von "Standard" oder "Sicherheitsorientiert" gar nicht mehr zu sprechen. @DrNo Die Wahrheit liegt wahrscheinlich (wie so oft) irgendwo in der Mitte dessen, was hier geraten wurde. Hättest du nichts unternommen wäre möglicherweise während des Praktikums nichts Außergewöhnliches vorgefallen oder (worst case) du übernimmst den Schlendrian als Arbeitsmethode - so bist du immerhin jetzt schon um eine Erfahrung reicher. Grüße, Edson
So etwas
1 | Darunter nicht nur eher harmlose wie die nie benutzten Variablen, |
2 | sondern auch Sachen wie Funktionen, als int foo(void) definiert waren, |
3 | deren Implementation dann aber nicht mit return <value>; verlassen |
4 | wurde, sondern einfach in die }-Klammer gelaufen wurde. |
war in der Prä-ANSI Zeit, als man noch mit K&R C rumwurschtelte, durchaus gang und gäbe. void gab es nocht nicht und man kannte die Vereinbarung auswendig, dass die Funktion eben nichts sinnvolles retourniert und man daher den Returnwert nicht verwenden kann. Dokumentation bestand nun mal hauptsächlich daraus, in den Code zu schauen, was da eigentlich retourniert wird, und wenn da nichts auftauchte, dann war der Returnwert int implizit als void anzusehen. Protoyp, was ist das? Ne, das machen wir nur dann, wenn der Returnwert kein int ist (zb bei einem double). In der K&R Zeit kam es schon mal vor, dass man so eine Sequenz fand
1 | int foo( a, b ) |
2 | double a; |
3 | int * b; |
4 | {
|
5 | double sin(); |
6 | |
7 | *b = 8 * sin( a ); |
8 | }
|
Selbst in Lehrbüchern fanden sich solche Konstrukte :-) Klar, sollte das alles im Lauf der Zeit irgendwann bereinigt werden. Aber auch die SW-Industrie lebt das Motto: Nichts ist so langlebig wie ein Provisorium
DrNo schrieb: > Es gab dann eine Projektbesprechung, bei der ich > angemerkt habe, dass bei dem bestehenden Code noch nicht alles 100%ig in > Ordnung sei und dass wahrscheinlich einige Anpassungsarbeiten notwendig > werden würden. Die Kollegen sagten mir jedoch, dass der Code nach einer > firmeninternen Codierungsrichtlinie erstellt worden wäre. Diese wäre > verbindlich und dürfe nicht variiert werden War da der Chef dabei? Vielleicht hast du gerade Leichen im Keller gefunden die der Chef nicht kannte und nicht kennen sollte? DrNo schrieb: > Zwei Tage später gab es eine weitere kurze Projektbesprechung unter > Hinzuziehung des Firmeninhabers. Dort wurde sehr kritisch bemerkt, dass > ich dem Zeitplan deutlich hinterhinge und auch unnötige Zeit mit dem > Studium von Datenblättern verbracht hätte. Der ursprüngliche Autor des > Codes sagte, ein Praktikant, der in eine Firma will, müsse sich doch > darum bemühen schnelle Zwischenergebnisse zu präsentieren. Der Chef > gestand ein, dass der Code des Testprogramm schon gewissermassen mit der > "heissen Nadel" gestrickt worden wäre. Er hätte die Weiterarbeit an > diesem Code aber gerade bewusst als Aufgabe für mich ausgewählt, weil er > auch testen müsse, inwieweit ich teamfähig wäre und eine mir gestellte > Aufgabe zuverlässig erledigen könne. Ok, du sollst Schuld sein. DrNo schrieb: > Ich habe zu diesem Zeitpunkt dann meine "interne Aufgabenstellung" > variiert und gedacht, ich könne die Sache dem Chef mal in Ruhe erklären, > etwa indem ich ihm in einer vorher-nachher Situation am Rechner die > Sache mit den abgeschalteten Warnungen vorführe und dann zum Vergleich > meinen bereinigten Code, der keine Compilerwarnungen mehr produziert. Warum änderst du deine Aufgabenstellung? Das ist nicht deine Aufgabe. Du hättest einfach deine Aufgabe weiter machen sollen. Wobei ich mich frage, ob lint das wirklich so kann, was der Chef so gesagt hat und wann das gemacht werden sollte? Wahrscheinlich wie immer, also nie. DrNo schrieb: > Hab ich noch massiven Nachholbedarf? Kann mir jemand gute Skripte/Bücher > empfehlen? > Wo kann ich demnächst einen Arbeitgeber finden, der gut zu mir passt? > Automotive-Industrie? Soll ja stressig dort zugehen. > Kleine Firmen? Sicher typisch für Fälle wie oben. > Große Firmen? Sind sicher bürokratisch, das kann ja auch nervig sein. > Vielleicht doch besser umsatteln auf Gärtner oder Dachdecker. Das sind alles Verallgemeinerungen die stimmen können, aber nicht müssen. Um die Firma ist es aber nicht schade, such weiter, du wirst schon was passendes finden.
Franz B. schrieb: > Ein paar Mögliche Gründe für "merkwürdige/fehlerhafte" Codes/Lösungen > > * Die "Lehrbuchmeinung" sieht zwar viel logischer aus, aber nach 2 > .. > * Zeitdruck. Ein Firma muss im wirtschaftlichen Rahmen arbeiten. Ich > .. > * Kompromisse. Oft kommen solche Krücken auch durch Kompromisse zu Danke für Dein differenziertes Posting. > * Die habens einfach nicht drauf. Aber das kommt eigentlich eher selten > vor. Ich hatte irgendwie den Eindruck, das letzteres galt, kombiniert mit ausgesprochener Unfreundlichkeit. Tut mir leid, wenn das super arrogant, anmaßend und vernichtend klingt. Es ist auch eigentlich nicht mein Stil, so rüberzukommen, gerade weil auch mal gesundheitliche/nervliche Probleme hatte und auf einen verständnisvollen Arbeitgeber eigentlich angewiesen bin. Aber irgendwie sprechen - finde ich - die Fakten für sich. Der viele mit #ifdef 0 rausgenommene Code hatte nichts mit einem ausfuchsten System bedingter Kompilierung zu tun, wie es das beim Linux-Kernel gibt. Auch nicht mit Dokumentation. Es war nur Faulheit/Unentschlossenheit. 100%ig sicher bin ich da aber nicht, nur zu 95%. Deswegen liegt mir der Vorwurf, arrogant zu sein auch im Magen. Kann man vielleicht irgendeine quantitative Aussage treffen, etwa nach dem Motto: - im Ursprungsprojekt wurden u C-Dateien verwendet, v Header-Dateien, Gesamtcodegröße w Zeilen für die Aufgabe gebraucht. -für ein redundanzbereinigtes Projekt ohne "toten Code" lag der Gesamtaufwand nun bei x C-Dateien, y Headern, z Gesamtzeilen bei nachgewiesen gleicher Funktionalität Wenn nun gleichzeitig gilt: u >> x v >> y w >> z könnte man ja sagen: Am Anfang war massiv was faul, aber jemand hat es geschafft, das Projekt von nun an brauchbar zu machen.
Den Unterschied zwischen "geht noch" und "geht gar nicht"-Arbeit macht ausschließlich der Nasenfaktor. Will sagen, dass du noch so eine Scheiße abliefern kannst, wenn der Chef dich leiden mag. Andersrum kannst du alles richtig machen und der Chef ist froh wenn du weg bist, weil er dich Kacke findet. und Weil an den Entscheidungsprozessen Menschen beteiligt sind, wird nicht objektiv entschieden und beurteilt. Das ist so. also Wenn du nun mit fettigen Haaren und Schweißgeruch, die Vorarbeit des unbekannten Teams und die Leitungsqualitäten des unbekannten Chefs in den ersten Tagen lautstark als mangelhaft darstellst, ohne vorher drei mal mit ihm zusammen Kegelweltmeister geworden zu sein, hat sich die Sache schnell erledigt. So etwas darf nur sein eigener Sohn o.ä. Nächstes Mal vorsichtiger, es steht keiner auf "objektive" Meinungen/Verbesserungen. Dein Problem ist ein rein Zwischenmenschliches, kein Fachliches.
DrNo schrieb: > könnte man ja sagen: Am Anfang war massiv was faul, aber jemand hat es > geschafft, das Projekt von nun an brauchbar zu machen. Das ist schwer und muss immer auf den Einzelfall abgestimmt werden. Gerade als Neuling ist es immer schwierig, die Notwendigkeit von bestimmten Dingen beurteilen zu können. Codegröße ist nicht alles. Ich will jetzt nichts schön reden, nicht falsch verstehen. Aber der Albtraum jedes Chefs ist es: Ich habe eine Codebasis, die nachgewiesenermassen seit Jahren funktioniert und draussen im Einsatz ist. Im laufe der Jahre wurden die meisten (viele) Bugs bereinigt, so dass es jetzt zu keinen gröberen Problemen mehr kommt. Und da kommt jetzt so ein Jungspund daher, und meint er muss alles umdrehen. Und plötzlich geht dann nichts mehr. Und mit Verlaub: Wenn die Codebasis auch nur einigermassen eine kritische Größe überstiegen hat, dann kannst du in 7 Tagen nicht beurteilen, welche Nebeneffekte deine Änderungen alle nach sich ziehen. Manche sind harmlos, andere nicht. Mal von ganz simplen Tippfehlern, die eine Variable zu einer anderen machen, ganz abgesehen. Ist mir auch schon passiert, dass bei Verschönerungsaktionen aus einem i ein j wurde, dass sich beim Umstellen von Code Variablenscopes plötzlich überschnitten haben, ... kurz und gut: Nach der Verschönerungsaktion geht erst mal nichts mehr. Oder noch schlimmer: Es sieht so aus, als ob noch alles funktioniert, aber in seltenen Sonderfällen gehts nicht mehr. Also: Situation abhaken. Nächster Versuch. Du bist nicht schuld. Aber es mag auch gute Gründe geben, warum die Situation für die Firma so ist, wie sie ist. Wohl dem, der einen Entwicklungsleiter hat, der versteht, dass Code genauso wie jedes andere technische Gerät eine Wartung braucht. Wohl dem, der einen Entwicklungsleiter hat, der beim Chef auch mal etwas Zeit für Aufräumarbeiten loszwackt.
> So etwas darf nur sein eigener Sohn o.ä.
Oh, ja.
Diese Situation ist der absolute Super-GAU. In dem Fall kannst du nur
das Weite suchen. Gegen den Sohn hast du nie eine Chance, da kannst du
dich höchstens unbeliebt machen. Und irgendwann wird der dann selber
Chef.
Ne, ganz klar. Man muss nicht alles schlucken. Es gibt halt Dinge die laufen völlig verkehrt. Aber wenn man sich genauer mit den Gründen beschäftigt kann man besser darauf reagieren und auch argumentieren. Sowas lernt man halt im Laufe der Jahre, spätestens dann wenn einem genau die Dinge selber mal passieren die man an anderen kritisiert und selber nie für möglich gehalten hat. Dann bekommt man ein Verständniss/Gespür für solche Sachen und kommt auch besser mit den Kollegen klar. Ich war auch so ein "mit dem Kopf durch die Wand"-Typ... leider hab ich auch oft recht gehabt damit. Macht man sich damit nicht überall Freunde. DrNo schrieb: > könnte man ja sagen: Am Anfang war massiv was faul, aber jemand hat es > geschafft, das Projekt von nun an brauchbar zu machen. Ach.. genau. Ich hab ja noch einen Punkt vergessen. Das "LearningByDoingIchWolltsDochGarned"-Projekt. Ich denke das haben alle schon mal mitgemacht. Man fängt testhalber mit was neuem an. Neuer Controller, Sprache, whatever. Man probiert einiges aus, um in die Sache reinzukommen. Ziemliches Neuland, kommt aber schnell rein mancht aber so manchen Anfängerfehler. Man hat gerade ein bischen zeit, und das Projekt schreitet sehr schnell voran. Leider schreitets dann schneller als der Wissenstand voran... man kommt irgendwann an den Punkt wo man merkt das man ein paar Prinzipielle Konzeptfehler verbaut hat, und würde am liebsten von vorne Anfangen. Leider waren zwischenzeitlich die Chefs alle so begeistert das es ne eigendynamik bekommen hat, und schon in Richtung Einsatz/Anwendung läuft. Jetzt kann man nicht mehr zurück, sonst kommt man nicht annähernd an die Termine ran. Es wird lustig weitergemurxt, weil irgendwie funkionierts ja. Solche Leichen hab ich auch im Keller liegen. Aber ich bekomm die 250 Mannstunden einfach ned her um das geradezubügeln.
Hi, DrNo, > Das Problem ist nur, ich weiss wirklich nicht was ich für Schlüsse aus > solchen Vorfällen ziehen soll. Antwort auf meine Eindrücke: "Übrigens glaube ich weder an Unstern noch Fluch, sondern nur an kluges und dummes Handeln." (Werner von Siemens) Ich wünsche Dir mehr Geschicklichkeit in Menschenkenntnis, speziell a) "wie erkenne ich, an welchen Arbeitgeber ich geraten bin?" b) wie stelle ich mein Verhalten darauf ein? Die gequälten Bemerkungen Deiner Kollegen waren Symptome für die Ursache "unser Unternehmer, das Genie". Deine Einstellung war das Indiz für "unser Projekt ist in Zeitnot". Wohl alle Neuen bekommen die "heissen Eisen" zur Bearbeitung. Das, wovor sich die Erfahrenen gedrückt haben. Sowie das, was sich zum Knüpfen der Sündenbockschlinge eignet. "Die Kunst des Managements besteht ohnehin darin, mit weniger Wissen, als es die Mitarbeiter haben, diese zu führen." (Bernd Pischetsrieder, Ex-BMW„ Pischetsrieder’s Weisheit“) Manche Unternehmer stimmen Pischetsrieder zu. Andere verhalten sich auch entsprechend. Sehr viele aber stimmen nicht zu, viele von denen fragen sich, wie aus intelligenten, kreativen, zum Engagement bereiten Einsteigern in ihre Firma Duckmäuser werden: "Sagen sie mir, was ich tun soll" und "... aber ich habe alles richtig gemacht!" Gerade geniale Ingenieure gelten zu Recht als "schwierig". Mit ihrer genialen Idee haben sie Kunden gefunden, Finanziers, Erfolg. Frei von aller Bürokratie arbeiten manche 20h / Tag, ihre Leistung ist dreimal höher als die eines verängstigten Ingenieurs. Vor ihrem inneren Auge haben sie eine kristallklare, detaillierte Vorstellung vom Produkt, aber zu wenig Zeit, diese ihren Mitarbeitern zu vermitteln. Stress ist unvermeidbar. Deine Idee mit der Vorführung hätte Anerkennung gefunden von Führungskräften, die Pischetsrieders Weisheit zustimmen. Der geniale Ingenieurunternehmer aber erschrickt über a) den Angriff auf seine bewährte Praxis, b) das Aufzeigen einer grundsätzlichen Ursache für Mängel und weitere Verzögerungen. DrNo, lest Du die VDi-Nachrichten mit dem Karriereberater Heiko Mell? „Du sollst deine Firma nicht gegen ihren Willen glücklich machen wollen.“ (11. Gebot nach Heiko Mell, Karriereberater mit wöchentlich ½ Seite in den VDINachrichten) Das gilt ganz besonders für Neulinge in einer Firma, deren Unternehmer auf sein Genie stolz ist. Entwurf einer Verhaltensregel für Neueinsteiger: Suche erst Anerkennung für fleißige Arbeit nach Vorschrift, und erst nach dieser Anerkennung schau nach Klagen, also nach Problemen - und präsentiere dafür dann deine erste Idee. Das hätte Dir manchen Frust erspart. Ciao Wolfgang Horn
Karl heinz Buchegger schrieb: > Und mit Verlaub: Wenn die Codebasis auch nur einigermassen eine > kritische Größe überstiegen hat, dann kannst du in 7 Tagen nicht > beurteilen, welche Nebeneffekte deine Änderungen alle nach sich ziehen. Au ja, das ist auch ein ganz großer Punkt zb. in den Opensourceprojekten bei denen ich mitmische. Ein paar Leute wollen partou nicht kapieren das aber einer gewissen Codegröße und Komplexität eine gewisse Vorsicht geboten ist und andere Spielregeln gelten. Da kann man sich ganz böse Fehler einbauen, die man erst Jahre später bemerkt. Typisches scenario... ".. is das schlecht.. das geht so viel besser... blabla..." änderung wird Hochgeladen... funktioniert erstmal... später stellt sich raus, x,y und z funktionieren aber nicht mehr. "Oh, kein kleiner Fehler, das haben wir gleich..." gemurx-weitermurx-murx-frikel... und auf einmal hört man nichts mehr von den Personen... nicht mehr auffindbar. :)
Franz B. schrieb: > Ach.. genau. Ich hab ja noch einen Punkt vergessen. Das > "LearningByDoingIchWolltsDochGarned"-Projekt. Ich denke das haben alle > schon mal mitgemacht. Man fängt testhalber mit was neuem an. Neuer > Controller, Sprache, whatever. Man probiert einiges aus, um in die Sache > reinzukommen. Ziemliches Neuland, kommt aber schnell rein mancht aber so > manchen Anfängerfehler. Man hat gerade ein bischen zeit, und das Projekt > schreitet sehr schnell voran. Leider schreitets dann schneller als der > Wissenstand voran... man kommt irgendwann an den Punkt wo man merkt das > man ein paar Prinzipielle Konzeptfehler verbaut hat, und würde am > liebsten von vorne Anfangen. Leider waren zwischenzeitlich die Chefs > alle so begeistert das es ne eigendynamik bekommen hat, und schon in > Richtung Einsatz/Anwendung läuft. Oh ja! Kenn ich Du strickst mit der heißen Nadel eine GUI zusammen, damit der Chef beim Kunden was zum Herzeigen hat. Patsch. Baust du in diesem Prototypen ein bischen zu viel Funktionalität ein, dann gilt das dann für Chef und Kunde als 'fast fertig, ein paar Kleinigkeiten noch'. Und zu allem Überfluss geht dein Boss mit deiner, noch nicht mal völlig duchgedachten, Idee auch gleich noch bei 5 anderern potentiellen Kunden hausieren. Endeffekt: Übernächste Woche müssen wir liefern, ich habs schon 5 mal verkauft! Hä? Ich hab doch noch nicht mal einen blassen Schimmer, welche Fehlerfälle da überhaupt auftreten können, ob das Verfahren allgemein genug ist, und der verkaufts schon.
Wolfgang Horn schrieb: > Entwurf einer Verhaltensregel für Neueinsteiger: Suche erst Anerkennung > für fleißige Arbeit nach Vorschrift, und erst nach dieser Anerkennung > schau nach Klagen, also nach Problemen - und präsentiere dafür dann > deine erste Idee. Das kann ich nachvollziehen. Aber ich hatte ja auch das Problem zu lösen, die bestehende Softwarelösung erst einmal zu verstehen. Ich habe immer das Bedürfnis, mir einen Gesamtüberblick verschaffen zu wollen. Quasi unnötigen Ballast komplett ausblenden, an einem leeren Schreibtisch beginnen. Deswegen habe ich gedacht, ich könnte mit einer riskanten Aufräumaktion schon mal auf eigene Faust beginnen.
Sorry, muss noch mal was nachlegen. Da ich 7 Tage lang am rotieren war, komme ich nur langsam wieder runter. Der "vermurkste Code" enthielt passend zur wunderschönen ungarischen Notation die Variablentypen long (was zu 32 bit werden sollte), int (was meines Wissens auch zu 32 bit aufgelöst werden sollte), dann aber auch noch short. Letzteres war irgendwie in hardwarenahen-Sachen (MMU-Initialisierung, Interrupttabelle) als Funktionspointer im THUMB-Modus vorgesehen und sollte dann zu 16 bit aufgelöst werden. Ob das noch in aktivem oder "totgelegten Code" drinstand, weiss ich allerdings nicht mehr. Hätte man doch viel übersichtlicher haben können, einfach #include <inttypes.h> und danach nur noch int32 und int16 (bzw. uint32 und uint16) verwenden. Platzverbrauch, Lesbarkeit und Eindeutigkeit um 200% verbessert. Ich hak's jetzt aber wirklich ab, versprochen.
Was mir beim (nicht ganz alles) Durchlesen eingefallen ist: Wenn es sich um Code für einen Hardwaretest handelt, wird öfter 'schnell mal' etwas aus den Firmwarequellen der Endanwendung herausgeschnippselt, zusammengeklebt und zurechtgebogen, nur um die Hardware zu testen ohne alle "Pfade" der Anwendung durchlaufen zu müssen. Im Projektcode ist bereits alles drin, um die Hardeware anzusprechen aber es fehlen z.B. Schnittstellen zur GUI am Testplatz-PC. Das würde die vielen undefinierten Variablen und #if 0 erklären. Langfristig ist diese Methode keine gute Idee. Man hätte vorher den/die HAL so entwerfen müssen, dass man die enthaltenen Funktionen sowohl im Testcode als auch im 'richtigen' Projekt ohne Gebastel nutzen kann (dann hätte man auch gleich noch einen Softwaretest neben dem Hardwaretest). Das kostet aber wahrscheinlich zu viel Zeit. Der Hardwaretestcode wird ja meist nur kurz benutzt und bietet keine Funktionalität für den Endanwender, da wird sich dann noch weniger Mühe gegeben, es 'auszuprogrammieren'. Nicht das dies die Umgangsformen in der Firma irgendwie rechtfertigen würde aber dazu wurde ja schon einiges kommentiert.
Dieter T. schrieb:
> wo Wohnst du?
Soltau, das ist so etwa in der Mitte zwischen Hannover und Hamburg
(komme aber aus dem Süden, genauer aus Nürnberg).
Arne schrieb:
> Also ich finds schön hier:...
Unbestritten, das Schade bezog sich nur auf die Entfernung.
Hallo DrNo, technisch hast Du nichts falsch gemacht. Was Du beschreibst ist technisch tatsächlich haarsträubend und sollte geändert werden. Du wirst in Deiner Ingenieurslaufbahn noch viele ähnlich gelagerte Fälle vorfinden. Da bist Du sowohl bei kleinen Klitschen als auch bei großen Firmen nicht davor gefeit. Ich jedenfalls habe ähnlich haarsträubende Mißstände schon ein paar Mal selbst erlebt. Was Du falsch gemacht hast ist, dass Du die Situation der Firma, der Mitarbeiter und Deine "Rolle" darin nicht richtig eingeschätzt hast. Ich formuliere das folgende bewußt hart und unverblümt und aus der Sicht des Chefs und der Mitarbeiter: Die Firma wollte jemanden haben, der das vorhandene System möglichst schnell weiterentwickelt bis es seine Aufgabe erfüllt. Du bist aber in die Firma "geplatzt", hattest überall etwas auszusetzen, hast Deine Zeit damit vergeudet, nach Dingen zu suchen, die für Deine Arbeit irrelevant sind (Datenblätter) und dann auch noch damit angefangen, funktionierenden Code grundlos zu ändern und hast das KM-System auch noch so geändert, dass jetzt hunderte Warnings erscheinen. Du bist quasi mit einer "Arschbombe" in der Abteilung gelandet, hast den vorhandenen Mitarbeitern indirekt gesagt "ist alles Scheiße was ihr hier gemacht habt" und dem Chef, dass er keine Ahnung von dem hat, was er eigentlich treibt (lint/warning). Dein Rauswurf war dann nur konsequent. So eine "Nummer" kann (wenn überhaupt) nur ein ausgewiesener Fachmann mit guten Referenzen und vielen Jahren Berufserfahrung bringen - und auch nur dann, wenn der Firmenführung klar ist, dass ein Problem besteht und er die Rückendeckung der Führung hat. Der Fachmann (oft auch Missionar/Evangelist genannt) wird aber deutlich vorsichtiger/subtiler agieren als Du. Was Dir fehlt nennt man Neudeutsch "social skills" oder "soft skills". So - nun ein Schnitt und Schluß mit den harten Worten und eine Erklärung wie Du es hättest besser machen können: - Herausfinden, was Deine Rolle in der Firma ist und Dich entsprechend verhalten. Von einem Praktikanten bzw. Berufseinsteiger erwartet man nicht, dass er die Mitarbeiter mit mehrjähriger Berufserfahrung kritisiert, sondern ganz im Gegenteil dass er von den Kollegen lernt. Wenn klar ist, dass die Kollegen Dir technisch nicht das Wasser reichen können heißt die Devise: "Klappe halten und gute Mine zum bösen Spiel machen". Die Kollegen merken sehr schnell, dass Du technisch überlegen bist - aber das wird keiner öffentlich zugeben bzw. sich anmerken lassen. Wie würde er auch vor den anderen Kollegen und dem Chef dastehen, wenn ihm ein Praktikant/Anfänger erklärt, was er falsch macht. Wenn Du dich aber zurück hältst merken die Kollegen, dass sie Dir vertrauen können und nach ein paar Monaten kannst Du dann tatsächlich damit anfangen, das "Feld" von hinten aufzurollen. Schritt für Schritt - und ohne dass ein alteingesessener Kollege sein Gesicht verliert. Ich kenne keinen anderen Weg. Ohne die Rückendeckung der Kollegen oder zumindest deren Duldung wirst Du nichts bewegen können. Und Dein Vorgesetzter wird sich bei Problemen fragen "sind wirklich 5 meiner langjährigen Mitarbeiter neben der Spur oder liegt das Problem beim Neuen?". Wie diese Überlegung ausgeht liegt auf der Hand. Wenn Du fürchtest, dass der ganze lausige Quellcode durch den Du dich kämpfen sollst eher eine Art von Test für Dich ist, also im Sinne von "wenn der hier länger als drei Tage werkelt ohne laut Scheiße zu schreien, dann schmeißen wir ihn raus, weil er keine Ahnung vom Programmieren hat" oder wenn Du Angst hast, dass Du dich an dem Chaos "Mitschuldig" machst, dann führe frühzeitig ein klärendes Gespräch mit Deinem Chef - und zwar nur mit Deinem Chef ohne vorher bei den Kollegen Kritik an der Qualität zu üben. Vermutlich ist Deinem Chef schon klar, dass der Quellcode Schwächen hat. Du kannst Deinem Chef dann in aller Ruhe klarmachen, dass der vorhandene Code nicht Deinen Qualitätsvorstellungen entspricht, dass Dir klar ist, dass aber die Funktion jetzt Priorität hat und dass Du Dich erst mal darum kümmern wirst, danach aber noch mal das Thema "Qualität" aufgreifen wirst. Entwicklung ist meist ein Kompromiss zwischen den eigenen Anforderungen und den oft erschreckend niedrigen Anforderungen anderer Entwickler, die sich schon freuen, wenn der Compiler nicht mit einem Fehler aussteigt. Dass Du technisch fit bist geht aus Deinem Posting klar und deutlich hervor. Keine Sorge, "soft skills" kann man lernen, auch wenn aus einem Ingenieur meist kein Diplomat wird. Gruß, Bernd
Hallo Bernd! Zunächst mal vielen Dank für Dein differenziertes Posting, auch wenn es "harte Worte" enthält. > technisch hast Du nichts falsch gemacht. Was Du beschreibst ist > technisch tatsächlich haarsträubend und sollte geändert werden. Du wirst > ..... > Was Dir fehlt nennt man Neudeutsch "social skills" oder "soft skills". Klar les ich letztes weniger gern, da man ja heute überall liest, wie wichtig solche Fähigkeiten sind. Ganz sicher hätte ich mehr reden, erklären, "vorsichtig vorfühlen" müssen. Hab's schon ein paar mal erwähnt, aufgrund der Länge des Threads ist es vielleicht untergegangen: Es gab in den 7 Tagen nur ganz, ganz wenige Gelegenheiten zum Reden. Der Chef war ganz oft außer Haus oder hatte Besuch. Besonders doof: Der mir eigentlich zugeteilte Kollege (definitiv kein alteingesessener, sondern auch ein Jungspund) war aufgrund eines familiären Krankheitsfalles nur stundenweise da. Nur im Endeffekt denke ich: So wie es letztlich ausgegangen ist (Rauswurf mit Rumbrüllerei) wäre es eh der falsche Platz gewesen, um sich in Diplomatie zu üben. Es war eigentlich noch heftiger, nachdem ich die Kündigung erhalten hatte und ich dabei war, meine Tasche zu packen, baute sich "der Alte" aufgeplustert vor mir auf und sagte irgendwas von "ich solle jetzt ganz schnell machen, sonst wüsste er nicht..." oder so ähnlich. Also nee, vielleicht war es doch umgekehrt mit den fehlenden sozialen Fähigkeiten.
Ich hätte mich fünf Zentimeter vor ihn hingestellt und geantwortet "Sonst was?"
DrNo schrieb: > Klar les ich letztes weniger gern, da man ja heute überall liest, wie > wichtig solche Fähigkeiten sind. Ganz sicher hätte ich mehr reden, > erklären, "vorsichtig vorfühlen" müssen. In nicht all zu ferner Zukunft wirst Du Dir sicher sagen: "Dass ich NUR 7 Tage da war, ist das Beste, was mir passieren konnte." Stell Dir mal vor, was aus Deiner Gesundheit nach 6 bis 12 Monaten geworden wäre. Du scheinst jemand zu sein, der sowas "in sich rein fisst". Ging mir auch früher so. ;)
Practitioner of Kyokushin Karate schrieb:
^^^^^^
> ...
Gar nicht mal schlecht die Idee, sich auch nach den Ideen der
fernöstlichen Kampfkunst zu orientieren.
Man weiss dann, man hat für den Notfall noch was in der Hinterhand.
DrNo schrieb: > Hätte man doch viel übersichtlicher haben können, einfach > #include <inttypes.h> C99-Stil ist leider in der freien Wildbahn nach wie vor noch sehr wenig verbreitet, was insbesondere auch an Microsofts Ignoranz gegenüber diesem Standard liegt (und wenn da auf "ungarische Notation" geschworen wird, klingt das Microsoft-lastig). Aber auch viele Compiler für embedded CPUs sind mit C99 leider auf Kriegsfuß. Rühmliche Ausnahme: IAR, die haben die vollständigste C99-Implemen- tierung, die ich je gesehen habe.
DrNo schrieb: > Also nee, vielleicht war es doch umgekehrt mit den fehlenden sozialen > Fähigkeiten. Ja, auch das. Nur: er hat das Geld.
Jörg Wunsch schrieb:
> Ja, auch das. Nur: er hat das Geld.
Manchmal stinkt Geld auch doch.
Das hast Du immer noch nicht ganz verstanden. "social skills" sind die Fähigkeiten, auf seine Umgebung richtig zu reagieren. Eben auch in Situationen, in denen die Umgebung falsch/unfair oder ähnlich reagiert. So wie Du das beschrieben hast, hast Du in dieser Umgebung falsch agiert/reagiert. Und wie der Vorposter ebenfalls geschrieben hat : wenn man das erkennt, kann man das auch lernen.
Hallo Arne , würde mich freuen wenn ich auch eine kurze Info bekommen könnte ob der Job SW Entwickler noch frei ist. Mfg Commtel
Hi, DrNo,
> Deswegen habe ich gedacht,...
Klar. Deine Gründe sind verständlich und nachvollziehbar.
Entscheidungssatz: Jede Person wählt von allen Handlungsvarianten stets
diejenige, von der sie nach ihren Entscheidungsgrundlagen die geringsten
Mühen erwartet für die Ver-wirklichung ihrer persönlichen Wüsche.
Aber: Ich deute Deine Schilderungen so:
1. Du hast Dich auf die Aufgabe konzentrierst und sie gut erledigen
wollen.
2. Aus dem Fehlen der Unterstützung Deiner Kollegen für Dich ahne ich,
a) dass Du sie wohl nicht gewonnen hast, b) dass Du Deine Aufgabe eher
für Dich allein bearbeitet hast. Du hast nicht beschrieben - oder habe
ich das überlesen? - wie Du die Personen, die vorher an der Aufgabe
gearbeitet haben, befragt hast, aus welchen Gründen der Code so
geschrieben war. Ich habe auch nicht gelesen, dass Du Kollegen Deine
Ideen schon frühzeitig unterbreitet und deren Meinung eingeholt hast.
Ansonsten fühle ich mich mit dieser Kritik nicht wohl. Aus diesem Grund:
"Kritik soll zur rechten Zeit erfolgen. Man darf sich nicht angewöhnen,
erst dann zu kritisieren, wenn das Unheil passiert ist." (Mao Tse Tung)
Für das nächste Mal wirst Du gelernt haben.
Toi, toi, toi.
Ciao
Wolfgang Horn
Richard S. schrieb: > Das hast Du immer noch nicht ganz verstanden. > "social skills" sind die Fähigkeiten, auf seine Umgebung richtig zu Bin ehrlich gesagt ziemlich verunsichert, was diese vielgelobte soziale Kompetenz eigentlich bedeuten soll. Bin eigentlich ein Typ, der bislang immer als kompromissbereit und hilfsbereit galt. Ständig kann man das jedoch nicht durchziehen, dann frisst man wirklich zu viel in sich hinein. Der olle Bohlen - den zu Recht viele nicht mögen - sagte ja bei DSDS oft so Sachen wie: "Ja ist es denn in Ordnung zu lügen? Ich sag doch nicht, dass das gut ist, was ich in Wirklichkeit voll scheiße finde!" Manchmal glaube ich, diese Einstellung ist gesünder.
Wolfgang Horn schrieb: > Für das nächste Mal wirst Du gelernt haben. DrNo schrieb: > Leider kann ich die Sache nicht als > Einzelereignis einordnen und schnell vergessen, weil es bei früheren > Arbeitgebern schon einmal ähnliche Vorfälle gab. Ohne Kenntnis der Person, der Hintergründe, und des Umfeldes sind Aussagen zwar schwierig, aber in diesem Fall fürchte ich, daß dort doch mal professionelle Lebenshilfe gefragt ist. Auch unter dem Gesichtspunkt, daß die Anzahl der Arbeitgeber, die gewillt sind, 30-jährige Praktikanten mit 5 Jahren (anscheinend) gescheiterter Berufserfahrung einzustellen, arg begrenzt sein wird. Ich kann deine gesundheitlichen Probleme nicht einschätzen. Du kannst aber davon ausgehen, daß du überall als angestellter Lohnempfänger daran gemessen werden wirst, welches Ergebnis du erzielst, und daß du überall mit anderen Menschen und mit Stress zu tun haben wirst. Selbst als Gärtner, Hausmeister, oder 1-Euro-Jobber. Wenn du damit gar nicht klarkommst, gibt es überall Probleme. Wenn doch, kannst du auch als Softwerker weitermachen. Lösen kann ich deine Probleme nicht. Ich drück dir aber die Daumen. Oliver
Hallo DrNo, die Beschreibung deines Praktikums erinnert mich sehr an eine frühere Firma von mir. Es handelt sich nicht zufällig um eine kleine Klitsche in Südwestfalen?
Arne schrieb:
> -> Wir suchen momentan einen SW-Entwickler (Bodensee Region).
Und der Firmenname ist ein Geheimnis?
Wolfgang Horn schrieb: > 2. Aus dem Fehlen der Unterstützung Deiner Kollegen für Dich ahne ich, > a) dass Du sie wohl nicht gewonnen hast, b) dass Du Deine Aufgabe eher > für Dich allein bearbeitet hast. Du hast nicht beschrieben - oder habe > ich das überlesen? - wie Du die Personen, die vorher an der Aufgabe > gearbeitet haben, befragt hast, aus welchen Gründen der Code so > geschrieben war. Ich habe auch nicht gelesen, dass Du Kollegen Deine > Ideen schon frühzeitig unterbreitet und deren Meinung eingeholt hast. Zugegebenermaßen habe ich mir nicht so viel Mühe damit gegeben. Es wäre bei dem einen, abwesenden Kollegen die meiste Zeit eh nur telefonisch gegangen. Ich fühlte mich aber auch deswegen im Recht, weil bei mir der "optische Informationskanal", den ich zum Hineindenken in ein Problem benötige, total von der Unübersichtlichkeit der vorgegebenen Aufgabe verstopft wurde. Ich hab ja auf dem Bildschirm die Entwicklungsumgebung und darin auf der linken Seite ein schmales Fenster, dass die zum Projekt gehörigen Sourcefiles auflistet. Das Fenster war von oben bis unten gefüllt, ich glaube der Scrollbalken tauchte sogar schon auf. Größenordnung: knapp 40 h-Dateien und nochmal knapp 40 c-Dateien. Als ich merkte, da wird gar nicht alles eingebunden, bin ich komplett ohne Schuldgefühle ans Löschen gegangen. Es ist ja auch niemals ein unwiderrufliches Löschen, sondern man hätte, falls erforderlich, später wieder einzelne Sachen aus einer älteren Projektkopie hinzuholen können. Die Situation ähnelt, finde ich, der eines Handwerkers, der vor einen zugemüllten Arbeitsplatz gesetzt wird. Der ganze Müll liegt zwar nicht auf dem Werkstück, aber überall drumrum, so dass er es noch nicht mal komplett ansehen kann. Es holt sich dann eine Mülltonne und schiebt Bananenschalen und Butterbrotpapiere großzügig hinein. Beim nächsten Rundgang des Chefs in der Werkhalle wird er dann zusammengestaucht, weil er nicht den Entsorgungsbeauftragten kontaktiert hat und ein Plastik-Kugelschreiber mit in die Mülltonne gewandert ist. Und dann denke ich auch: Ich bin etwas raus aus dem Job, hab länger keinen C-Compiler mehr angeschmissen, kenne den ARM-Prozessor nicht so gut. Ich möchte mal sehen, wo dort Interrupttabellen sind, wie das Benennungsschema für Module in dem Projekt ist, am liebsten auch mal ins Datenblatt gucken. Da ist es mir einfach wichtig, dass der "optische Informationskanal" frei bleibt, und ich finde 40 + 40 Dateien sind wirklich massiv zuviel für so ein Projekt. Du sagtest was vom "verängstigten Ingenieur", dessen Arbeitsleistung gegen 1/3 Drittel der eines Ingenieur geht, der frei denken darf. Ich hab mir halt erlaubt, mal frei zu denken, rumzulöschen und die Forderung nach einer schnellen Lösung der eigentlichen Aufgabe in den Hintergrund gestellt. Aber auch nur weil ich gedachte habe, das Projekt geht danach noch weiter > Für das nächste Mal wirst Du gelernt haben. Ich denke schon.
Klaus schrieb:
> Es handelt sich nicht zufällig um eine kleine Klitsche in Südwestfalen?
Südwestfalen ist als Region richtig, aber das kann ja Zufall sein. So
ganz klein ist die Region ja auch nicht. Ich war dort schon bei mehreren
Firmen.
DrNo schrieb: > Es ist ja auch niemals ein unwiderrufliches Löschen, sondern > man hätte, falls erforderlich, später wieder einzelne Sachen aus einer > älteren Projektkopie hinzuholen können. ...was wieder extra Arbeit ist. Aber das klingt ja alles so, als hätten die da nichtmal ein VCS, bei dem du deine Änderungen erstmal ganz privat für dich machen und testen kannst. Versionsverwaltung per Kopie von Verzeichnisbäumen? Hmpf. :)
Jörg Wunsch schrieb: > kannst. Versionsverwaltung per Kopie von Verzeichnisbäumen? Hmpf. :) Ja, also ich habe mir immer wieder Kopien des ganzen Projektordners auf der lokalen Festplatte angelegt und damit herumexperimentiert. Auf dem Rechner, an dem ich gearbeitet habe, war "Microsoft Visual Source Safe" installiert, aber ich glaube, das war ausschließlich für PC-Anwendungssoftware gedacht, die mit Microsoft-Compilern erstellt wurde. Der eine abwesende Kollege sagte mir zu Beginn des Praktikums auch sowas wie "wir überlegen ob wir demnächst Subversion einsetzen". Auf seinem Arbeitsplatz lag der Ausdruck eines geTex-ten Skriptes mit dem Titel "Einführung in Versionsverwaltung mit SVN" oder so ähnlich. Aber ich muss gestehen, dass mich sowieso wenig mit SVN auskenne. Benutze es höchstens privat mal zum "auschecken" von Open-Source-Projekten. Müsste ich das besser kennen? Ich bin ja eigentlich auch eher Hardware-Entwickler, dass ich jetzt so tief in eine Software-Kiste geschubst wurde ist Zufall ....
... etwas stress-ärmeres wie Gärtner, Hausmeister oder 1-Euro-Jobber ... Bist du ein Spinner - oder wie kommst du auf diesen bekloppten Vergelich?
Martin schrieb: > ... etwas stress-ärmeres wie Gärtner, Hausmeister oder 1-Euro-Jobber ... > Bist du ein Spinner - oder wie kommst du auf diesen bekloppten > Vergelich? Warum ist das jetzt so bekloppt? Für Zufriedenheit im Job sind meiner Meinung nach viele Sachen wichtig. Nicht nur Bezahlung und intellektuelle Herausforderung, sondern manchmal auch körperliche Aktivität oder Arbeit an der frischen Luft. Mehr mit Menschen und weniger mit Technik zu tun zu haben, habe ich mir schon so manches Mal besser vorgestellt. OK, bisschen Polemik war beabsichtigt. Aber den Absatz oben meine ich ernst.
DrNo schrieb: > Aber ich muss gestehen, dass mich sowieso wenig mit SVN auskenne. > Benutze es höchstens privat mal zum "auschecken" von > Open-Source-Projekten. Müsste ich das besser kennen? Ich bin ja > eigentlich auch eher Hardware-Entwickler, dass ich jetzt so tief in eine > Software-Kiste geschubst wurde ist Zufall .... Subversion ist jetzt wirklich nicht schwer zu benutzen. Insbesondere mit TortoiseSVN macht es sogar Spaß, vor allem wenn man humorvolle Kollegen hat und deren Kommentare zu verschiedenen Versionsständen lesen darf :) Eine Firma, die keine vernünftige Versionsverwaltung einsetzt, ist eine "Frickelbude". Wer professionell entwickeln will, kommt um CVS, Git, Subversion etc. nicht herum. Übrigens kann man da nicht nur Sourcecode einstellen, sondern auch die PDF-Dateien und sonstige, mit denen man ein Projekt dokumentiert. Zumindest wenn man Wert darauf legt, es richtig zu machen ;-)
Mark Brandis schrieb: > Subversion ist jetzt wirklich nicht schwer zu benutzen. Insbesondere mit Ja glaub ich. Ich hab ein Buch über SVN von Galileo Computing, das sich ganz gut liest. Hab auch CVS und git schon benutzt, aber immer privat und immer nur von der "Auscheckerseite". Liegt eben daran, dass ich nur bei "Frickelbuden" war und/oder eh der einzige, der die Sofware für die Mikrocontroller erstellt.
Mark Brandis schrieb: > Eine Firma, die keine vernünftige Versionsverwaltung einsetzt, ist eine > "Frickelbude". Das würde ich Anfang des 3. Jahrtausends auch unterschreiben. Ob man allerdings Microsofts SourceSafe überhaupt als brauchbar einstuft, hängt sicher vom Geschmack der Leute ab. ;-) Ich habe schon mehr als einen darüber klagen gehört, dass er wiederholt Projekte damit nur aus einem Backup auf einen veralteten Stand rekonstruieren konnte, und wenn man mal nach "sourcesafe problems" gurgelt, dann landet man als erten Treffer gleich Visual SourceSafe: Microsoft's Source Destruction System
Bei Bombardier setzen sie in einer gewissen Abteilung eine zehn (!) Jahre alte Version von Visual Source Safe ein. Das Programm kommt nicht mal mit der Groß-/Kleinschreibung richtig klar. Warum man da nicht lieber eine kostenlose und wunderbar funktionierende Software einsetzt, wird wohl ein Geheimnis bleiben. Liegt vielleicht daran dass in jener Abteilung lauter Elektrotechniker sind, von denen viele qua Studium nur begrenzt Ahnung davon haben, wie man Software richtig entwickelt. Der Link ist übrigens richtig gut: "There are many fine solutions for revision control systems. SourceSafe isn't one of them." :)
DrNo schrieb: > Ich > hab mir halt erlaubt, mal frei zu denken, rumzulöschen und die Forderung > nach einer schnellen Lösung der eigentlichen Aufgabe in den Hintergrund > gestellt. Aber auch nur weil ich gedachte habe, das Projekt geht danach > noch weiter Und da ist der Fehler, du hast ohne Rücksprache deine Aufgabe nicht gemacht sondern etwas anderes. Wenn du das in einem Projekt machst, hagelt es Vertragsstrafen. Wobei manch anderer Chef mal ein Vier-Augen-Gespräch mit dir gesucht hätte.
dagger schrieb:
> Und da ist der Fehler, du hast ohne Rücksprache deine Aufgabe nicht
Nö. Hab gerade von jemanden noch Hintergrundinformationen per PM
erhalten.
Das hat letzte Selbstzweifel bei mir ausgeräumt.
Ich bedanke mich bei allen Postern.
Das ist ja echt ein Thread geworden, bei dem man Lesegeduld braucht.
Jungs, ich muss nur gerade nochmal was loswerden: Denkt dran, dass das hier nicht die kuschelige Selbsthilfegruppe von nebenan ist, sondern ein öffentliches Diskussionsforum, von dem ihr nicht wisst, wer das alles liest. Ich bin hier zufällig über den Beitrag gestolpert, habe angefangen zu lesen und nach kurzer Zeit war ich mir sehr sicher, dass a) die Firma für die ich arbeite hier mit ein Thema ist (wenn auch glücklicherweise nicht die im Fokus) und b) ich mir sehr sicher bin, wer hier der Threadstarter ist. Was mir ohne Anstrengung gelingt, würde insbesonders auch problemlos jemandem gelingen, der zufällig Mitarbeiter in der besagten Firma ist. Einen hinreichend paranoiden Geschäftsführer vorausgesetzt könnte das durchaus auch rechtlichen Stress zur Folge haben. Insofern hielte ich es für sinnvoll, dass wir uns alle geografischen und grafischen Spekulationen verkneifen und das Problem eher auf einem abstrakten Level diskutieren. S. B.
S. B. schrieb: > Was mir ohne Anstrengung gelingt, würde insbesonders auch problemlos > jemandem gelingen, der zufällig Mitarbeiter in der besagten Firma ist. > Einen hinreichend paranoiden Geschäftsführer vorausgesetzt könnte das > durchaus auch rechtlichen Stress zur Folge haben. Da weder Namen von Personen, noch von der Firma, noch vom genauen Ort genannt wurden, kann ich mir ehrlich gesagt nicht vorstellen was hier straf- oder zivilrechtlich relevant sein sollte.
S. B. schrieb: > Denkt dran, dass das hier nicht die kuschelige Selbsthilfegruppe von Auch Techniker wollen halt mal kuscheln. > durchaus auch rechtlichen Stress zur Folge haben. Ich bleibe da eher entspannt. Hier wurde ja von vielen Regionen gesprochen (Bodensee, Frankfurt, ...). Firmenlogos, die die Farben Orange und Schwarz enthalten, dürfte es wie Sand am Meer geben. Dass ich außer der 'Firma im Fokus' noch eine weitere mit einem Halbsatz touchiert habe, halte ich für harmlos, zumal ich von dieser Firma in keinster Weise etwas Negatives denke. @S. B.: Glaube auch zu wissen wer Du bist, können ja mal im RL quatschen.
DrNo schrieb: > Bin ehrlich gesagt ziemlich verunsichert, was diese vielgelobte soziale > Kompetenz eigentlich bedeuten soll. Also eine Ablenkung vom eigentlichen Thema. Aber nützlich, um besser zu handeln als allgemein üblich, Erfinder der Managementmodewelle von den "sozialen Kompetenzen" sind: Faix, Laier: "Soziale Kompetenz - das Potential zum unternehmerischen und persönlichen Erfolg", Gabler 1991 Sie waren wohl Personalentwickler bei IBM, als die PC's diese in den freien Sturz gebracht hatte. Die Produktivität der Zusammenarbeit brach ein. Wo früher Miteinander, da nun blankes Gegeneinander. Manager müssen befürchtet haben, man könne sie dafür verantwortlich machen. In dieser Situation wurde die Mär gern gehört: "Ihr, Manager, seid völlig schuldfrei, das Gegeneinander ist die Folge von Mangel an sozhialen Kompetenzen bei euren Mitarbeitern. Wir machen ein bißchen Training, und dann sind alle glücklich, alles wird gut, wenn ihr uns nur beauftragt." Diese Modewelle ist ausgelaufen, weil die Trainings nicht wirklich was gebracht haben. Wäre ein Unternehmen ein Patient, und Gegeneinander das Symptom, dann wäre dies Training extremer Ärztepfusch. Wegen Fehldiagnose und Fehltherapie. Sondern: Aussicht auf Personalabbau erzwingt geradezu den "Kampf um den letzten Arbeitsplatz". Der wird dann ausgefochten mit allem, was uns Mitarbeitern einfällt und was unsere Manager dulden. Unter denen ist der Kampf noch schrecklicher, weil die Verluste größer sind. Die bessere Therapie wäre antizyklisch und schmerzhafter: Wenn ein neuer Aufschwung nicht gelingt, muss man so viel Personal abbauen, dass die Überlastung der Überlebenden jede Angst vor Stellenabbau vertreibt. Nach dem Training nimmt die Zahl der Heucheleien zu. Wir überziehen die Stahlklingen an unseren Ellbogen halt "sozial kompetent" mit sanftem Fell und kleben freundliche Smilies drauf. Dieser "Schonüberzeug" garantiert aber noch mehr Unklarheit, noch mehr Mißverständnisse, erschwert die Kommunikation und erzwingt so Steigerung der Kosten. „Wenn die Leute nicht immer per wir in Geschäftsangelegenheiten sprechen, nicht Gelegenheit haben, sich bei Ehren und Sorgen des Geschäfts beteiligt zu fühlen, so kann man kein treues Festhalten, auch in trüberen Zeiten, verlangen und erwarten.“ (Werner von Siemens) Er ist mein Vorbild. Solange Manager für sich beanspruchen, sie hätten die größte Wirkung auf die Erfolge ihres Unternehmens, solange sind vor allem sie verantwortlich für das Schaffen und Bewahren produktiven Miteinanders. Folgerungen: 1. Wenn Personalentwickler solche Trainigs vorschreiben, wäre Verweigerung ein Anlass zur Abmahnung - und die Wiederholung meiner Argumentation könnte als Rebellion und Majestätsbeleidigung aufgefasst werden. Besonders, wenn ein Techniker den Soziologen oder Pädagogen widerspricht. 2. Genau das tun, was der Arbeitgeber will - zu Dolchstößen aller Art immer eine freundliche Miene machen, damit einem nicht ein Mangel an sozialen Kompetenzen vorgeworfen werden kann. 3. Den eigenen Boss "erziehen", damit im eigenen Team mehr Miteinander herrscht, dies produktiver arbeitet und seine Überlebenszeit verlängert. Ciao Wolfgang Horn
Hi, DrNo schrieb: > Zugegebenermaßen habe ich mir nicht so viel Mühe damit gegeben. Es wäre... > die meiste Zeit eh nur telefonisch gegangen. > Ich fühlte mich aber auch deswegen im Recht, weil... Natürlich hast Du nach bestem Wissen und Gewissen entschieden. Wie alle Menschen. Wie auch alle Verkäufer und Käufer von Lehmann-Zertifikaten, wie auch alle Kriminellen und Diktatoren. Wenn man ihnen nur zuhören würde. Errare humanum est. > Das Fenster war von oben bis unten gefüllt...bin ich komplett ohne Schuldgefühle ans Löschen gegangen. Nachvollziehbar. Von der eigentlichen Aufgabe her vernünftig. Aber - wenn Deine Aufgabe ein Patient wäre, der Tohuwabohu in den Quellen dessen Symptom und Du ein Arzt, was hätte dann die Diagnose sein können? Wir wissen von der FMEA: Wer in der Kette von Ursachen und Folgen die ursächlichere Ursache erkennt und abstellt, der ist im Vorteil. Das gilt nicht nur in der Technik, sondern auch sonst in der Arbeit. > Die Situation ähnelt, ... der eines Handwerkers, der vor einen > zugemüllten Arbeitsplatz gesetzt wird. Es holt sich dann eine Mülltonne... Klar. Das macht der vernünftige Handwerker. Trotzdem lohnt die Frage nach dem "wozu sieht das hier so aus? Wozu wurde das bisher geduldet? Wozu ist bisher keiner eingeschritten?" > Aber auch nur weil ich gedachte habe,... Du hast Dir Selberdenken erlaubt in einem Unternehmen, dessen Unternehmer - nach Deinen Schilderungen - das Selberdenken seiner Arbeitnehmer nicht kann oder gar nicht will. DrNo, Fragen und Selbstvorwürfe sind gesunde Symptome des Lernens. Im Lernschritt kommt es aber nicht auf die Quantität an, sondern auf die Qualität der Erkenntnisse. Ciao Wolfgang Horn
Ich verstehe das nicht ganz: - Studierter Dipl.-Ing - 5 Jahre Berufserfahrung ... und dann machst du ein PRAKTIKUM? Am besten noch unbezahlt? Auch wenn sich der Rest der Story ganz plausibel anhört bist du im Entwicklungumsfeld vielleicht wirklich falsch.
rglbmpf schrieb: > ... und dann machst du ein PRAKTIKUM? > Am besten noch unbezahlt? Nein, es war ein bezahltes Praktikum. Dass es "nur" ein Praktikum war, hatte den Grund in den chronischen Gesundheitsproblemen, die ich nun mal hatte und auf die jemand kommen kann, der sich meinen Lebenslauf genau durchliest. Ich hab dazu absichtlich nicht viel gesagt, um den Thread nicht noch länger und komplizierter zu machen. > Auch wenn sich der Rest der Story ganz plausibel anhört bist du im > Entwicklungumsfeld vielleicht wirklich falsch. Das hat schon mal jemand vermutet. Entwicklung ist aber der Bereich, der mich so aus freien Stücken heraus in der Technik am meisten interessiert. Deshalb tue ich mich schwer damit, dies als Motivationsquelle aufzugeben.
>Die bessere Therapie wäre antizyklisch und schmerzhafter: Wenn ein neuer >Aufschwung nicht gelingt, muss man so viel Personal abbauen, dass die >Überlastung der Überlebenden jede Angst vor Stellenabbau vertreibt. Falsch! Die Angst vor Verlust des Arbeitsplatzes gehört zum System des Zitat: "überwältigendenden, autoritären Kapitalismus", wie heute in meiner Tageszeitung in einem interessanten Interview zu lesen ist. Diese Drohkulisse ist wichtiger Teil des Systems.
> Wer professionell entwickeln will, kommt um CVS,
Sicher nicht (clientsidig) unter Windows.
Die Version ist (seit Anbeginn an) kaputt und macht kaputt.
>... und dann machst du ein PRAKTIKUM?
Bin ich auch der Meinung das man sich das nicht antun soll.
Es gibt die gesetzliche Probezeit um sein Können unter Beweis
zu stellen, falls der Betrieb nicht unter die Klitschenklausel
einzugruppiern ist. Leider muss sich kein Chef der Handverlese
unterwerfen, sonst würde es bei den Nieten in Nadelstreifen
ganz düster in D aussehen. Auf jeden Fall würde ich den Betrieb
niemals mehr erwähnen, auch nicht in einem neuen Unternehmen.
Die Spionage der Kollegen ist leider unberechenbar.
Wenn die Firmen sich bei der Einstellung nicht seriös und
wohlwollend verhalten und ulkige Bedingungen verlangen lieber
verzichten oder den Spies umdrehen. Von mir hätten die jedenfalls
keinen dokumentierten Code bekommen, falls ich in letzter Sekunde
nicht noch den Löschknopf gedrückt hätte. Hab das mal ähnlich
erlebt und der Praktikant vor mir hat die Löschaktion genauso
durchgezogen. Kam mir komisch vor und hat sich dann herausgestellt
das der Abteilungsleiter für den Posten zwar promoviert,
aber noch nicht die sittliche Reife für den Job hatte.
Übrigens Softwerker sind selten echte Teamplayer. Real ist dagegen
ausgeprägter Futterneid und Selbstsucht. Ein falsches Wort
und schon steht man beim Chef auf der Matte.
Ich tu mir sowas jedenfalls nicht mehr an.
Es lief da Einiges schief. Einem Neuen schlechten Code zu geben : Es laeuft eigentlich alles, muss nochmals angeschaut werden... ist schlechter Stil. Eigentlich sollte man von Null alles nochmals neu schreiben. Wenn ein Chef Codezeilen zaehlt ist er ein Pflug. Auf sowas ist man vor 20 Jahren reingefallen. Sei froh, biste nach einer Woche da rausgekommen. Nur nicht verzagen. Es haette eh nichts gebracht.
Um noch mal auf die "soft skills" / social kompetenz oder besser oder vllt. etwas übertrieben gesagt "Arschkriecherei" zu kommen: kann es sein, daß diese "Kunst" besonders ganz passabel nur von fachlichen Nieten und Nichtskönnern erfolgreich praktiziert wird? In meinen berufl. u. privaten Erfahrungen mußte ich solches "Glanz"-Verhalten dummerweise dann immer von den selben "Größen" zur Kenntnis nehmen, welche weder durch Leistung noch durch Können, also weder praktischen noch theoretischen Nutzen, glänzten. Denn wenn dies in der Allgemeinheit so wäre, dann lohnt sich wohl weder die Anstrengung fachlich wie leistungsmäßig seinen Anteil an der realen Arbeit zu suchen. Für eure Meinung dazu wäre man dankbar. mfG
Der Chef hat noch nichts von Qualitätssicherung gehört. Bei dem reift die Software beim Kunden. Das führt zu Kundenunzufriedenheit (ich höre schon das Geschrei des Kunden am Telefon) und zahlosen Softwareupdates (wer da noch den Überblick behält?).
Lustige Geschichte. Aber da sind einige Ungereimtheiten drin. 1. Man setzt einen Praktikanten nicht auf eine terminkritische Arbeit an. 2. Da wurde wohl ein Szenario aufgebaut in dem die Belastbarkeit des Kandidaten getestet wurde. Ergebnis: naja. Egal, mach dir halt mal klar daß du mit deiner Arbeit Geld verdienen möchtest. Die Selbstverwirklichung kann in Feierabendprojekten stattfinden.
@ Franz (Gast) >vllt. etwas übertrieben gesagt "Arschkriecherei" zu kommen: kann es >sein, daß diese "Kunst" besonders ganz passabel nur von fachlichen >Nieten und Nichtskönnern erfolgreich praktiziert wird? Jain. Sie ist dort aber logischerweise deutlich stärker ausgeprägt. Muss ja auch, denn schliesslich müssen/wollen die Leute im (Berufs)leben überleben. >"Glanz"-Verhalten dummerweise dann immer von den selben "Größen" zur >Kenntnis nehmen, welche weder durch Leistung noch durch Können, also >weder praktischen noch theoretischen Nutzen, glänzten. Jain. Aber auch der fachkompetente Mensch brauchst sie. Und sie hat nur wenig mit Arschkriecherei zu tun. Sondern u.a. was mit Stressvermeidung. Als Neuer in der Firma muss man erst mal die Füsse ruhig halten und die Lage peilen. Ist vollkommmen normal. Wenn man dann weiss, wer wie tickt, welche Verbindungen in der Firma existieren, welche Macken und Frickeleien so betrieben werden, DANN, aber auch nur DANN kann man VIELLEICHT etwas mehr Stellung beziehen. U.a.auch, weil man dann nach einiger Zeit (Wochen, Monate, Jahre) auch schon mal sich selbst mit seiner Arbeit einen Namen gemacht hat (je nach Typ im Guten wie im Schlechten ;-) und auch etwas Gewicht in die Waagschale werfen kann. Als Neuling (in der Firma) einfach mal alles umkempeln wollen ist schlicht falsch, selbst wenn man 100mal Recht hat. Das funktioniert pychiologisch nicht! Und genaud DAS müssen viele Fachleute lernen. Sonst reiben sie sich sehr schnell, sehr sinnlos auf. Und man darf auch nicht vergessen, dass der Mensch ein Gewohnheitstier ist. Das, vor allem mit fortschreitendem Alter, lernunwilliger und lernunfähiger wird. Gewürzt mit egozentrisch-choerischem Charakter und fertig ist der Albtraumchef ;-) Und wenn was schief läuft, muss es meist erst RICHTIG krachen, bevor die Leute lernen. Lernen durch Schmerz! Nicht schön, ist aber so! DA hat man ggf. eine Chance, die Leute zum Umdenken zu bewegen, indem man den Finger auf die Wunde legt und unschuldig fragt "" Tut das weh?". Aber selbst das klappt oft nur zu 50% und weniger. Klingt komisch, ist aber so ;-) >Denn wenn dies in der Allgemeinheit so wäre, dann lohnt sich wohl weder >die Anstrengung fachlich wie leistungsmäßig seinen Anteil an der realen >Arbeit zu suchen. Willkommen in der Realität! Denkst du, die Banker, Versicherungsvertreter, "Top"manager und weiss der Geier sind die wahren Leistungsträger der Gesellschaft? Nöö, die sind zum Großteil schlicht nur die Leute, die sich mit möglich viel Trara, Ellenbogen, Taktieren und wenig substantieller Leistung ein möglichst grosses Stück vom Kuchen abschneiden. Sowas nennt man Politik. MfG Falk http://www.amazon.de/Dilbert-Way-Weasel-Scott-Adams/dp/0752215590/ref=sr_1_1?ie=UTF8&s=books-intl-de&qid=1269771780&sr=8-1 Ist lustig, aber KEIN Comic, sondern je nach Blickwinkel Sarkassmus oder Zynismus.
Hey DrNo! Du brauchst dir eigentlich nur zu sagen: Hey! Ich bin ein fertiger Ingenieur, da kann mir doch ein Chef nix! Und gekündigt hat er mir nicht wirklich, ich wäre sowieso freiwillig gegangen, weil es mir dort nicht getaugt hat. Die Welt steht mir offen, ich bin in meiner Arbeitsplatzwahl komplett frei, ich bin frei in meinem Handeln, die Gedanken sind frei! Und heute ist Sonntag, gutes Wetter, mein Tank ist voll, ich habe gerade ein Dutzend geile Kassetten im Auto rumliegen, also fahr ich einfach nur weg, egal wohin... Los, DrNo! Das Leben ist dazu da, entdeckt zu werden! Wenn dir was nicht passt, mach es passend. ;-)
Stefan schrieb: > Los, DrNo! Das Leben ist dazu da, entdeckt zu werden! Wenn dir was nicht > passt, mach es passend. ;-) Full ACK! Danke Stefan, das Posting und der Vorschlag entsprechen sowieso grad meiner momentanen Stimmung.
DrNo schrieb: > Da fing es schon an etwas komisch zu werden. Ich war > dabei, mir eine pdf-Datei mit dem Datenblatt des SoC herunterzuladen. > "Warum sind Sie denn auf der Internetseite von [Hersteller des SoC], das > brauchen Sie doch gar nicht!", sagte ein Kollege unfreundlich, der mir > über die Schulter auf den Browserbildschirm schaute. Auweia, was ist denn das für eine fürchterliche Bude, in der Du da gelandet bist? Klingt so, als wäre der Chef jemand, der am Arbeitsmarkt aufgrund fachlicher und sozialer Defizite keine andere Chance hatte, als selbstständig zu werden und sich vergleichbare Leute angestellt hat.
>Leider kann ich die Sache nicht als Einzelereignis einordnen und schnell >vergessen, weil es bei früheren Arbeitgebern schon einmal ähnliche >Vorfälle gab. Wir kennen nur die Schilderung von DrNo. Es sollte aber schon zu denken geben, daß dieses offenbar nicht das erste Mal vorgekommen ist.
Backflow schrieb: > Wir kennen nur die Schilderung von DrNo. Es sollte aber schon zu denken > geben, daß dieses offenbar nicht das erste Mal vorgekommen ist. Nun ja zugegeben, bei zwei Arbeitgebern, die ich vorher hatte, lief es auch nicht glücklich. Aber nicht ganz genauso! In einem Fall gab es andere Vorfälle, und ich habe dann kurz vor Ablauf der Probezeit gekündigt. Das Dèja-Vu, das ich schon mal hatte, war, dass ich vor total unübersichtlichen Sourcecode gesetzt wurde und mein Kopf dabei anfing zu qualmen und zu qualmen und ich heftige Selbstzweifel bekam, ob ich es einfach nicht raffe oder was eigentlich los ist. Vielleicht hab ich ja trotzdem in dieser Zeit etwas gelernt über Einsatz der Programmiersprache C. Dass in diesem Thread auch Gurus wie Jörg Wunsch geantwortet haben und ein paar meiner Gedanken bestätigt haben, hat mir sehr geholfen.
"Kritik soll zur rechten Zeit erfolgen. Man darf sich nicht angewöhnen, erst dann zu kritisieren, wenn das Unheil passiert ist." (Mao Tse Tung) Dieses Zitat - ausgerechnet von diesem Mann, einer der schlimmsten Diktatoren, der 70 Mios. auf dem Gewissen hat! Aber er war ja immer schon ein Zyniker.
Hallo DrNo, hoffentlich hattest Du einen schönen So-Ausflug und konntest den Ärger einige Zeit vergessen. Die Arbeitsbedingungen in der "Bude" brrrr... Der Chef hat wohl schon abgefärbt. Für mich ist es das normalste der Welt daß man den µC mit dem man arbeiten soll auch kennt. Ich kenne solche Leute wie Deinen Chef auch, als Chef ungenießbar (ging allen so), also nicht nur mir. Nachdem ich mich selbständig gemacht habe kam dieser Typ zu mir und wollte daß ich was für ihn entwickle, dieser Auftrag (und weitere) lief völlig problemlos zur beiderseitgen Zufriedenheit ab, offensichtlich hatte der nur Probleme mit "Untergebenen" aber nicht mit Geschäftspartnern. Gibt man kritische Terminaufträge an Praktikanten (nichts gegen Praktikanten, da gibt es sehr gute Leute) handelt man-wie schon mehrfach erwähnt- leichtsinnig. Oder gilt "Geiz ist geil"? Selbst einer Neueinstellung wird man nicht unbedingt so einen Job anvertrauen. Nach meiner Erfahrung (>>25Jahre) ist es meist schneller, effizienter und einfacher "Zweifelhaften" Code vom Vorgänger zu "löschen" und neu zu schreiben. Das empfiehlt sich teilweise bei eigenem Code nach der x-ten Änderung/"Verschlimmbesserung". Sei froh, daß Du dort nicht mehr schaffen mußt, Du weißt auch welche Produkte Du besser meidest, weil dort die "schlimme" Software und was weiß ich noch verbaut ist. In einem muß ich den Vorpostern zustimmen, versuche erst mal herauszube- kommen warum was wie gemacht wird, und wenn es Deiner Meinung nnach hundertmal falsch ist. 1. Stecken "politische" Gründe dahinter: Änderung fast unmöglich 2. Stecken technische Gründe dahinter: Änderung vorsichtig mit guten Argumenten und Überzeugungsarbeit langsam möglich. (Am besten bei einem neuen und nicht so knappen Projekt machbar) 3. "Haben wir immer schon so gemacht"..... siehe 1.
Zum Thema Soft Skills: Man kann in so einer Situation natürlich erstmal den Chef in ein Vier-Augen Gespräch bitten und darauf hinweisen, was da alles Scheisse ist, mit dem Hinweis dass man deswegen nix geschafft hat. Man könnte aber auch mal ganz dezent die Kollegen fragen, warum z. B. die Compilerwarnungen abgeschaltet worden waren. Wäre wohl wesentlich besser angekommen. Gruss Axel
Also ich kann dir auch nur raten... vergess die ganze Sache schnell und mach weiter... jedoch sind/waren deine Softskills nicht ganz so toll, aber ich glaube es wurden dir nun hinreichend Tips an die Hand gegeben... Mein erster Chef hat mir in der Probezeit gekuendigt und mitgeteilt ich solle doch lieber Abstand von Elektrotechnik nehmen... Habe ich nicht gemacht, hatte das Glueck das mein naechster Job fantastisch war und ich den 2 Jahren viel gelernt habe. Das war noch nicht mal so sehr das technische, eher wie man am besten vorgeht und auch eben eine Menge Softskills... und nie die interne Politik vergessen... :) Aber ich muss natuerlich sagen man lernt nie aus... Ach ja noch ein paar Worte zu meinem damaligen Chef... er selber hat nie sein E-Tech Studium zuende gebracht und macht heute ganz was anderes... so kann es gehen...
Mag sein, aber er saß nicht auf einer normalen Stelle, sondern machte ein Praktikum. Vielleicht hätte es an ihm gelegen, etwas kommunikativer zu sein. Nachdem das aber halt nicht war, wäre es Aufgabe der Firma bzw. des Vorgesetzten gewesen, so etwas zu klären und in sinnvolle Bahnen zu lenken. Jemanden unbetreut ins Messer laufen zu lassen, kann ja nicht Sinn eines Praktikums sein. Wenn er etwas daraus lernt, ist es gut für ihn. Die Firma scheint da weniger lernfähig zu sein.
OK, ich bin kein Programmierer und kann es auch nicht, jedoch hoert es sich so an als wenn der Poster von Programmieren Ahnung hat.. Jedoch haette er nicht eigenmaechtig am Code rummurksen sollen... auch bezweifel ich das er ohne weitere Dokumentation/Fragen so genial ist nur durch scharfes Betrachten den Code zu verstehen... gerade das Nachvollziehen von Programmen die von anderen geschrieben wurden ist in den meisten Faellen doch eher sehr muehselig, oder lieg ich da falsch?
Mousse Chocolate schrieb: > verzettelt hat. Außerdem merkt man an seinen Postings daß er vom > Hundertsten ins Tausendste kommt. So wird das natürlich nie was Dass das ursprüngliche Posting lang und unübersichtlich ist, hatte ich ja bereits zugegeben. Es handelte sich eben um eine Verzahnung von fachlichen und arbeitsorganisatorischen Problemen, die ich schlecht kürzer darstellen konnte. Dass ein Thread sich in einem Forum länger hinzieht und auch "Nebenthreads" entwickelt, gehört meiner Meinung nach in Foren wie diesen zur Normalität. Einige Nebenthreads fand ich durchaus interessant (wie z. B. "befindet sich die Firma in Region XYZ" oder "kann es zu rechtlichen Problemen führen, wenn ein Mitarbeiter/Geschäftsführer 'seine' Firma wiedererkennt"), so dass ich dazu geantwortet habe. Ich möchte mich nun aus diesem Thread zurückziehen, da ich einiges zu tun habe (u. a. Jobsuche). Der Aufgabe, "social skills" zu verbessern, werde ich auch lang- und mittelfristig nachgehen. Meine ursprünglich genannte Email-Adresse habe ich aufgegeben - leider treten verstärkt Probleme mit Spam auf. Wer mich dennoch kontaktieren möchte, kann es probieren, indem er die Assoziation <eigenbrödlerischer Eulenvogel mit 4 Buchstaben>1973@gmx.de auflöst.
@DrNo: Nimm Mousse Chocolate nicht so ernst, er hatte heute zwischen 13.00 und 14.30 Uhr nichts zu tun, und hat so ziemlich jeden Thread hier mit seinen "Späßle" beglückt. Vielleicht ist er ja inzwischen wieder etwas runtergekommen.
Franz B. schrieb:
> * Zeitdruck. Ein Firma muss im wirtschaftlichen Rahmen arbeiten.
Was durch den Zeitdruck und das "wirtschaftliche Arbeiten" herauskommt,
sieht man z.B. daran, das heutzutage selbst Fernseher beim Kunden
"nachreifen", sprich durch Softwareupdates fit gemacht werden müssen.
Hier denken die Cheffs nicht nach. Was man an Zeit bei der Entwicklung
spart, zahlt man hinterher wieder drauf.
jo, sach nur TOYODAAAA zupi günstig und hui und dann Rückruf ...pfui. Wir hamn bald ein Gekaspere in der Wirtschaft, das der Gesellschaft in Summe mehr schadet als nützt.
> <eigenbrödlerischer Eulenvogel mit 4 Buchstaben>
Kiwi? Ente? Pfau? Huhn?
(Mir will kein Eulenvogel mit 4 Buchstaben einfallen, vielleicht geht ja
ersatzweise ein beliebiger Vogel)
kauz ...ich wusste, dass sich das Ornitologiestudium irgendwann mal als nützlich erweisen wird ;-)
>> <eigenbrödlerischer Eulenvogel mit 4 Buchstaben> > Kiwi? Ente? Pfau? Huhn? Kauz So, und jetzt bitte diesen unsäglichen Thread schließen...!
Es ist wie ein Spiel vernünftig mit seinen Vorgesetzten umzugehen: Bsp: Wenn ich Frei haben möchte an einem Bestimmten Termin, dann bereite ich meinen Chef ein paar Wochen indirekt darauf vor. Am Tag wo es soweit ist schlägt er mir vor das ich doch lieber frei machen soll. und dann sage ich : ohh aber das geht doch gar nicht die arbeit die noch zu tun ist. Dann sagt er ich kümmere mich darum und alles ist gut vom chef in den Urlaub heschickt ;) In der Hochschule ist es genau so wenn man direkt einen guten vorschlag macht dann wird der als blödsinn dargestellt. Aber wenn man dem Chef/Prof beim Kaffee oder wärend der arbeit ein paar kleine spur aus "Brotkrümeln" streut, und ihn dazu bewegt das er selber auf die Idee kommt dann ist alles super. Niemals mit der Tür ins haus fallen. Aber die Firma und das Umfeld wie du es beschrieben hast, kannste sowieso an den Nagel hängen. Sei froh das du da weg bist.
@ Peter, und das ist eine wahre Begebenheit, mit dem Urlaub, und funktioniert so bei dir. Gratuliere zu solchem Chef, wird aber in Zukunft nicht mehr viele von der Sorte geben. Aus meiner länger herliegenden berufl. Vergangenheit hat das damals nicht so funktioniert, und da ging es um eine OP. Nur dumm für unseren GL, daß man eine OP nicht so einfach platzen lassen kann. Im Endeffekt war ich aber der Dumme, weil Querulant - wenn man führungsunfähige Leute in falsche Positionen mit hartnäckigen MA platziert, wird das ebend Nichts. Habe mich dann in eine andere Abteilung (AD mit Körpereinsatz) versetzen lassen, war aber auch nicht mit mehr Erfolg gesegnet, lag dann wohl doch an mir, mich mit div. Führungskadern nicht gut stellen zu können. Entweder man ist ein schmeichelhafter Typ und schleimt sich so durch den Job, dann klappt es meist mit den ganzen Vorgesetzten, nur nicht mit den nächsten Kollegen. Doch die können einen ja nicht entlassen, höchtens beim Chef anschmieren, aber das war mir dann auch zu blöd, und ich hab mich für die Kollegen und die Arbeit entschieden, was aber auch nicht der goldene Weg war. Es gibt immer wieder welche mit zwei Gesichtern. Zum dem zweiten Fakt, das kann man voll und ganz nur so bestätigen. Das kratzt dann schon einigen an der Ehre, wenn da Einer so daher kommt, und die ganze Ordnung so durcheinanderhaut. Gewisse Leute möchten gern von unten gekrault werden und an jeder Idee oder Erfindung mitbeteiligt werden. Dabei sind das meisten die nur unterdurchschnittlichen "Größen".
> wenn man führungsunfähige Leute in falsche Positionen > mit hartnäckigen MA platziert Das kann auch Absicht sein, um die MA rauszumobben.
Franz schrieb: > Entweder man ist ein schmeichelhafter Typ und schleimt sich so durch den > Job, dann klappt es meist mit den ganzen Vorgesetzten, nur nicht mit den > nächsten Kollegen. Sehr schön formuliert. In so einer Situation habe ich eher ein Problem mit dem Vorgesetzten. Gut, dass es Abteilungen (bzw. Firmen) gibt, wo der Vorgesetzte keinen Wert auf Schleimer legt. Glücklicher weise durfte ich vor paar Jahren in eine andere Abteilung wechseln, und siehe da, alles ist schön, und ich musste mich nicht ändern :-)
>Gratuliere zu solchem Chef, wird aber in Zukunft nicht mehr viele von >der Sorte geben. Hääh, ein Chef, den man monatelang mit irgendwelchen "Tricks" darauf "vorbereiten" muss, dass man mal einen Tag freinehmen kann? >Aus meiner länger herliegenden berufl. Vergangenheit hat das damals >nicht so funktioniert, und da ging es um eine OP. >Nur dumm für unseren GL, daß man eine OP nicht so einfach platzen lassen >kann. Also entschuldige bitte, aber ihr spinnt doch. Du willst behaupten, Dein Vorgesetzter hätte Dir untersagt, Dich zu einem bestimten Zeitpunkt einer OP zu unterziehen? >Im Endeffekt war ich aber der Dumme, weil Querulant - wenn man Ach daher weht der Wind! Was ihr da schreibt, kann nur totaler Unsinn sein. Ich habe ja schon einiges erlebt, aber es war bisher immer völlig banal, einen oder mehrere Tage frei zu bekommen. Rein zum Chef, sagen "ich brauche in zwei Wochen einen Tag frei", Chef sagt "kein Problem" und Thema erledigt. Wenn man natürlich direkt einen Tag vor einer wichtige Deadline auf einem freien Tag besteht, kann man nicht mit einem unkomplizierten Verhalten seitens des Vorgesetzten rechnen.
>>Peter >>Es ist wie ein Spiel vernünftig mit seinen Vorgesetzten umzugehen: >>Bsp: >>Wenn ich Frei haben möchte an einem Bestimmten Termin, dann bereite ich >>meinen Chef ein paar Wochen indirekt darauf vor. Am Tag wo es soweit ist >>schlägt er mir vor das ich doch lieber frei machen soll. und dann sage >>ich : ohh aber das geht doch gar nicht die arbeit die noch zu tun ist. >>Dann sagt er ich kümmere mich darum und alles ist gut vom chef in den >>Urlaub heschickt ;) also wenn da sowas nötig wäre, würd ich direkt künden... ist ja nen witz... also wenn ich am nächsten tag frei machen will (wenn nicht gerade was lichterloh am brennen ist) sag ichs und es ist ok... wenn ich am freitag mittag feststelle das ich keinen bock habe am nachmittag zu arbeiten, sag ichs und ok... sollte auch so sein denke ich...
Hallo Gast1 von heute 10:40 Uhr , kannst du dir vllt. auch mal vorstellen, daß es MA gibt, ohne die der Laden ganz einfach nicht rund läuft, die praktisch an allen Ecken und Enden die heißen Kastanien aus dem Feuer holen müssen und dann auch noch Feuerlöscher spielen sollen? Wenn du solche Umstände in einem "Team" hast, und dummerweise derjenige bist, auf den sich immer Alle verlassen können, und das auch tun, doch wenn du dann mal ein größeres gesundheitl. Problem hast (OP mit anschl. Krankschreibung weil AU, durch Leistungssport Entzündung d. Achillessehne), den Termin rechtzeitig Wochen vorher bekannt gibst, und dann nicht weiter nachfragst(warum auch), und dann eine Woche vorher nochmal darauf hinweist, und der GL fällt dann angeblich aus allen Wolken. So wie "hättest du das nicht rechtzeitig vorher sagen können". Was soll man dann davon bitte schön halten? - für mich war ab dem Zeitpunkt dort der Laden gelaufen, und das war kein Scherz vom "TL"! Man wurde ganz einfach als treuer und zuverlässiger MA nicht Ernst genug genommen, wieso auch, so lange wie der Depp immer schön alles so macht, wie es alle haben wollen = ergebnisorientiert arbeiten. Ab dem Zeitpunkt ist mir dann ein Licht aufgegangen, und ich habe meine Einstellung zu Führungskräften dann mal ein wenig geändert, seit dem waren die auch immer sehr vorsichtig im Umgang mit mir. War ab dann aber dort auch kein richtiges kollegiales Arbeiten mehr möglich. Und noch was zu deinen Arbeitsverhältnissen, bei uns gab es da mehrere Hirachrchien, und die waren aber dann auch immer auf die Leute ganz unten angewiesen, weil dort wurde die Leistung erbracht und nicht irgendwo dazwischen. Und zu dem Zustand mit "den Chef vorsichtig darauf vorbereiten" kann man dann auch noch hinzufügen, man muß dann aber auch noch immer den richtigen Moment seines Chefs Laune abpassen, damit das so funktioniert, wie gewollt. So was ist in der Produktion absolut leistungsdemotivierend und behindernd. Nur interessiert das gewisse Chefs nicht die Bohne, die arbieten im Gegensatz noch darauf hin, daß man ihnen regelmäßig in den Ar... kriechen muß. Bekommen sie i.d.R von sehr vielen ihrer MA so vorgelebt, nur sind das meistens die Leute, die sich so den ganzen Tag über an irgendwas festhalten um zum Feierabend rechtzeitig die Kurve zu kriegen und dann noch zu sagen, man daß habe ich heute geschafft! Hallo Roland, deine Verhältnisse bei der Arbeit muß man nicht unbedingt verstehen - Gleizeit und nach Std. bezahlt, richtig? Oder nur ein sehr gutes Verhältnis zum Chef?
>...daß es MA gibt, ohne die der Laden ganz einfach nicht rund läuft, die >praktisch an allen Ecken ... Ja, ja, die Friedhöfe sind voll von unersetzbaren Mitarbeitern.
Was Manche hier nicht so alles zwischen den Zeilen lesen können, und dann mit nur einem Satz auf IHREN Punkt bringen. Die Darstellungsweise war sicher nicht glücklich gewählt, man könnte das auch so formulieren: durch gewisse MA (oder besser deren Arbeitsweise) ist es einigen anderen MAn sehr angenehm, die Arbeit zu genießen. Es gibt prinzipiell keine nicht ersetzbaren oder unentbehrlichen Leute, nur wenn eine bestimmte Sorte von MA nicht mehr in der Gruppe verfügbar ist, verändert sich plötzlich schlagartig das Arbeitsklima und der GL muß sich einen neuen Plan zur Verteilung der Aufgaben unter seinen verbliebenen Leuten machen. Oder für passenden Ersatz sorgen.
>...und der GL muß sich einen neuen Plan zur Verteilung der Aufgaben unter >seinen verbliebenen Leuten machen. Oder für passenden Ersatz sorgen. Ist das nicht sein normaler Job? Oder muß er kontrollieren, ob die LEDs richtig herum eingelötet sind? Dieses Forum müßte doch ein Eldorado für Headhunter sein. 99% aller Teilnehmer sind tragende Säulen ihrer Firma und retten diese ständig vor dem durch andere verursachten drohenden Ruin, um dann durch undankbare MA/GL gemobbt oder gefeuert zu werden..
Hallo Backflow, der 1.April ist seit über 2 Tagen Geschichte. Man kann ja nicht wissen, wie deine Chefs, oder du eingestellt sind / bist. I.d.R. möchten die aber so wenig wie möglich Veränderungen in ihrem Bereich, wenn die sich mal ihre Planungsstrategie, zum Einsatz ihrer MA, ausgedacht und über längere Zeit erfolgreich praktiziert haben. Wenn du natürlich nur zum LED´s Einlöten taugst, und dafür deine ganze Arbeitszeit benötigts, mein Beileid. Dann kann man natürlich auch nachvollziehen, daß man solchen Leuten nur durch Mobing oder Kündigung ihre Grenzen aufzeigen muß. Andere gescheite Leute ziehen es vor solche Umstände durch eigene Initiative zu verlassen. Aber jeder wie er kann und mag.
>I.d.R. möchten die aber so wenig wie möglich Veränderungen in ihrem >Bereich, wenn die sich mal ihre Planungsstrategie... Bei uns wird die Arbeit abgesprochen und ggf. ein Zieltermin zur Fertigstellung vorgegeben. Wie ich dann vorgehe ist meine Angelegenheit. Könnte auch daran liegen, daß bei uns die Leute selbstständig arbeiten wollen und auch können. Denk mal darüber nach, warum Dein Chef ständig Deine Anwesenheit will. Vielleicht braucht Deine Arbeitsweise entsprechend häufige Kontrolle.
Hallo! Tröste Dich. So etwas kommt vor. Ich habe etwas ähnliches erlebt. Maschinensteuerung, Kerneltreiber für Windows und Linux. Mit den Tools kannte ich mich aus, ich hab das nicht zum ersten Mal gemacht. Am ersten Tag habe ich meine Hardware hingestellt bekommen, dazu etwa 15 MB spärlich kommentierten C++ Quellcode, und die Aussage: "Da drüben (drei Tische weiter) sitzt Dein Handbuch. Wenn Du Fragen hast, frag." Punkt. Das wars. Keine weiteren Erläuterungen. Zeitvorgabe 6 Wochen. Keine drei Tage später hatte ich das dumpfe Gefühl, dass aus den 6 Wochen eher 16 Wochen werden würden. Ende vom Lied. Nach 6 Wochen hat sich der vorherige Entwickler das ganze angeschaut und festgestellt, dass ich eine wesentliche Anforderung nicht berücksichtigt habe. Tja, Pech gehabt. Wenn keiner auch nur annähernd so etwas wie eine Dokumentation schreibt, dann muss sich niemand darüber wundern. Man muss nicht nur fragen können, man muss auch die richtigen Fragen wissen. Ich garantiere dafür, dass diese Firma bis heute nichts aus diesem Vorfall gelernt hat. Und ich habe gelernt, dass es genauso wichtig ist, dass man in ein Team und in eine Firma hineinpasst. Menschen sind halt zu verschieden als dass das immer klappt. Ich habe die Konsequenzen gezogen und bin in der Probezeit gegangen, und ich weine diesem Laden keine Träne nach. Also Kopf hoch und auf zum nächsten Versuch. Der Spruch "Kennst Du einen, kennst Du alle" mag für Konzerne gelten, aber je kleiner die Firmen werden, desto größer wird die Bandbreite an möglichen Erlebnissen. Und die 7 Tage, die waren doch so gut wie gar nichts, das lohnt doch nicht mal eine Zeile im Lebenslauf, nicht wahr? e.
Das irrst du dich gewaltig Personaler. Man muß sich nicht schlechter machen und bis auf die Knochen ehrlich sein, sondern nur den Ansprüchen genügen, die der zukünftige AG an die zu vergebende Stelle knüpft. Schließlich will man dort ja nicht Teilhaber oder Gesellschafter werden oder können. Aber diese Weisheit wollen einem ja gerade die Personaler erst nach dem Vorstellungsgespräch und der Abgabe seiner Bewerbungsunterlagen vermitteln. Nur dann ist es meist zu spät, und man hat erst mal dazugelernt. Und eine Stellenausschreibung ist in erster Linie an eine fachl. Leistung oder das Können dafür gebunden, aber gewisse Leute haben davon ja weniger Durchblick. Die können und wollen nur den Typen analysieren, um daraus dann seine Fähigkeiten, welche sie nicht fachl. einschätzen können, zu beurteilen. @ Backflow , du solltest eigentlich bemerkt haben, daß ich nicht im Ing.-Bereich tätig bin, und auch meine allgemeinen Aussagen nicht darauf ausrichten kann. Es gibt in E- und ITK-Technik noch eine ganze Palette an Bereichen unter den Ings.! Und selbst der ehemalige "GL" war keiner, und seine Aufgabe war auch an produktive Tätigkeiten gekoppelt, aber auch Arbeitsverteilung (mehrfach täglich) und Auswertung, sowie Korrespondenz mit der nächst höheren Führungsebene (Entgegennahme neuer Aufträge / Angebotsabsprachen). Wenn ich aber deine Einschätzungen fremder Leute (oder deren Leistungen) so lese, zielt die doch grundsätzlich nur in eine Richtung. Auch wenn es nur Andeutungen sind. Kannst du dir eigentl. auch vorstellen, daß es auf der FA-Ebene in einer Gruppe (nicht unbedingt Team) auch sehr verschiedene Alters- sowie Leistungsgruppen gibt? Wenn deine Vermutung zutreffen würde, daß man selbst ständige Kontrolle für seine Tätigkeiten brauche, auf einen solchen MA könnte man doch ganz gut verzichten. Und wenn der mal ebend nicht arbeitsfähig wäre, dann hätte doch der GL eine ganze Menge weniger Streß mit Kontrolle und Anleitung. So denn nicht seine anderen Leute vom selben Kaliber wären, und selbst dann würde durch Abwesenheit Eines, nicht selbstständig handelnden, eher weniger Arbeit auf den GL zukommen. Also doch wieder ohne Zusammenhang und Sinn. Den anderen Fall überlasse ich deiner Fantasie und Vorstellungskraft. Aber Teamwork scheint nicht so deine Aufgabe zu sein, wenn man ständig nur seinen Bereich erledigen muß, und dabei sehr viel freie Hand hat. Und wenn du selbst mal über einen längeren Zeitraum (Tage/Wochen) nicht in der Firma tätig bist, wird das wohl auch nicht so dramatisch für den Ablauf bei euch sein, und dein GL wird die Arbeit von dir dann jemand anderem übertragen, richtig? Und wenn euer GL mal Urlaub macht, oder Krank (AU) ist, wird er auch von irgendjemandem anderen ganz gleichwertig vertreten. Jeder ist erstzbar, aber nur in seiner primitivsten Funktion, jedoch niemals sofort, oder überhaupt persönlich in seinen ganzen kollektiven Eigenschaften. Sonst wären wir wohl alles nur Maschinen und keine Menschen.
Hallo, ich frage mich, wie wohl die Leute, die DrNo beipflichten, reagieren würden, wenn ihnen so ein Praktikant vor die Nase gesetzt würde. Nach 7 Tagen wäre wahrscheinlich auch bei ihnen Feierabend gewesen. Ein 30-jähriger Ing. mit unglücklichem Lebenslauf und Vorerkrankung wird als Praktikant eingestellt. Praktikum ist nicht toll, aber es wäre unter diesen Umständen wieder ein Schritt nach vorne. Doch was passiert: 1.) Statt seine Aufgabe zu erledigen, fängt er an ein funktionierendes System zu verbessern. Ob die Abweichungen vom Standard einen Grund haben weiß er nicht, weil er weder mit dem Verantwortlichen noch mit dessen Krankheitsvertretung spricht. O-Ton: "habe es mir gespart". Mögliche Gründe für die Abweichungen/Fehler wurden von Vorpostern genannt. 2.) Seine Aufgaben fanden in einem Projekt statt. Projekt = Es muss zu einem bestimmten Zeitpunkt abgeliefert werden. Anstatt die gewünschten Funktionen zu implementieren, belehrt er lieber den Chef und klaut ihm die Zeit. 3.) Das ständige Herumreiten auf vermeintlichen Fehlern, lässt seine Kollegen nicht im besten Licht dastehen. Ob die Ungereimtheiten einen Grund haben, kann er nicht beurteilen (siehe 1.). Es bleibt aber bei denen, die nicht komplett im Projekt eingebunden sind, im Gedächtnis hängen, dass die Leistung der anderen irgendwie suboptimal war. 4.) Zwei krasse Ermahnungen (wg. Datenblättern und Frage nach Ergebnissen) von Kollegen werden einfach ignoriert. Wer ein bisschen Berufserfahrung hat weiß, dass solche Rüffel nicht aus dem Nichts kommen. Erst wenn vorsichtige Hinweise nicht wahrgenommen werden, kommt die Breitseite. Rein von der Schilderung her hätte alles noch auf einem Irrtum basieren können. Vielleicht spielte der Nasenfaktor auch eine Rolle oder die Leute waren wirklich alle inkompetent. Doch dann folgen weitere Beiträge. (Und es folgt wieder eine Liste): 1.) DrNo schafft es nicht einmal auf den Punkt zu kommen. Die Beiträge könnten ohne Informationsverlust auf 20% des Umfangs reduziert werden. 2.) Kritische Stimmen werden einfach so lange bequatscht bis ihnen die Puste ausgeht. Für alles, wirklich alles gibt es ein Erklärung. 3.) Er nennt seine Heimatregion und gibt Hinweise auf seinen Ex-Arbeitgeber. Dazu noch die Info, dass der Lebenslauf erklärungsbedürftig ist und er eine Vorerkrankung hat. Wäre es meine Heimatregion gewesen, bräuchte ich wahrscheinlich nur 2-3 Anrufe, um herauszufinden um wen es sich handelt. 4.) Einer aus seiner Region macht ihn höflich auf 4.) aufmerksam. Auch er wird belehrt. 5.) Schafft knapp eine Woche Praktikum, zeigt aber gegenüber Nicht-Akademikern eine krasse Verachtung. Wie kann man Gärtnertätigkeit und 1€-Job in den gleichen Topf schmeißen? Und viel wichtiger: Wie verhält es sich mit den Werkern und "Schraubern" mit denen er zusammen arbeiten muss? Es mag etwas krass klingen, aber ich bete jeden Sonntag Abend dadrum, dass mir am Montag morgen nicht so einer ins Team gesteckt wird. Auf die meisten, die ihm zugestimmt haben, könnte ich wahrscheinlich auch verzichten, denn noch macht mir mein Beruf richtig Spaß. Und den Spaß würde ich nur ungern verlieren.
Ich kenne die Sorte Menschen wie der OP einer zu sein scheint (ich betreute mal einen Praktikanten): kommen in die Firma, haben alles schon gemacht, alles schon gesehen, können alles, und zwar viel besser als alle anderen. Was andere machen ist eh alles Schrott... Mit fünf Jahren BE passt der OP zwar nicht ins Schema, aber die jüngeren Generationen leiden teilweise an krankhafter Selbstüberschätzung und Arroganz, dass einem die Spucke wegbleibt. Wenn solche Leute schon in den ersten Tagen wüten wie der Elefant im Porzellanladen und jedes soziale Gespür vermissen lassen, dann dürfen sie sich nicht wundern, wenn sie nicht gerade mit offenen Armen von den Kollegen aufgenommen werden. Nicht dass ich falsch verstanden werde, aber man sollte einfach nicht gleich am ersten Tag die Daseinsberechtigung einer ganzen Firma am schwarzen Brett kundtun.
aber man sollte einfach nicht gleich am ersten Tag die Daseinsberechtigung einer ganzen Firma am schwarzen Brett in_ _Frage_ _stellen.
>Finde ich nicht. Wenn da Murkser am Werk sind muß man das dem Chef >gegenüber klar und deutlich artikulieren. Ich würde mir niemals anmaßen, das gleich in den ersten Tagen in einer neuen Firma zu beurteilen. Allein dass er dies tut, zeigt die maßlose Selbstüberschätzung und Arroganz. Oft haben die Leute ein derart gestörtes Verhältnis zu ihren eigenen Leistungen, dass sie gar nicht bemerken, dass sie selbst auf der falschen Spur fahren, nach dem Motto: "wieso sagt der Sprecher im Radio, es wäre ein Falschfahrer unterwegs? es sind doch hunderte!"
>Warum nicht. Vielleicht ist es aus wirtschaftlichen Gründen besser die >Firma gleich komplett zu schließen als ewig so weiterzuwurschtelen. Weil er das sicher nicht nach wenigen Tagen in einer neuen Firma beurteilen kann! Von ein paar Quelltextzeilen, die _aus der Sicht des OP_ angeblich "schlecht" sind, auf die Daseinsberechtigung und Organisationsstruktur einer ganze Firma zu schließen, ist Schwachsinn! Sagt mal, wie realitätsfremd seid ihr denn?
Ich wiederhole mich jetzt zum letzten Mal: Er kann das nicht nach wenigen Tagen in einer Firma und wenigen gesichteten Quelltextdateien beurteilen. Punkt! Und selbst wenn es in einer Firma deutliche Defizite geben sollte: Warum sollte man eine Firma dichtmachen, die noch Leute in Lohn und Brot halten kann? Nur, weil die Angestellten nicht sklavisch der reinen Lehre der Softewareentwicklung folgen und damit die Daseinsberechtigung der Firma automatsich erlischt. <kopfschüttel>
@ Die Stimme der Vernunft (Gast) >Aber gesetzt den Fall daß es sich dabei wirklich um eine Murks-Firma >handelt. Wäre es dann nicht besser die Geschäftstätigkeit einzustellen >bevor es zu einer Insolvenz kommt? Nöö. Das Zauberwort lautet Psychiologie. Recht haben und Recht bekommen sind zwei verschiedene Paar Schuhe. Und auf der psychiologischen Schiene hatten beide Parteien deutliche Defizite. Beitrag "Re: Riesenstress mit C-Programmierung und Chef" MfG Falk
@ Gast1 (Gast) >Ich wiederhole mich jetzt zum letzten Mal: Er kann das nicht nach >wenigen Tagen in einer Firma und wenigen gesichteten Quelltextdateien >beurteilen. Punkt! Ja. Doppelpunkt. Aber er muss nach wenigen Tagen an diesem Murks weiterarbeiten. Und das IST ein Problem, so oder so. Räumt er auf, wird gemeckert. Räumt er nicht auf und verzettlet sich später, wird gemeckert. :-0 >Und selbst wenn es in einer Firma deutliche Defizite geben sollte: Warum >sollte man eine Firma dichtmachen, die noch Leute in Lohn und Brot >halten kann? Hat keiner wirklich gefordert. Und wer die Praxis kennt weiß, wie lange sich Provisorien und Murks halten. Wie Unkraut, nahezu ewig ;-) Nichts desto trotz hatte der OP die Arschkarte. Mit mehr Geschick und psychiologischem Wissen hätte er Stress vermieden. Langfristig wäre das aber wahrscheinlich nix geworden. C'est la vie. MFG Falk
Macht das für die Angestellten einen Unterschied, ob sie aufgrund von Insolvenz oder Geschäftsaufgabe arbeitslos werden? Das Produkt hat funktioniert. Der Kunde ist zufrieden, wenn Programm all das macht wofür er bezahlt hat. Und da der OP keinen Kundenkontakt hatte, ist es müßig dadrüber zu spekulieren, ob das Unternehmen eine Berechtigung am Markt hat. Nebenbei: Es gibt es eine Vielzahl von Firmen, die an (Code-)Schönheit gestorben sind. Schöne Code-Basis bringt nichts, wenn die Funktionalität nicht gegeben ist.
Falk Brunner schrieb: > Nichts desto trotz hatte der OP die Arschkarte. Mit mehr Geschick und > psychiologischem Wissen hätte er Stress vermieden. Langfristig wäre das > aber wahrscheinlich nix geworden. C'est la vie. Alles Vermutungen. Und: Muss es denn unbedingt langfristig sein? Hätte ja auch so laufen können: Gute Arbeitsleistungen, Übernahme, 3 Jahre echte BE, gutes Arbeitszeugnis und schon sieht die Ing.-Welt ganz anders aus. Stattdessen wichtig machen und wieder Arbeitslosigkeit.
@ Klaus (Gast) >Alles Vermutungen. Und: >Muss es denn unbedingt langfristig sein? Unter langfristig verstehe ich hier >1 Monat. Und damit ist die Antwort JA! >Hätte ja auch so laufen können: Gute Arbeitsleistungen, Übernahme, 3 >Jahre echte BE, gutes Arbeitszeugnis und schon sieht die Ing.-Welt ganz >anders aus. Siehe oben: Alles Vermutungen. > Stattdessen wichtig machen und wieder Arbeitslosigkeit. Dumm gelaufen. Beim nächten Mal weiß er es besser. Und hat hoffentlich mehr Glück mit deinem Arbeitgeber. MFG Falk
Also was dieser Klaus (Gast) am 05.04. von sich gegeben hat, ist schon starker Tobak. Ist wohl aus dem selben Holz geschnitzt wie dieser Ex-Chef von Dr. No. Der Fisch fängt bekanntlich im Kopf an zu stinken. Würde mich bei dem autoritären Führungsstil nicht wundern wenn in der Firma eine hohe Mitarbeiterfluktuation bestünde.
Thomas K. schrieb: > Du kommst mit OOP oder > vielleicht alle Warnungen als Errors zu interpretieren und das löst bei > alten Hasen Panik aus, weil das alles neumodischer Kram ist den niemand > braucht... Das ergibt keinen Sinn. Und überhaupt: Ein Styleguide ist das Mindeste und hoffentlich ist ein Styleguide nicht das Ende der Fahnenstange. Systematische Tests und Verifikation sind wichtig und da hapert leider auch. Klaus schrieb: > h frage mich, wie wohl die Leute, die DrNo beipflichten, reagieren > würden, wenn ihnen so ein Praktikant vor die Nase gesetzt würde. Nach 7 > Tagen wäre wahrscheinlich auch bei ihnen Feierabend gewesen. Warum? Ich finde kritische Stimmen immer gut. Ich kann viel weniger die Leute ab, ihre beschränkte Sicht der Dinge zum Non-Plus-Ultra aufblasen, weil sie "Erfahrung" haben. Erfahrung worin? Software sch**ße implementieren, die dann trotzdem irgendwann und irgendwie funktioniert? Wichtig ist meiner Meinung nach, über den Tellerrand zu schauen, zu lesen, was sich in der Wissenschaft tut. Wenn ich so mit Kollegen rede, dann sage ich auch gerne, dass in der Wirtschaft schlechte Programmiersprachen gewählt werden. So bietet C/C++ extrem viele Fallstricke. Was erhalte ich als Antwort? Das haben die Entwickler gelernt. Oder nehmen wir Java. Java war schon altbacken, als es auf die Welt kam. Es wurde und wird gecastet, was natürlich auch wieder extrem fehleranfällig ist. Ich befürworte funktionale Programmiersprachen für den eigentlichen algorithmischen Teil einer Anwendung. Gegenargumente: "Es gibt nicht diese oder jene Guibibliothek für Scala." Scala nenne ich hier beispielhaft, weil es eine sehr gute Sprache ist. Und auch noch auf der JVM läuft und bestehender Java-Code transparent weitergenutzt werden kann. Ich habe es in meinem Beruf mit vielen Leuten zu tun, die kein großes Interesse an ihrer Arbeit und akademischen Disziplin haben.
DrNo, ich hoffe Du ließt noch mit; zu bemerken ist, dass ich mir die anderen Beiträge nicht durchgelesen hab'. Dieses Szenario ist typisch für unsere Wirtschaftsstruktur und auch kennzeichnend für diesen Typ Menschen ansich. Du scheinst gewissenhaft zu sein, vielleicht gar ein Idealist, scheinbar auch mit Tendenzen zum Perfektionismus - auf jeden Fall an eher einem Ideal, als denn dem puren Ergebnis orientiert. Glückwunsch! Das macht Dich zu einer Person, die von diesem kleinen Teil gleichdenkenden Elite geachtet wird - Du musst Dir vor Augen halten, dass Leute wie z.B. dieser Arbeitgeber nichtswerter Abschaum sind, welche nie auf schätzenswerter Ebene höheres Erreichen, etwas bemerkenswertes Erschaffen. In der freien, rein gewinnorientierten Wirtschaft wirst Du es schwer haben, Du wirst Dich verändern und einschränken müssen und einfach funktionieren wie man es von Dir erwartet, Arschkriechen und falsche Selbstkritik inklusive, Du musst Dir in den Arsch ficken lassen und auch noch so tun als würdest Du es lieben - kurzum, Du musst Dich brechen lassen! Oder Du scheißt auf diese Idioten und das was diese Gesellschaft prägt. ...ganz Praktisch kann ich Dir zu Jobs in der Forschung, möglichst weit weg von der Wirtschaft, raten (d.h. z.B. auf keine Fall Frauenhofer!, eher etwas in Richtug PTB, Desy, Uni, ...) - da laufen die Uhren bekannter Weise anders - kein Leistungsstress in dieser Form; Wissen, gewissenhafte Ausführung und Grundsatztreue genau wie Ehrgeiz sein Wissen zu erweitern werden geschätzt, Produktivität - auf Teufel komm' raus - ist nicht die oberste Devise - auch muss man keinen Kunden in den Arsch kriechen und kann auch kritische Kommentare ungeschöhnt äußern, ohne abgesägt zu werden. Ja, oftmals trifft man gar auf eine flache Hierarchie und die fachlichen Beziehungen beruhen nicht auf bestimmten Positionen, sondern auf Fähigkeiten und Wissen - auch findet eine tatsäche Kooperation statt, eine äußerst fruchtbare und konstruktive Atmosphäre, weil alle ein gemeinsames Ziel verfolgen, nicht ihre Zeit absitzen und auf Wochenenden und Gehaltszahlungen warten, um in den 'Urlaub' zu flüchten... Bevor ich eine solche Stellung fand, aus der ich inzwischen viel Kraft ziehe und in der Vergangenheit genug Kraft zog, selbst eine Akademikerlaufbahn einzuschlagen - um nie wieder anderen Bedingungen ausgesetzt zu sein - quälte ich mich ähnlich wie Du, litt an schweren (behandlungsresistenten - durch die Umgebungsbedingungen hervorgerufenen) Depressionen und stand sehr, sehr kurz vor einem ernsthaften Suizidversuch (nicht die Art, die einen Hilfeschrei darstellt - sondern die Art, die rational abgewägt einen Ausweg aus einer unerträglichen und verzweifelten Situation darstellt). Zu dieser Zeit hab' ich kaum einen Ausweg gesehen, vor allem, da ich meine Kräfte nicht mehr wirklich mobilisieren konnte. Die Rechnungen türmten sich und ich war arbeitsunfähig/unwillig... es war ein harter Weg und sicherlich auch Glück, dass ich ein so wunderbares Umfeld fand - und das wünsche ich auch Dir! Wenn Du in meinem Text Deine eigene Situation und Denkweise wiedererkennst, rate ich Dir: halte Dich fern von der Wirtschaft! Geh' in ruhigere, aber wesentlich wichtigere und gar erfüllende Gefilde, gehe in richtung wissenschaftlicher Grundlagenforschung!
Big Game James schrieb: > Warum? Ich finde kritische Stimmen immer gut. Ich kann viel weniger die > Leute ab, ihre beschränkte Sicht der Dinge zum Non-Plus-Ultra aufblasen, > weil sie "Erfahrung" haben. Erfahrung worin? Software sch**ße > implementieren, die dann trotzdem irgendwann und irgendwie funktioniert? Sehe ich genauso. Ich lerne auch immer gerne dazu, auch von Praktikanten, wenn die mal etwas Neues anbringen. Wenn man Beiträge wie die von "Klaus" liest, denkt man automatisch an "Hackordnung" und nicht an Team.
Ich habe ein spezielles Interessensgebiet innerhalb der Informatik und es ist ein wichtiges Thema, nämlich wie man Softwaresysteme möglichst gut entwickeln kann. Und es ist sogar noch ein wirtschaftsnahes Thema, weil man in der Wirtschaft mit möglichst wenig Aufwand die Ziel möglichst schnell erreichen will. Nun tut sich da einiges in der Forschung, was Verifikation, Model Checking, Softwaretest usw. betrifft. Meine Erfahrung ist: Das lässt man alles links liegen. Mir wird immer wieder vorgehalten, man müsse möglichst schnell Ergebnisse erzielen. Moderne Verfahren und Forschungsergebnisse dienten der "Ästhetik", ohne dass es dem Kunden nutzt. Von wegen. Natürlich muss man etwas investieren, um z. B. neue Programmiersprachen, Methoden usw. zu erlernen. Komischerweise ist für jeden Methoden-Quacksalber und "Guru" Geld da. Was nützen mir RUP, CMMI oder Scrum? Man hat nur Erfahrungswerte, ob etwas gut funktioniert oder nicht. Ein gutes Vorgehensmodell ist wichtig, aber es ist nicht der Heilsbringer. Das ist vergleichbar mit Basketball, wenn die Spieler einer Mannschaft in jedem Jahr eine neuen Blödsinn lernen, aber es verpasst wurde, dass die Spieler einen vernünftigen Sprungwurf erlernen. Der Sprungwurf ist seriös, man nimmt ihn kaum wahr... in Spielzusammenfassungen zeigt man dann Dunkings. Dabei werden wahrscheinlich mehr als 70% aller Punkte durch Sprungwürfe erzielt, wenn man davon ausgeht, dass 10 bis 15 % der Punkte durch Freiwürfe erzielt werden. Und da hapert es auch in der Wirtschaft, indem man einfach die Fundamente vernachlässigt werden. Vor ein paar Jahren wurde Ajax propagiert, jetzt sind es Ruby on Rails und Grails. Viele Unternehmen würde stärker davon profitieren, wenn gewisse Fundamente da wären. Um bestimmte Performanzprobleme in den Griff zu bekommen, braucht man theoretische Informatik. Um Effekte in Datenbanken zu verstehen, wirkt das Wissen über Bäume wie ein Katalysator. Ich habe auch einen Kollegen, der propagiert ohne Scham: Das meiste sei Copy & Paste. Kopieren und Anpassen. Ich sagte ihm, es sei besser, wenn dann an dieser Stelle die gemeinsamen Teile gemeinsam nutzen würde... Weniger Code, weniger Fehler. Das geht in das eine Ohr rein, aus dem anderen Ohr wieder aus.
Hallo Leute, also ich muss nochmal ein paar Worte zum Thema verlieren: man darf etwaige verkrustete Strukturen und, sagen wir es vorsichtig, zu selbstbewusste Praktikanten nicht in einen Topf werfen: Ich bin selbst noch "relativ jung", und kenne die Probleme, die sich ergeben können, wenn man in einer Firma Veränderungen umsetzen möchte. Das hat allerdings nichts damit zu tun, dass ein arroganter, sich selbst überschätzender Praktikant sich verhält, als wäre für ihn sowieso alles ein Klacks, und das, was in der Firma entwickelt wird, wäre sowieso alles kalter Kaffee. Glaubt's mir bitte, ich bin wirklich gutmütig und für neue Ideen sehr aufgeschlossen. Wenn dann allerdings so ein Praktikant kommt und sich aufführt wie ein Arroganzbolzen, dann kann es schon mal passieren, dass man Grenzen aufzeigen muss. Leute, arbeitet doch mal mit heute Zwanzigjährigen zusammen. Ihr werdet teilweise euer blaues Wunder erleben. Die Selbstüberschätzung (man könnte es auch Überheblichkeit nennen) kennt stellenweise keine Grenzen.
Big Game James schrieb: > Warum? Ich finde kritische Stimmen immer gut. Ich kann viel weniger die > Leute ab, ihre beschränkte Sicht der Dinge zum Non-Plus-Ultra aufblasen, > weil sie "Erfahrung" haben. Erfahrung worin? Software sch**ße > implementieren, die dann trotzdem irgendwann und irgendwie funktioniert? > Wichtig ist meiner Meinung nach, über den Tellerrand zu schauen, zu > lesen, was sich in der Wissenschaft tut. Kritische Stimmen sind wichtig. Entscheidend ist dabei nicht eine firmeninterne Hackordnung sondern die Art und Weise wie man diesen Input einbringt. Zwei Zitate aus den ersten beiden Posts: DrNo schrieb: > Die Kollegen sagten mir jedoch, dass der Code nach einer > firmeninternen Codierungsrichtlinie erstellt worden wäre. Diese wäre > verbindlich und dürfe nicht variiert werden, weil die Steuerungsgeräte > später in Bereichen wie etwa der Bergbau- und Bahntechnik eingesetzt > würden, in den die funktionale Sicherheit garantiert werden müsse. DrNo schrieb: > Als Vertretung wurde dann der Kollege beauftragt, der beanstandet hatte, > dass ich ein Datenblatt lese. Der war so unfreundlich, dass ich mich > entschieden hatte, mit dem gar nicht mehr zu reden. Es gibt eine Codierungsrichtlinie, die zum Teil für die schlechte Implementierung verantwortlich ist. Ob die Richtlinie schlecht oder veraltet ist oder ob sie Besonderheiten des Kunden oder Branche berücksichtigen muss, kann DrNo nicht beurteilen weil er mit seinen Kollegen bewusst nicht redet. Er ist neu und redet nach wenigen Tagen nicht mehr mit seinen Kollegen! Er stellt damit keine kritische Stimme mehr dar, sondern eine destruktive.
@ Big Game James: Willkommen zurück Onkel Kapott, ...
@ arno nyhm (Gast) >In der freien, rein gewinnorientierten Wirtschaft wirst Du es schwer >haben, Du wirst Dich verändern und einschränken müssen Ja. >und einfach >funktionieren wie man es von Dir erwartet, Arschkriechen und falsche >Selbstkritik inklusive, Du musst Dir in den Arsch ficken lassen und auch >noch so tun als würdest Du es lieben - kurzum, Du musst Dich brechen >lassen! Selten so einen Unsinn gelesen. Zuviel "Full Metal Jacket" gesehn? Der Op muss was lernen, hab ich schonmal geschrieben. Beitrag "Re: Riesenstress mit C-Programmierung und Chef" Das heißt NICHT; dass er zum Arschkriecher werden soll oder muss! Das heißt, dass er lernen muss, gewisse komische Umstände zu akzeptieren und sich nicht in realitätsfremden Idealsimus flüchten darf. Der Chef will die schnelle Murkslösung? Ok, er bekommt sie! Aber wenn es dann knallt, soll er bitteschön dafür gerade stehen. Ja, das ist nicht einfach und bedarf einiges an Erfahrung und Wissen. Politischem Wissen. Denn wenns knallt will man meist fix den schwarzen Peter den kleinen Indianern zuschieben. Davor muss man sich schützen. Durch Unterschriften auf Dokumenten, Emails, verschiedene andere Sachen. Ausserdem muss der OP lernen, das alles nicht so bierernst zu nehmen. Und eben halt das taktische Gespür entwickeln. Schrieb ich bereits. Das alles geht nicht von heute auf morgen, schon klar. Und auch in diesem Lernprozess wird es Rückschläge geben. Aber am Ende ist man gestählt, lässt sich durch den ganzen Unsinn nicht aus der Ruhe bringen, macht sein Ding und ist am Ende nicht gestresst. Auch wenn man dabei nicht immer seinen eigenen, idealen Qualitätsstandard umsetzen kann. Und last but not least, nicht jede Bude und jeder Chef ist so irre wie der OP beschrieben hat. Im Ernstfall sucht man sich einen anderen Laden! Alles Dutzendfach einfacher und besser als zum Psychowrack zu werden! > Oder Du scheißt auf diese Idioten und das was diese Gesellschaft > prägt. >...ganz Praktisch kann ich Dir zu Jobs in der Forschung, möglichst weit >weg von der Wirtschaft, raten Die Insel der Glückseligkeit? Selbst wenn es dort so ist, der Mensch, so er möglichst stressarm leben will und dennoch halbwegs sich in der nichtidealen Realität bewegen will, muss vor allem lernen, wie der Hase läuft. Siehe oben. Als unbeweglicher Idealist wirst du immer nur Stress haben. Sinnlos! >Zu dieser Zeit hab' ich kaum einen Ausweg gesehen, vor allem, da ich >meine Kräfte nicht mehr wirklich mobilisieren konnte. Schlecht. Aber nicht das Thema. >wiedererkennst, rate ich Dir: halte Dich fern von der Wirtschaft! Ob das so ein guter Rat ist? > Geh' >in ruhigere, aber wesentlich wichtigere und gar erfüllende Gefilde, gehe >in richtung wissenschaftlicher Grundlagenforschung! Wer dagt denn, dass der OP das a) will und b) kann? Als "normaler Softwareentwickler" ist man meist eher in der Industrie als in der Forschung zu finden. MfG Falk
Falk Brunner schrieb: >Ja, das ist nicht einfach und bedarf einiges an Erfahrung >und Wissen. Politischem Wissen. Denn wenns knallt will man >meist fix den schwarzen Peter den kleinen Indianern >zuschieben. Davor muss man sich schützen. >Durch Unterschriften auf Dokumenten, Emails, verschiedene >andere Sachen. Richtig. Ich kannte da einen Mann in meiner ehemaligen Firma, der sowohl seine Aufgaben excellent machte, als auch ein umgänglicher Typ war. Eine Koryphäe in Naturwissenschaften mit Doktor-Titel. Manchmal flippte er regelrecht über die aalglatten abgecheckten Typen in der Firma aus, die sich an keine Absprachen und Abmachungen hielten. In einem persönlichen Gespräch, als ich selbst mal einen Anschiß erhielt, meinte er zu mir: Ich lasse mir mittlerweile nachträglich mindestens intern von Telefonpartnern sogar den Gesprächsinhalt per Mail schriftlich bestätigen, damit ich nicht das Wort im Munde herum gedreht bekomme. Booooaaah, was für ein Arbeitsklima! Eher Kleinkriege? Ist das heute so üblich? Der Mann wurde einige Zeit nach mir aber auch gekündigt, wie ich später erfuhr. Seine Vorgehensweise scheint ihm nicht zuträglich gewesen zu sein.
@ Wilhelm (Gast) >Manchmal flippte er regelrecht über die aalglatten abgecheckten Typen in >der Firma aus, die sich an keine Absprachen und Abmachungen hielten. Tja, dumm gelaufen. >Booooaaah, was für ein Arbeitsklima! Eher Kleinkriege? Ist das heute so >üblich? Nicht überall!! Aber oft. >Der Mann wurde einige Zeit nach mir aber auch gekündigt, wie ich später >erfuhr. Seine Vorgehensweise scheint ihm nicht zuträglich gewesen zu >sein. Zu rauh für die aalglatten Typen :-( Naja, in solchen Situationen ist am Ende kein Blumentopf zu gewinnen. Es gibt manchmal Steine auf dem Lebensweg, um die muss man herumlaufen, auch wenns ne Weile dauert. Aber mit dem Kopf durch ist deutlich ungesünder. Siehe den Herrn arno nyhm & Co. MFG Falk
Und wieso werden hier wieder ganze Postings ohne Hinweis gelöscht, so
daß dann folgende überhaupt keinen Sinn oder Zusammenhang ergeben?
Siehe Personaler vor meinem Posting, einfach weggelöscht - Danke Admin.
Den Grund dafür frage ich erst lieber gar nicht nach - kann man wohl aus
meinem folgenden Text erraten.
@ Wilhelm
> Seine Vorgehensweise scheint ihm nicht zuträglich gewesen zu sein.
Da verwechselst du etwas ganz Entscheidendes, es ist aber auch nur ein
Wortspiel, diese Vorgehensweise deines Kollegen war ihm ganz sicher sehr
zuträglich - nur nicht seinen aalglatten Widersachern.
Doch die werden aus ihren eigenen Fehlentscheidungen auch gewisse Lehren
haben ziehen müssen - garantiert.
Wilhelm schrieb: > Ich lasse mir mittlerweile nachträglich > mindestens intern von Telefonpartnern sogar den Gesprächsinhalt per Mail > schriftlich bestätigen, damit ich nicht das Wort im Munde herum gedreht > bekomme. > > Booooaaah, was für ein Arbeitsklima! Eher Kleinkriege? Ist das heute so > üblich? Leider oftmals notwendig - gibt auch die Variante, daß man ein Gesprächsprotokoll führt u. allen Beteiligten zukommen lässt. Besprechungen sind ohne schriftliche Dokumentation heutzutage leider nichts mehr wert - das gesprochene Wort zählt heutzutage nichts mehr. Gast1 schrieb: > Leute, arbeitet > doch mal mit heute Zwanzigjährigen zusammen. Ihr werdet teilweise euer > blaues Wunder erleben. Die Selbstüberschätzung (man könnte es auch > Überheblichkeit nennen) kennt stellenweise keine Grenzen. Der großen Klappe folgen dann sehr mickrige Taten - meist von jenen, die die "absoluten Helden" sind, aber bei fast keinem AG die Probezeit beenden können. Obwohl es leider immer mehr von der Sorte Quatschköpfe gibt, ist der Großteil der "Jungen" immer noch von der normalen Sorte, die ambitioniert, lernbereit u. kooperativ sind. Glücklicherweise komme ich viel mit dem berufl. Nachwuchs in Kontakt, habe meine Freude in der Zusammenarbeit/Förderung derselben u. die meisten Dampfplauderer lassen sich auf Kurs bringen.
Schönen guten Tach... ich les ja auch manchmal hier im Forum, aber dass ich jemals einen Bericht finden würde, in dem ich selber vorkomme, hätte ich nicht gedacht. Ich hatte schon bei Deinem Aufenthalt bei uns drüber nachgedacht, ob man mal ein paar Punkte mit Dir ansprechen sollte. Es gibt ja bei jedem Menschen ein Selbstbild und ein Fremdbild. Wenn es gut läuft, dann stimmen die überein. Wenn es schlecht läuft, dann wissen beide voneinander so gut wie gar nichts. Wenn ich längere Zeit arbeitslos war und in eine Firma komme, dort etwas bewegen will etcpp... dann würde ich Folgendes tun: - die gestellte Aufgabe möglichst nicht anzweifeln - vor allem wenn mehrfach deutlich gesagt wird, dass der Code nicht perfekt ist - aber auch gar nicht sein muss, weil die SW für einen untergeordneten Produktionstest ist. SW für Kunden sieht bei uns durchaus anders aus... - die Aufgaben möglichst schnell umsetzen und zum Ansprechpartner rennen und sagen: "Guck mal, schon fertig". - Wenn dann noch Zeit ist, kann man gerne Warnungen aus dem Code entfernen und schön dokumentieren und einrücken und... (das sollte man durchaus auch nebenbei bei seinem Ansprechpartner erwähnen) - mit den Kollegen reden - mehr als das unbedingt Notwendige, so dass die anderen wenigstens den Eindruck haben, man wäre an Teamwork interessiert - sich nicht gleich mit jedem anlegen und möglichst nicht bei den ersten Problemen einen Termin mit dem Firmeninhaber einfordern - und noch einiges mehr Man kann natürlich auch in jedem Gespräch und mit jeder Aktion allen anderen das Gefühl geben, dass man es selbst sowieso viel besser kann... Wenn man dann nach einem ersten kritischen Gespräch immer noch nicht die Kurve kriegt, dann geht ein Praktikum auch mal nach 7 Tagen zu Ende. Leider muss nämlich mit aller Arbeit irgendwann auch mal Geld verdient werden. Wenn nach 7 Tagen von 5 mehr oder weniger kleinen Aufgaben immer noch 0% gelöst sind, dann wird es eng... Stattdessen wurde ne neue Entwicklungsumgebung installiert und was weiß ich noch nicht alles gemacht. Meine ehrliche Meinung, auch wenn ich nicht bei uns arbeiten würde: So wird das für Dich auch anderswo schwer... Gruß und trotzdem Viel Erfolg bei der weiteren Arbeitssuche!
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.