Hallo, ich habe vor kurzen dem Job gewechselt. Im alten Job war ich 5 Jahre in Forschung&Entwicklung. Außer mir gab es keine Programmierer oder Leute mit Programiererfahrung. Ich habe hauptsächlich Kameras in Betrieb genommen bzw. Bildverarbeitung mittels OpenCL realisiert und dazu C/C++ Programme geschrieben. Als Oberfläche kam Qt zum Einsatz. Ich hab gewechselt damit ich nicht ständig im eigenen Saft koche. Meine Programmierkenntnisse sind was C betrifft sind relativ gut (hab technische Informatik studiert). C++ mittelmäßig. Templates/Makros kenn ich, hab ich aber kaum verwendet. Java ist ok. Hab nebenbei Der neue Job ist eine reine Softwarefirma. Meine Aufgabe ist eine Protokollumsetzung in C++. Als Vorlage dienen Quellen in Objective-C. (Bzw. ist auch eine Implementierung in Java/C# vorhanden.) Diese sind gespickt mit Templates, Makros, neusten Compiler-Direktiven und kurzen Variablennamen. Doku ist keine vorhanden, sprich durch den Code hangeln. Wenn ich mir den Quellcode an manchen Stelle anschaue hab ich keine Ahnung was der tut. Den Entwickler kann ich natürlich um Hilfe bitten, allerdings ja auch nicht ständig. Um die das Protokoll von Grund auf neu zu Schreiben fehlt mir die Erfahrung bzw. einfach die Zeit. Ich komm mir im Moment echt blöd vor. Frage mich halt ob es an mir liegt oder ob es anderen ähnlich gehen würde. Wie würdet ihr weiter vorgehen? Gespräch suchen mit Chef? Anderen Job suchen? Danke für eure Hilfe.
Nachtrag zu Java: Hab nebenbei mal kleine Sachen für Android programmiert. Keine riesigen Frameworks, nur kleinere Sachen wie Sensoren auswerten usw.
besorg dir ein gutes c++ buch, z.b. "der c++ programmierer". templates zu verstehen ist wichtig, wenn du c++ anwenden willst. der rest ist übung. sprich: sieh es als herausvorderung und nutze die zeit, dich weiterzubilden. dann wird das schon.
vic schrieb: > Diese sind gespickt mit > Templates, Makros, neusten Compiler-Direktiven und kurzen > Variablennamen. Doku ist keine vorhanden, sprich durch den Code hangeln. Ich denke, die Templates, Makros und neusten Compiler-Direktiven musst Du lernen. Alles andere ist ein Problem, das nichts mit Dir zu tun hat. Frag' mal Deinen Chef, ob Zeit ist, dass Du eine ordentliche Dokumantation machst, sonst hat der Nachfolger wieder das gleiche Problem. Falls ja: Dann fällt es vllt. auch leichter, den Entwickler zu fragen? Falls der ursprüngliche Programmierern noch in der Firma ist: Glück gehabt! Andere haben's schwerer.
:
Bearbeitet durch User
Ich denke auch dir fehlt einfach die Übung und das Auge dafür den Code schneller zu überblicken und zu verstehen. Einfach nach Arbeitsende und an WEs für ein paar Wochen dir Bücher dazu lesen und vorallem Testprogramme schreiben dann wird das schon.
vic schrieb: > Doku ist keine vorhanden, sprich durch den Code hangeln. Was dann auch wieder deine Zeit kostet, wofür dein Chef sicher kein Verständnis haben wird. > Wenn ich mir den Quellcode an manchen Stelle anschaue hab ich keine > Ahnung was der tut. Wenn das ganze ordentlich dokumentiert wäre, sähe es wahrscheinlich anders aus. Manchen machen das aus Zeitmangel nicht und andere weil sie sich damit unverzichtbar machen wollen, was natürlich nicht geht. > Den Entwickler kann ich natürlich um Hilfe bitten, > allerdings ja auch nicht ständig. Der soll erst mal die Suppe, die er da angerichtet hat, selbst auslöffeln. Da gibts gar keine Ausrede. Klar würde ich mit dem Chef reden und darum bitten das der Entwickler sich da mal von seinen sonstigen Aufgaben freimacht und das ganze, am besten mit deiner Hilfe alles dokumentiert und durchgeht. Je ausführlicher, umso besser. Wenn der Entwickler nämlich mal selbst die Bude verlässt, hat die Firma nämlich ein Problem, wenn die alte Software weiter Bestand haben soll. Wenn man Schaltungen entwirft, muss man ja auch Schaltpläne und Funktionsbeschreibungen erstellen. Ich erahne, dass das der Chef und der Entwickler auch genau wissen und du deshalb eingestellt wurdest, um das Problem zu lösen. Allerdings ist das auch eine Frage der Erfahrung und wenn auf dem Arbeitsmarkt keine Erfahrenen zu bekommen waren, die sich damit in der Tiefe auskennen und den erst Besten genommen haben, hast du natürlich erst mal die A-karte gezogen, d.h. du wirst immer schuld sein. Ich weiß nicht, was man dir da sonst noch raten soll, aber wenn du da nicht kräftig unterstützt wirst, dann fang schon mal zum Ende der Probezeit (sofern es überhaupt eine gibt) an zu zittern. Ist schon klar, das die Stellenausschreibung und die Realität oft ganz anders sind und das die Firma das dann auch selbst verschuldet hat, aber entweder lernen die daraus oder auch nicht. Bei der nächsten Firma wirst du hoffentlich aus dieser Erfahrung gelernt haben und lässt dir mal einen vorbefasslichen Eindruck in die Dokumentation geben, bevor du einen Vertrag unterschreibst.
vic schrieb: > Ich komm mir im Moment echt blöd vor. Frage mich halt ob es an mir liegt > oder ob es anderen ähnlich gehen würde. > Wie würdet ihr weiter vorgehen? Gespräch suchen mit Chef? Anderen Job > suchen? Mimimi? Du wurdest doch für diese Tätigkeit angestelltund Einarbeitung gehört nunmal dazu. Nutze die Arbeitszeit, dich einzuarbeiten und dann loszulegen. Bei Fragen den Ersteller nerven. Falls es dem Chef zu langsam geht, kannste ihm durch die Blume erklären, dass du dich da erstmal in den undokumentierten Code reinwühlen musst.
In ein gewachsenes Sauerkraut-Programm einzuarbeiten ist immer schwerer als selbst was auszudenken. Fragen ist keine Schande, sondern eher ein Zeichen, daß man Interesse hat. Schlimm ist nur, wenn man 3x das Gleiche fragt! Lass Dir die Doku zu diesem Machwerk geben oder vervollständige diese (solange Du den Entwickler NOCH fragen kannst)! Er könnte morgen schon verschwunden sein. Dann helfen evtl. nur noch Testpunkte im Programm um ihm langsam auf die Schliche zu kommen wenn die Doku zu schlecht ist. XP hat über 500 Patche. Erfahrungsgemäß wird ständig etwas verbessert, was dann in der Doku (noch???) nicht aktualisiert wurde. Deshalb ist eine Frage keine Schande.
Die Quellcode die du bekommen hast ist nicht dokumentiert. Dann ist sie - wahrscheinlich auch sehr schlecht getested. Also fang damit an fuer die Sachen die du machst auch gleich testen zu schreiben. Auf fuer die empfangen Quellcode. Dann wirst du sehen das es viele bugs darein sein, und damit kannst du auch der Chef deutlich machen das die Code wahrscheinlich besser neu geschrieben kann werden. Und noch einen tip - Auch wenn du die Plannung hast jetzt schon andere Arbeit zu suchen, dann wirst du (nehme ich an) sowieso noch einige Monate dafuer brauchen. Benutze die Monaten. Grusz Patrick
Vill. siehst du im Moment nur den Berg an Arbeit. Du musst ja nicht versuchen alles auf einmal zu verstehen. Auch wenn du gut programmieren kannst wird keiner verlangen können, dass du ein großes Softwareprojekt verstehst wenn du dir 2 Stunden den Code anschaust.
Wieso portiert das nicht der, der das Verbrochen hat? Der kennt wenigstens den Code. Hier jemand Fremden hinzusetzen ist ja das allerdümmste was man machen kann, vor allem wenn keine Doku vorhanden ist. Ineffizienter gehts wirklich nicht mehr. Nerv den Typ ohne Ende der das verbrochen hat, was anderes bleibt dir sowieso nicht übrig, dann merken sie hoffentlich nebenbei, dass er die bessere Wahl für diese Aufgabe ist und er bekommt es aufgehalst. Da haste ja echt die dreifache Arschkarte mit braunem Rand gezogen. War die Stelle auch so ausgeschrieben? Ich vermute nicht, sonst hätte sich keiner darauf beworben.
Hallo Leute, danke für eure Antworten. Es ist nicht so, dass ich nur rumningeln will. Ich möchte nur gern wissen wie andere das sehen. Das man sich einarbeiten muss ist mir klar und ich bin auch bereit dazu. Ich hielt ich es für besser Leute mit Erfahrung in der Hinsicht zu fragen. ;) Die Aufgabe scheint schon länger rumzugeistern und mein eigentliches Projekt ist noch nicht da. Vieles läuft informell. Die Implementierungen in den andren Sprachen versteh ich so halbwegs und mit bisschen Zeit würde ich das hinbekommen (wenn auch nicht so elegant). Allerdings ist die jetzige Vorlage von jemanden entwickelt welcher ein absoluter Guru in C++ ist. Schon alleine dahinter zu steigen was gemacht wurde, würde viel Zeit verschlingen. Noch dazu gibt es in der Implementierung viele Nebenschauplätze welche zwar schön sind um sich auszutoben und mit Sicherheit elegant gelöst wurden, die aber mit der eigentlichen Aufgabe nicht viel zu tun haben bzw. die man einfacher abhandeln kann. Die Frage ist: - durchbeissen - durchbeissen und vorher Boss bescheid sagen - andere Aufgabe vom Boss beziehen - was andres suchen (wobei ich hier evtl. noch paar Optionen hätte, allerdings auch nicht ewig)
Ging mir nach meinem letzten Jobwechsel ähnlich: 10 Jahre altes, riesiges Java-Webprojekt, bei dem sich niemand die Mühe gemacht hat, über die Jahre hinweg immer mal wieder zu konsolidieren. Stattdessen wurden nur Teilbereiche erneuert, aber alte Strukturen, Stile und Biliotheken beibehalten. Als Einsteiger in das Projekt (mit vorheriger Berufserfahrung) sieht man den Wald vor lauter Bäumen oft nicht und fragt sich, wer diesen Mist verbockt hat. Unendlich umständliche XML-Konfigurationen an stellen, wo niemand die Konfigurierbarkeit gebraucht hätte. Dokumentation? Fehlanzeige. Steht doch alles im Code! Testabedeckung? Gleich null. Man will damit anfangen - irgendwas in Richtung Clean-Code einzuführen, aber der Kunde wäre nicht bereit dafür zu zahlen. Es würde ihm erstmal keinen Vorteil bringen. UX und Usability? Das spielt keine Rolle. Solange Business die eine Auswertungsseite hübsch bekommt und bloß die restlichen, niederen Anwender total ineffizent arbeiten müssen, ist es im Rahmen. Das hilft nur, sich durchzubeißen oder sich doch nach einem anderen Job umzusehen.
vic schrieb: > Doku ist keine vorhanden, sprich durch den Code hangeln. > Wenn ich mir den Quellcode an manchen Stelle anschaue hab ich keine > Ahnung was der tut. Ist wieder mal typisch und scheint mir an der Tagesordnung zu sein. Gefrickel aus der Hand und ohne Konzept. Es wird gleichzeitig Konzept und Design gemacht, dabei zwischen drin Fehler behoben und getestet. Die meisten sogenannten Softwareentwickler arbeiten im Chaos und unverständlicherweise finden sich nur selten Teamleiter, die ihnen das abgewöhnen und dafür sorgen, dass sauber entwickelt wird. Was ist denn bitte grosses dabei, sich eine Grafik hinzumalen, die die einzelnen Blöcke bezeichnet und den Datenfluss skizziert. Dazu noch einen groben Ablaufplan über die use cases und abgefangenen fail cases und gut ist. Das kostet insgesamt 2 Tage, sowas für eine mittelgrosse SW zu leisten. Diese Informationen müssen ohnehin von jemandem definiert und vorgegeben sein. Dazu gibt es das Konzept des Requirement Engineerings. Die funktionellen Anforderungen zu erfassen und zu definieren, kostet in der Regel 2-3 Wochen! Selbst dann, wenn der SW-Entwickler sich vieles selber sagt und vorgibt, kann er es zunächst skizzieren, sich abhaken lassen und dann einfach umsetzen. Das ist viel einfacher und schon bei der Erstentwicklung schneller!!! Auch bei Änderungen zahlt es sich aus: Wenn man die Funktion der SW kennt und sieht, welcher Block was tut, dann kann man sehr einfach die Codezeilen interpretieren. Umgekehrt ist das eine Ochsentour, kostet viel Zeit und ist fehlerträchtig. Aber das Beispiel ist leider kein Einzelfall. In meiner direkten Umgebung sehe ich andauernd Duos von Entwicklern, die zu zweit am PC sitzen und Codeanalyse betreiben, weil sie an etwas weiterstricken sollen, was einer zusammengewichst hat, da weggegangen ist. Mir ist es einfach komplett unbegreiflich, warum sowas nach wie vor exisitert und man Softwareentwicklern nicht schon an der Uni beibringt, geradlinig zu arbeiten. Zu Zeiten der 8Bit-Computer mit 3k RAM war es noch möglich, dass sich ein Schüler ein komplettes Programm ausdenkt und im Kopf behält, aber heute doch nicht mehr. Die Zeiten der Hacker sind vorbei!
Klaus L. schrieb: > Mir ist es einfach komplett unbegreiflich, warum sowas nach wie vor > exisitert und man Softwareentwicklern nicht schon an der Uni beibringt, > geradlinig zu arbeiten. Das ist gar nicht so ungewöhnlich. Gerade in Klitschen machen die Chefs oder Vertriebler dem Kunden gern Versprechungen, um schnell Umsätze und Achtungserfolge zu generieren. Die Qualität bleibt dann auf der Strecke weil dafür nicht genug Resourcen vorhanden sind. Auch in betriebliche Strukturen wo ein Teamleiter kein Softwerker ist, haben solche Probleme.
@ Klaus L. (klausi5000)
>Die Zeiten der Hacker sind vorbei!
Die Zeichen der Zeit erkannt du hast.
Also ich würde hier einmal schauen, welche Verfahren zur Sicherung und Dokumentation des Codes verwendet werden. Wenn dann die Doku auf einer Serviette steht und die Sicherung der Arbeit auf einer Time Machine erfolgt, brauchst du garnicht weiter fragen ob Model- oder Testgetrieben entwickelt wird. Mein Vorschlag. Schaue dir den Code genau an und analysiere, wo deine Probleme liegen. Du wirst feststellen, das du eine Menge Skills aufbauen musst. Danach analysiere was dich daran hindert den Code schnell zu erfassen und ggf. umzusetzen. Sammle das ganze und bereite dich auf ein Gespräch mit deinem Entwickler und deinem Chef vor. Das Gespräch solltest du mit beiden gleichzeitig führen, so fühlt sich keiner übergangen und es kann dich auch keiner hintenherum unter Druck setzten. Lege dein Probleme auf den Tisch und mache deutlich wo dir der Schuh drückt. Der Rest hängt auch etwas von der Reaktion deiner gegenüber ab. Sollte es keine Dokumentation und revisionierte Codeablage geben, kannst du gerne die Einführung von SVN, GIT oder Doxygen vorschlagen. Der Aufwand für einen späteren Einstieg ist zwar nicht ganz ohne, lohnt sich aber und es wird ja eh deine Aufgabe sein, den Code zu dokumentieren. Viel wichtiger ist es da, ob deine Kollegen dir folgen und es selber umsetzen oder oder ob die die Arbeit lieber versuchen auf die abzuschieben. Ist letztes der Fall und bekommst du keinen Rückhalt vom Chef, nutze die verbleibende Zeit dir einen neuen Job zu suchen. Ich erlebe das in Projekten gerne immer wieder, das gerade programmierende Ings. sich mit den Werkzeugen wie GIT oder SVN schwer tun und nicht bereit sind sich in so etwas einzuarbeiten. Der Code wird dann in Verzeichnisse mit Datumsangabe zwischen gesichert und die Katastrophe ist damit schon vorprogrammiert.
:
Bearbeitet durch User
Klaus L. schrieb: > Was ist denn bitte grosses dabei, sich eine Grafik > hinzumalen, [...] > Diese Informationen müssen ohnehin von jemandem definiert > und vorgegeben sein. Im Prinzip richtig - das kann der Programmierer aber nicht im Alleingang machen. Das Umfeld muss schon halbwegs stimmen. Wenn Dein Chef ein Chaot ist, der sich von den Kunden auf der Nase herumtanzen lässt, hast Du schlechte Karten. > In meiner direkten Umgebung sehe ich andauernd Duos von > Entwicklern, die zu zweit am PC sitzen [...] ??? "Pair programming" kann sinnvoll sein. > Mir ist es einfach komplett unbegreiflich, warum sowas > nach wie vor exisitert und man Softwareentwicklern nicht > schon an der Uni beibringt, geradlinig zu arbeiten. Weil die optimale Methoden von - den Programmierern, - dem Umfeld und - dem Problem abhängt. Ich gebe Dir durchaus recht, dass die Arbeitsmethodik vielerorts schlicht und einfach zum Kotzen ist - aber es ist nicht trivial, das zu verbessern, und mit der Brechstange funktiniert es sicher nicht. > Die Zeiten der Hacker sind vorbei! Hihi... das hättest Du gern... :)
@ Possetitjel (Gast) >> Die Zeiten der Hacker sind vorbei! >Hihi... das hättest Du gern... :) Er meinte wohl eher die "professionellen" Frickler und Einzelkämpfer. Da hat er schon recht. Wo wäre Linux und Co ohne die Zusammenarbeit tausender Enthusiasten? Und die müssen sich auch koordinieren und kommunizieren. Im Bereich Hardware ist es ähnlich. Ich hatte mal das Vergnügen, ein Projekt zu übernehmen, welches ein solides Update kriegen sollte. Doku? "Ja, komm dann mal mit nem Zettel und Stift vorbei, ich sag dir wie das so ungefähr funktioniert." Bitte? Ich hab dann fast die gesamte Doku des Systems (Hardware, Grundkonzept) auf diese Weise und duch viel Rumfragen und auch Messen reverse engineered und aufgeschrieben. Unnötig zu erwähnen, dass das keine Sau interessiert geschweige denn honoriert hatte. Die hielten sich einfach für zu genial, sowas zu brauchen. Naja, am Ende der Probezeit war ich dann wieder weg, sowas muss man sich nicht antun, schon gar nicht als junger Mensch (Die fehlende Doku war nicht das Problem, wohl aber gewisse Leute dort).
:
Bearbeitet durch User
Falk Brunner schrieb: > Die hielten sich einfach für zu genial, sowas zu brauchen. Naja, > am Ende der Probezeit war ich dann wieder weg, sowas muss man sich nicht > antun, schon gar nicht als junger Mensch (Die fehlende Doku war nicht > das Problem, wohl aber gewisse Leute dort). Ich finde, so etwas sollte man sich gerade als junger Mensch ein oder zweimal antun. Das prägt, bringt Erfahrung und man kann verdammt viel dabei lernen. aber man muss dann auch schnell sehen, das man den Absprung in ein seriöses Unternehmen findet.
Klaus L. schrieb: > Mir ist es einfach komplett unbegreiflich, warum sowas nach wie vor > exisitert und man Softwareentwicklern nicht schon an der Uni beibringt, > geradlinig zu arbeiten. Softwareentwicklung krankt insgesamt daran, dass man in kürzester Zeit Dinge von unglaublicher Komplexität und Funktionalität bauen kann. Ein Maschinenbauingenieur, der sich etwas ausdenkt, der muss danach tage-/wochen-/monatelang warten, bis er den teuren (!!!) Prototypen in der Hand hält. Dort haben die Unternehmen gelernt, dass man besser zweimal denkt, bevor man produziert. Softwerker hingegen können ihre Gedanken in Minutenfirst in die Realität umsetzen und Konsequenzen von Fehlern und Fehlplanungen können genau so schnell wieder korrigiert werden. Bis zu einem gewissen Punkt jedenfalls, aber der kommt meist relativ spät...
@ P. M. (o-o) >Softwareentwicklung krankt insgesamt daran, dass man in kürzester Zeit >Dinge von unglaublicher Komplexität und Funktionalität bauen kann. Jain. > Ein >Maschinenbauingenieur, der sich etwas ausdenkt, der muss danach >tage-/wochen-/monatelang warten, bis er den teuren (!!!) Prototypen in >der Hand hält. Dort haben die Unternehmen gelernt, dass man besser >zweimal denkt, bevor man produziert. Wohl wahr. > Softwerker hingegen können ihre >Gedanken in Minutenfirst in die Realität umsetzen und Konsequenzen Scheinbar. > von >Fehlern und Fehlplanungen können genau so schnell wieder korrigiert >werden. Das glaube ich eher nicht. Wenn das wirklich so wäre, wäre Softwareentwicklung deutlich kürzer und stressärmer. Software ist eines der meisten unterschätzten und wohl am meisten ausufernsten Dingen, die der Mensch so produziert.
Sowas nennt man sich ausserhalb seiner Komfortzone zu befinden. Bleib dran, gib nicht auf, das ist das Beste was dir passieren koennte.
Klingt ja leider so, als würde überall hauptsächlich gepfuscht. Unser Unternehmen erzählt den Mitarbeiter auch immer groß vom Arbeiten nach Prozess/Spice Level Blahblahblah, aber machen tut's trotzdem niemand. Wenn man da das Wort Prozess erwähnt, kriegen alle entsetzte Gesichter und wechseln das Thema. Da haben's die Maschinenbauer 'einfacher', dass die Teile eher in einer Kostenaufstellung auftauchen. Arbeitszeit selbst wird 'bei uns' gefühlt nicht berücksichtigt. Anstatt ein Problem mal anzupacken, wird stundenlang geredet, diskutiert und philosophiert, obwohl teilweise noch nicht mal eine faktische Grundlage vorhanden ist. Als Diskussion über Spekulation. ...und bei meiner Bewerbung dachte ich mal, ein so großes Geschäft sollte doch seriös arbeiten, damit ich aus der Uni-Bastelecke mal rauskomme. Schade, das war's nicht. Ich werde weitersuchen.
> Wenn man da das Wort Prozess erwähnt, kriegen alle entsetzte Gesichter
Über Prozesse spricht man NUR, wenn sie nicht funktionieren. Oft ist die
Veränderung schneller als Dein Prozess...
Ja das mit der fehlenden Doku ist ärgerlich, aber vielleicht noch verschmerzbar. Bitte hängt euch da nicht so dran auf. Danke @London. Meine Komfortzone ist praktisch nicht vorhanden. Ich sehe kaum Erfolge und fühle mich einfach blöd weil ich bei jeder kleinen Sache nachfragen muss und nach 8h nicht viel mehr auf die Reihe gebracht hab. Fühle mich wie in ner Prüfung von der ich keinen Plan habe. Würdet ihr das Gespräch mit dem Chef suchen?
@ vic (Gast) >Meine Komfortzone ist praktisch nicht vorhanden. Ich sehe kaum Erfolge >und fühle mich einfach blöd weil ich bei jeder kleinen Sache nachfragen >muss und nach 8h nicht viel mehr auf die Reihe gebracht hab. Fühle mich >wie in ner Prüfung von der ich keinen Plan habe. Schlecht. >Würdet ihr das Gespräch mit dem Chef suchen? Ja, aber nicht nach drei Tagen. Versuch es wenigstens 4 Wochen. Wenn du dann kein Land siehst, sprich mit dem Chef.
vic schrieb: > Ja das mit der fehlenden Doku ist ärgerlich, aber vielleicht noch > verschmerzbar. Bitte hängt euch da nicht so dran auf. > > Danke @London. > Meine Komfortzone ist praktisch nicht vorhanden. Ich sehe kaum Erfolge > und fühle mich einfach blöd weil ich bei jeder kleinen Sache nachfragen > muss und nach 8h nicht viel mehr auf die Reihe gebracht hab. Fühle mich > wie in ner Prüfung von der ich keinen Plan habe. > > Würdet ihr das Gespräch mit dem Chef suchen? kommt immer wieder mal vor dass man sich in nicht dokumentierte sw einarbeitrn muss. wenn du dann immer nach 2 tagen zum chef läufst und heulst, hat keiner was davon. nutze die ersten paar wochen um dich mit c++ und den tools vertraut zu machen. anstatt alle 5min zu fragen lern mit dem debugger umzugehen und sieh zu was der code tatsächlich macht. wenn die lage nach 1monat immer noch aussichtslos ist kannst du dad thema ja mal anschneiden. aber vorerst musst du da durch!
progger schrieb: > aber vorerst musst du da durch! Nein, er kann kündigen, denn er ist ein freier Mensch und kein Sklave!
Jubi schrieb: > progger schrieb: >> aber vorerst musst du da durch! > > Nein, er kann kündigen, denn er ist ein freier Mensch und kein Sklave! kann er. jederzeit. die frage ist nur: ist es sinnvoll, beim kleinsten widerstand im leben davonzulaufen? oder ist es vielleicht besser, mal durchzubeissen? vielleicht ist ja garnicht der code so schlecht, vielleicht sind es die fehlenden c++ kenntnisse. man kann es als chance sehen, mal vernünftig c++ zu lernen. man kann natürlich auch einen anderen job suchen und hoffen, dass dort alles besser ist. und vielleicht ist dort alles besser.
Mitteilung an den Chef, dass es dir nicht leicht fällt und du es ohne Unterstützung nicht in time schaffst. Gleichzeitig aber zeigen, dass du es gerne machen willst.
Es gibt Sachen, die beherrscht man erst nach 2 Jahren perfekt. Sauge die die neuen Dinge auf wie ein Schwamm und besorge Dir rechtzeitig notwendige Hilfsmittel und Bücher wenn es Dir hilft. Frage 2 ist, ob Du schon Plan B hast, wenn Du jetzt schon aufgeben willst.
@ Rudi Radlos (Gast) >Es gibt Sachen, die beherrscht man erst nach 2 Jahren perfekt. Darum geht es doch gar nicht! Der OP ist am absaufen! >Sauge die >die neuen Dinge auf wie ein Schwamm und besorge Dir rechtzeitig >notwendige Hilfsmittel und Bücher wenn es Dir hilft. Ach was? Aber das ist gerade unter Termindruck alles andere als einfach!
Danke nochmal an alle für eure Unterstützung. Kleinere Erfolge sind mittlerweile eingetreten, allerdings bin ich noch weit entfernt davon alle Zusammenhänge zu verstehen. Bin gespannt wie sich das noch entwickelt. Ich bleib dran und werd ab und zu mal hier posten.
Hallo, ich hab nochmal diesen alten Thread herausgekramt um eine Rückmeldung zu geben. Was die anfänglichen Probleme betrifft: Ich hab nach ein/zwei Monaten ein Gespräch gesucht, was auch positiv gewertet wurde. Zur fachlichen Seite: der Code, den ich umsetzen sollte wurde von einem absoluten Guru in Sachen generischer Programmierung geschrieben.Man muss sagen, dass viele meiner Kollegen bei dem Code die Ohren anlegen. Also lag es nicht nur an mir. Generell habe ich viel daraus gelernt, nicht nur auf fachlicher Ebene sondern auch auf zwischenmenschlicher Ebene. Ich denke rein aus der Sicht Erfahrungen zu sammeln, war es auf jeden Fall richtig nicht gleich die Flinte ins Korn zu werfen. Bin nun mittlerweile ein Jahr in der Firma und hab mich recht gut eingelebt. Die Arbeitsbedingungen sind gut, ich habe nette Kollegen und auch ein gutes Gehalt. Die altbekannten Probleme mit fehlender Doku, architektonischen Schnellschüssen,fehlender Kommunikation und gewachsenen historischen Strukturen sind allerdings leider noch da.
@vic (Gast) >Bin nun mittlerweile ein Jahr in der Firma und hab mich recht gut >eingelebt. Die Arbeitsbedingungen sind gut, ich habe nette Kollegen und >auch ein gutes Gehalt. Klingt gut! >Die altbekannten Probleme mit fehlender Doku, architektonischen >Schnellschüssen,fehlender Kommunikation und gewachsenen historischen >Strukturen sind allerdings leider noch da. Die werden nie vollständig verschwinden. Du solltest dazu eine gesunde Einstellung entwickeln. Nicht alles zu ernst nehmen, dich daran nicht aufreiben. Trotzem immer wieder auf die Misstände hinweisen und selber so weit wie möglich an deren Überwindung arbeiten. Perfekt wird es nie.
vic schrieb: > Zur fachlichen Seite: der Code, den ich umsetzen sollte wurde von einem > absoluten Guru in Sachen generischer Programmierung geschrieben.Man muss > sagen, dass viele meiner Kollegen bei dem Code die Ohren anlegen. Also > lag es nicht nur an mir. Ich werde hier ja immer gehauen wenn ich mal schreibe, dass man nicht jede neue Programmiersprache braucht und nicht jedes Feature einer Programmiersprache benutzen sollte, nur weil es da ist. Nun weißt du warum. Man erzeugt Wartungsprobleme. Das verstehen auch Sprachdesigner nicht, die nicht die Finger davon lassen können in ihre Sprache den neusten Rotz einzubauen, nur weil diverse andere Sprachen den Rotz auch haben. Den Sprachdesignern folgen dann Programmierer die den Rotz auch noch verwenden, weil "ist neu", "macht man heute so". Ziel für Codequalität und -komplexität ist, was der durchschnittliche Programmierer gut warten kann und ein schlechter Programmierer gerade noch so in den Griff bekommt. Dieses Einzelkämpfer-Heldentum "Ich und meine IDE gegen den Rest der Welt" ist Gift für Projekte. Leider ist es so, dass viele Chefs solche Gurus für besonders wertvoll halten und übersehen dabei, welchen Schaden sie anrichten.
vic schrieb: > Als Vorlage dienen Quellen in Objective-C. (Bzw. ist auch eine > Implementierung in Java/C# vorhanden.) Wieso gibt es keine anständige Doku?
vic schrieb: > Zur fachlichen Seite: der Code, den ich umsetzen sollte wurde von einem > absoluten Guru in Sachen generischer Programmierung geschrieben.Man muss > sagen, dass viele meiner Kollegen bei dem Code die Ohren anlegen. Also > lag es nicht nur an mir. Ich erinnere mich noch gut an einen alteingesessenen Superexperten, der anstatt
1 | a = a - 1; |
lieber
1 | a = a + 0xFFFF; |
verwendete, weil dies auf dem 8051 angeblich schneller verarbeitet wurde. (Das wir damals einen MSP430 verwendet haben, ist ihm dabei wohl entgegangen). Was ich draus gelernt habe: Die wahre Kunst ist es, verständlichen und wartbaren Code zu schreiben. Soviel zum Thema "absoluter Guru".
Jay schrieb: > Ich werde hier ja immer gehauen wenn ich mal schreibe, dass man nicht > jede neue Programmiersprache braucht und nicht jedes Feature einer > Programmiersprache benutzen sollte, nur weil es da ist. Nun weißt du > warum. Man erzeugt Wartungsprobleme. Wartungsprobleme sehe ich dann sogar mit weitaus mehr Aufwand als die eigentliche Entwicklung. Dabei liegt es nicht mal unbedingt daran, dass es nur Einzelkämpfer sind. Vielmehr wird einfach aus "Spaß" an der Technik rundrum ein übelster Mehraufwand betrieben und die eigentliche Aufgabe wird aus dem Blickfeld verloren. Im übertragenen Sinn: Entwicklung eines Rasenmähers: heraus kommt ein Monster mit BiTurbolader, Kompressor, nutzergesteuerter Kennfeldanpassung etc. und alles natürlich vom Anwender konfigurierbar. Das alles wird nur entwickelt "weil mans kann" Die Wartung sieht dann so aus, dass die eigentlich (billige) Wartungsaufgabe (Messer schärfen etc.) völlig zur Nebensache wird und man sich plötzlich mit Kennfeldern rumschlägt... Stichwort: Overengineering Jay schrieb: > Ziel für Codequalität und -komplexität ist, was der durchschnittliche > Programmierer gut warten kann und ein schlechter Programmierer gerade > noch so in den Griff bekommt. Das ich kann 100% unterschreiben. Zur Dokumentation: Natürlich ist jeder angehalten sein Zeug zu dokumentieren. Im allgemeinen ist es aber meistens so, dass erst dokumentiert wird wenn der Softwarestand "fertig" ist. Und da das gewöhnlich nie erreicht wird, fehlt halt meistens die Doku. und es wird sofort zur Wartung/Bugfixes usw. übergegangen.
Possetitjel schrieb: > Im Prinzip richtig - das kann der Programmierer aber nicht > im Alleingang machen. Das Umfeld muss schon halbwegs stimmen. Ich glaube, dass hier der Hase im Pfeffer liegt. Die jungen Entwickler kommen erst mal in die Klitschen rein, wo alles auf Druck und Oberflächlichkeit ausgelegt ist. Am Schlimmsten geht es da bei den Zeitarbeitern zu. Statt in Qualität und Nachhaltigkeit zu investieren, wird nur das Allernötigste gemacht, weil mehr nicht bezahlt wird - höchsten im Folgeauftrag. Habe da so meine eigenen Erfahrungen. Hinterher wird es schwer, sich nochmal einen anderen Stil anzugewöhnen...
Nabend, vic schrieb: > Jay schrieb: >> Ziel für Codequalität und -komplexität ist, was der durchschnittliche >> Programmierer gut warten kann und ein schlechter Programmierer gerade >> noch so in den Griff bekommt. > > Das ich kann 100% unterschreiben. Das Ganze kann dann aber auch zu einer Abwärts-Spirale führen, bei der die besten dann gehen und der Durchschnitt dabei immer weiter sinkt. Als freelancer sehe ich ja so die eine oder andere Entwicklungsabteilung und kann berichten, dass der "Durchschnittsentwickler", je nach Unternehmen/Abteilung sehr unterschiedlich sein kann. Ich denke, wir werden damit leben müssen, dass es sehr große Unterschiede gibt und nun ausgerechnet den Besten, die meist die höchste Produktivität haben, Steine in den Weg zu legen, halte ich für nicht Zielführend. Dann eher mal die Besten zu internen Schulungen verdonnern und gemeinsam von den Besten lernen ;-) mfg und frohe Ostern, Torsten
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.