Hi zusammen,
ich bin nicht direkt im Bereich Elektronik und Controller angesiedelt,
aber nah dran.
Ich bin in einem DAX-Konzern und zurzeit als Werkstudent tätig. Nebenbei
schreibe ich meine Bachelorarbeit. Dazu bin ich bei der Firma angestellt
und soll die Arbeit nebenbei miterledigen. Soweit zwar zeitlich durchaus
anspruchsvoll. Zum Glück darf ich in (theoretischen) Leerlaufphasen
Recherche im Unternehmen betreiben. Das Unternehmen hat ein konkretes
Problem im Dokubereich, das ich als Fallbeispiel für meine BA verwenden
kann (und darf).
Das Problem: Ich bin ja als Werkstudent da und meine Aufgabe ist es,
eine etwa 500-600 Seiten starke Dokumentation über eine recht komplexe
Datenbankanwendung aktuell zu halten ("Hand"buch).
Soweit kein Problem, das Handbuch kenne ich sehr gut, weil ich es
komplett neu geschrieben habe. War soweit recht spaßig, das Programm mal
auf Herz und Nieren zu testen und gefundene Bugs/Fehler zu melden.
Jetzt könnte ich was anderes machen, aber das Programm wird
weiterentwickelt (sinnvollerweise). Ich soll die Doku dazu aber immer
noch aktuell halten (sinnvollerweise).
Mein Problem ist jetzt, dass ich von den Entwicklern nichts bekomme,
worauf ich schließen könnte, welche Teile der 500-600 Seiten ich auf
Änderungen und Neuerungen kontrollieren und aktualisieren müsste.
Im Klartext heißt das, dass ich die komplette Doku mit allen Abläufen
"live" am System testen und vergleichen muss, ob sich was geändert hat.
Das kostet einerseits Nerven (andererseits kann man als Werkstudent
nicht erwarten, Spaß zu haben), vor allem aber extrem viel Zeit.
Zeit, die eigentlich für die Katz ist und mir für die BA fehlt.
Mit der Entwicklung habe ich schon gesprochen, sie wissen selbst, dass
sie eigentlich ein Changelog machen müssten, aber offenbar wird da
munter drauflosprogrammiert, ohne überhaupt einen Plan zu haben, den sie
mir geben könnten. Anscheinend gibt es da gar nichts!
O-Ton: "Für so was haben wir keine Zeit".
Was kann man denn da machen? Wenn ich als Werkstudent aufmucke, dann bin
ich raus. An Bewerbern wird es kaum mangeln. Die Entwicklung hat keinen
Bock auf ein Changelog und ich reiße mir hier den Arsch auf, um
einerseits die Doku aktuell zu halten und andererseits nebenbei noch
eine Bachelorarbeit zu schreiben. Die Bachelorarbeit ist deswegen auch
schon hinter dem Zeitplan.
Langsam kotzt es mich an, hier 90% für die Ablage P zu arbeiten und
nebenbei noch meinen Abschluss zu gefährden. Kündigen geht leider nicht,
weil ich das Unternehmen als Fallbeispiel brauche und sich meine Miete
nicht von selbst zahlt.
Hilfe!
Gruß
schreibsklave schrieb: > Was kann man denn da machen? Wenn ich als Werkstudent aufmucke, dann bin > ich raus. Mal mit Deinem direkten Vorgesetzten sprechen? Frag ihn, wie er sich das denn vorstellt. Wenn Du am Anfang die Absprache hattest, dass Du nur Sachen updaten musst, die im Changelog stehen, dann hast Du doch jetzt weniger zu tun, oder?
Die Entwicklung wird doch bestimmt eine Versionskontrolle (git,svn,cvs...) nutzen. Aus dessen Log sollte sich doch herausfinden lassen woran gearbeitet wird, auch wenn der nicht besonders schön/übersichtlich ist. Im Zusammenhang mit dem Bugtracker und was sonst noch so verwendet wird (Jira & Co) müsstest du doch alle Informationen finden können.
schreibsklave schrieb: > sie wissen selbst, dass > sie eigentlich ein Changelog machen müssten, aber offenbar wird da > munter drauflosprogrammiert, ohne überhaupt einen Plan zu haben, Herzlich willkommen in der realen Berufswelt.
schreibsklave schrieb: > Mein Problem ist jetzt, dass ich von den Entwicklern nichts bekomme, > worauf ich schließen könnte, welche Teile der 500-600 Seiten ich auf > Änderungen und Neuerungen kontrollieren und aktualisieren müsste. Wie sollen die Dir das auch sagen? Dazu müssten sie es kennen und könnten es dann besser selber machen. schreibsklave schrieb: > vor allem aber extrem viel Zeit. > Zeit, die eigentlich für die Katz ist und mir für die BA fehlt. Da stimmt dann irgendwas nicht. Dienst ist Dienst und BA ist BA. Wenn Du 3h pro Tag Doku machst, dann wird halt soviel fertig wie fertig wird. Das Rennen gegen den Igel Software kannst Du doch eh nicht gewinnen. Ein Schalter anders gesetzt und in jeder Maske ändert sich ein Icon. Sinnvoll ist Deine Arbeit nur, wenn - die Software abgeschlossen ist - Du die Quellen bekommst - Ein Analysetool die Quellen zu fresen kriegt und semantische Infos daraus ausspuckt. Im Einfachsten Fall Doxygen & Co, im komplizierteren Fall fällt durch individuelle Tools eine Beschreibung aus den Quellen.
Dr. Sommer schrieb: > Aus dessen Log sollte sich doch herausfinden Zwischen einer KLEINEN Änderung und deren Folgen können Welten liegen. Ob z.B. jeder Fliegendreck als Punkt erkannt oder dokumentiert wird? Eine ständige Sammlung der Symptome wäre nach meiner Meinung eine erste Keimzelle zum Aufbau einer Wiki usw.
schreibsklave schrieb: > Was kann man denn da machen? Wenn ich als Werkstudent aufmucke, dann bin > ich raus. An Bewerbern wird es kaum mangeln. Falsche Einstellung. Auf dem Weg von der digitalen Gesellschaft 3.8 zur digitalen Gesellschaft 4.0 (da wo Estland heute schon ist ;)) brauchen wir Frechmut quer durch alle Hierarchieebenen. Auf auf, sei der erste und fang an. Zeig den reaktionären Kräften, warum die Generation Y die Generation "Why" ist! Mutig, verantwortungsbewusst und pionierhaft - so muss er sein, der moderne Arbeitnehmer. Du bist kein Sklave. Du bist die Zukunft!
Alles neu, alles digital! schrieb: > schreibsklave schrieb: >> Was kann man denn da machen? Wenn ich als Werkstudent aufmucke, dann bin >> ich raus. An Bewerbern wird es kaum mangeln. > > Falsche Einstellung. Auf dem Weg von der digitalen Gesellschaft 3.8 zur > digitalen Gesellschaft 4.0 (da wo Estland heute schon ist ;)) brauchen > wir Frechmut quer durch alle Hierarchieebenen. > Auf auf, sei der erste und fang an. Zeig den reaktionären Kräften, warum > die Generation Y die Generation "Why" ist! Mutig, verantwortungsbewusst > und pionierhaft - so muss er sein, der moderne Arbeitnehmer. > > Du bist kein Sklave. Du bist die Zukunft! love it!
Herzlich willkommen in der realen Berufswelt. Etwas lockerer werden und nicht an scheinbaren Widerspruechen klebenbleiben. Du machst deinen job, deine Arbeit und die anderen machen ihren. Auch wenn "Optimierungspotential" besteht.
Alles neu, alles digital! schrieb: > Auf auf, sei der erste und fang an. Zeig den reaktionären Kräften, warum > die Generation Y die Generation "Why" ist! Mutig, verantwortungsbewusst > und pionierhaft - so muss er sein, der moderne Arbeitnehmer. > > Du bist kein Sklave. Du bist die Zukunft! Super. Ganz genau. Die autoritären Zeiten des 2. Weltkriegs sind vorbei! Jetzt zeigen wir es unseren Chefs! (Und vor allem, dass die auch mal was lernen können, die meisten haben wenig Ahnung von guter Entwicklung!)
schreibsklave schrieb: > Was kann man denn da machen? Wenn ich als Werkstudent aufmucke, dann bin > ich raus. An Bewerbern wird es kaum mangeln. Die Entwicklung hat keinen > Bock auf ein Changelog und ich reiße mir hier den Arsch auf, um > einerseits die Doku aktuell zu halten und andererseits nebenbei noch > eine Bachelorarbeit zu schreiben. Du machst da aber Allerhand verkehrt! 1. Fehler: Du "darfst" dort deine Bachelorarbeit schreiben. So? Ist es nicht eher so, daß deine Firma ein Problem gelöst haben will, wofür aber sowieso viel zu teure Ings zu teuer sind? Die Firma soll lieber froh sein daß DU dich ihrer annimmst. Mach dich nicht kleiner als du bist. 2. Fehler: Du schreibst deine BA nebenbei, gnädigerweise darfst du während der Arbeit recherchieren. Deine BA ist der verdammte Zweck deines Dortseins, eine BA schreibt man nicht nebenbei, das ist ein Vollzeitjob. Jedenfalls bei einer anständigen BA. Recherche gehört da zu deinen Hauptpflichten. Dies erledigst du nicht nur selbstverständlich in deiner Arbeitszeit, sondern deine Arbeitszeit ist genau dafür da. 3. Fehler: Du kriegst keine Change-Logs...hast du wenigstens Einblick in den Quellcode? Machen sich die Code-Affen in deiner Firma wenigstens mal ein paar Gedanken bezüglich Klassendiagrammen oder Entwurfsmuster? Oder hacken die erst auf der Tastatur rum und überlegen sich hinterher was das sein könnte? Es ist doch scheißegal wieviele Bewerber in deiner Firma Schlange stehen-überleg dir lieber, ob du unter diesen Bedingungen arbeiten willst. DAX-Konzern hin oder her...
Wühlhase schrieb: > 3. Fehler: > Du kriegst keine Change-Logs... Glaubst Du dasss da immer ALLES drin steht oder es einen sofort ins Auge fällt? Wie war das doch gleich bei Dieselgate?
Wühlhase schrieb: > 1. Fehler: > Du "darfst" dort deine Bachelorarbeit schreiben. So? Ist es nicht eher > so, daß deine Firma ein Problem gelöst haben will, wofür aber sowieso > viel zu teure Ings zu teuer sind? Da überschätzt du die Leitungsfähigkeit von Bachelor-Kandidaten und die Anforderungen an sie aber gewaltig. Es wird immer wieder behauptet, dass es in der Industrie weit verbreitet ist, dass man Ingenieurarbeit durch Bachelor-Kandidaten machen lässt. Das stimmt aber nicht. Die Bachelor-, wie früher die Diplomarbeit, handelt im Normalfall vom ersten praktische Problem das der Kandidat je lösen muss. Noch dazu mit einem pseudo-wissenschaftlichen Anspruch, den in der Industrie eigentlich keinen interessiert. Die Wahrscheinlichkeit, dass der Kandidat wirklich eine industriereife Lösung findet ist gering. Der Betreuungsaufwand meist so hoch, das es im Normalfall billiger ist es einfach selber zu machen. Das war schon zu Diplomzeiten so. Mit dem Bachelor sind die Anforderungen an Bachelor-Arbeiten nochmal gesunken. Daher gibt man den Kandidaten Aufgaben bei denen sie möglichst keinen Schaden anrichten könnten. Das Ergebnis verschwinden zu 99% in der Schublade. Man könnte als Merksatz sagen: Wenn ein Bachelor-Kandidat das Problem lösen kann, dann ist es sowieso kein Problem für einen teuren Ingenieur. > Deine BA ist der verdammte Zweck deines Dortseins, eine BA schreibt man > nicht nebenbei, das ist ein Vollzeitjob. Nein, wie er selber schreibt >> zurzeit als Werkstudent tätig Das heißt, man bezahlt ihn als Werkstudent und erlaubt ihm schon einmal nebenbei in ein Thema hineinzusehen. Der Trick ist nicht neu. Eigentlich dürfen laut vielen Studienordnungen Abschlussarbeiten nicht bezahlt werden. So umgeht man das zu einem gewissen Grad und lässt dem Studenten ein paar Euro zukommen. Ansonsten, alle Studienordnungen, die ich im BA Bereich kenne, sehen die Möglichkeit der Teilzeit-Bachelorarbeit vor. Dabei verdoppelt sich die erlaubte Zeit. > Machen sich die Code-Affen An den Fragesteller: Nur falls es nicht klar ist, Kollegen als Code-Affen zu beleidigen kommt nicht gut. Ich empfehle die Ausdrucksweise nicht zu übernehmen. > in deiner Firma wenigstens mal ein > paar Gedanken bezüglich Klassendiagrammen oder Entwurfsmuster? Ok, jetzt wissen wir dass du nicht in der Industrie arbeitest. > Es ist doch scheißegal wieviele Bewerber in deiner Firma Schlange > stehen- Nur wenn er selber Alternativen hat. Wenn er keine hat, dann muss er sich halt anpassen. > überleg dir lieber, ob du unter diesen Bedingungen arbeiten > willst. DAX-Konzern hin oder her... Ja, aber den Weg vom Studium direkt in die Rente schaffen wenige.
"Keine Zeit" heist immer(!) "keine Lust". Entwickler wollen sich die Arbeit so einfach wie möglich machn. Jegliche Doku, wenn Sie nicht zwingend vorgeschrieben ist und der Chef die nicht ständig einfordert wird einfach nicht gemacht. So ist das in fast jeder Firma! Du wirst daran nichts ändern.... Also: lass dich nicht verheizen. Deine Doku wird niemand jemals lesen, bestenfalls wird sie mal durchgeblättert oder nach Stichworten durchsucht. Du bestimmst also den Inhalt und was wichtig ist um dokumentiert zu werden. Die BA ist wichtiger!
Hannes J. schrieb: > Mit dem Bachelor sind die Anforderungen an Bachelor-Arbeiten nochmal > gesunken. Finde den Fehler... oszi40 schrieb: > Wühlhase schrieb: > 3. Fehler: > Du kriegst keine Change-Logs... > > Glaubst Du dasss da immer ALLES drin steht oder es einen sofort ins Auge > fällt? Wie war das doch gleich bei Dieselgate? Ich glaube nicht dass solche "Easter-Eggs" im Manual landen sollen...
Der klassische Ansatz war mal: Laufe zyklisch Deine Programmierer ab und frag sie auf dem kleinen Dienstweg, was sich geändert hat. Das hat man mir noch so beigebracht. Das sei der kommunikative Bestandteil der technischen Redakteursarbeit. In der Praxis scheitert dieser Ansatz, weil der Softi Deine Doku nicht kennt, seine Sicht auf die Dinge grundsätzlich anders ist. Auch manuell oder teilautomatisiert erstellte ChangeLogs verraten nicht immer die Wahrheit über das Produkt. Was soll der Programmierer denn schreiben, wenn er in einer externen Ressource 'nen String ändert? "RessourceID 3942 auf "Datei nicht konvertieren" geändert" ist seine Sicht der Dinge. "Logik des Parameters "Dateikonvertierung" auf Dialog "Blablabla" umgedreht" wäre Deine und damit die Sicht des Kunden. Ich habe damals eine Reihe externer Tools gebaut, die diese Änderungen ermitteln und auch mit Versionierung nachhalten. Das geht für APIs (z.B. C# über Reflection), Datenbanken und Ressourcen ganz gut. Es verschiebt allerdings auch das Problem auf eine andere (anspruchsvollere?!?) Ebene. Wenn Du Dich nicht mehr fragen musst "Was hat sich geändert?", hast Du mehr Zeit, Dich zu fragen "Warum hat sich das geändert?". Hier tun sich Abgründe auf. Ich habe oft genug bis in den Quellcode verfolgen können und müssen, welchen Unsinn die Softies dort getrieben haben: logische Widersprüche, nicht wartbare Gattergräber, unvollständige Funktion bis hin zur gänzlich fehlenden Implementierung scheinen der Alltag im Business zu sein (Alte Bauernregel: Je unkooperativer der Softi, desto größer der Dreck am Stecken!). Will sagen: Das was Du so erfährst, willst Du als Schreiberling eigentlich gar nicht wissen! Es gibt aber durchaus modernere Methoden, bei denen der Redakteur im Vorfeld als produktives Mitglied des Teams z.B. die Useability einer Änderung/Erweiterung erarbeitet (SAP hat so was mal angedacht) und damit quasi nebenbei über die Aufgaben in seinem Arbeitsbereich informiert wird. Dann malt man Dialoge, legt Captions fest, testet den Bedienablauf aus oder schreibt auch mal 'nen Example für eine API, so wie die Intention es vorgibt (nicht, wie die Programmierer es gerne hätten!). Danach hat man alles, was man braucht und kann die Softies ölen lassen. Vielleicht ganz heilsam: Setz Dich mal zyklisch mit dem First Level Support zusammen und versuche herauszufinden, wo es beim Kunden wirklich hakt. Ich habe oft genug erlebt, dass Kunden eher zum Telefon greifen, als nur "F1" oder "Hilfe" für die kontextsensitive Hilfe zu drücken. Viele wussten gar nicht, dass das geht! Schon hier gehen viele liebevoll und sorgfältig recherchierte Infos des Redakteurs verloren - sogar zwischen Redaktion und Support (der reißt auch oft den Dialog auf und versucht, fünf Einstellungen voreinander zu bekommen, bevor er die Hilfe liest). Hier erfährst Du am ehesten, welchen Stellenwert Deine Doku einnimmt, wo Du etwas verbessern oder erweitern kannst, insbesondere auch, wie selten ein wirklicher Fehler in der Dokumentation überhaupt auffällt. Ein abschließendes Zitat noch (O-Ton meines damaligen GF): "Wir verkaufen Software - keine Dokumentation." Das sagt doch alles, oder?
Rumpel schrieb: > "Keine Zeit" heist immer(!) "keine Lust". Entwickler wollen sich die > Arbeit so einfach wie möglich machn. Jegliche Doku, wenn Sie nicht > zwingend vorgeschrieben ist und der Chef die nicht ständig einfordert > wird einfach nicht gemacht. So ist das in fast jeder Firma! Du wirst > daran nichts ändern.... Genau so ist es. Doku schreiben? Viel zu mühsam die überhaupt aktuell zu halten. In der Zeit könnte ich auch Kaffee trinken, ein neues Framework ausprobieren oder halt an einem der 5 gleichzeitig brennenden Prio-1 Projekte arbeiten. Doku ist immer veraltet - daher liest sie auch keiner. Wenn meine Studenten so schreien würden,.. ich würde da nicht reagieren. Höchstens meinem Teamleiter sagen, dass mich die Leute von der Arbeit abhalten mit ihren Problemchen. Dann bekommen die vielleicht readonly Berechtigungen zum git-Repository oder Jira und können sich das Deltas selbst bilden. Vieles in der IT funktioniert nach dem Miau-Prinzip: alles für die Katz'. Damit muss man sich abfinden, dass eben gern man was für die Tonne gearbeitet wird. Manchmal wusste ich bei Projekten schon vorher, dass sie so niemals live gehen werden.
klausi schrieb: > Ja das sagt auch, wie wenig Hirn diese GFs haben.. Falls sich die Äußerung auf die Aussage "Wir verkaufen Software - keine Dokumentation." beziehen sollte, muss ich deutlich widersprechen. In den allerseltensten Fällen wird schon vor dem Kauf die Qualität der Dokumentation geprüft. Allerhöchstens wirft man einen Blick auf die Leistungsbeschreibung und "Erfolgsgeschichten". Derjenige, der die Kaufentscheidung fällt, ist vielfach auch nicht der spätere Anwender des Produktes. Sicherlich kann eine ordentliche Dokumentation bei einigen Produkten auch als eine Art Aushängeschild gelten, aber das ist die ganz große Ausnahme. In der Praxis stellt sich heraus, dass die wenigsten Anwender eines Produktes wirklich in die mühsam erstellte Dokumentation hineinschauen. Natürlich muss die Dokumentation zumindest die rechtlich vorgeschriebenen Inhalte aufweisen. Dies aber weniger für den Anwender, sondern vielmehr für andere Marktteilnehmer, die bei fehlenden Informationen versuchen würden, einen Vertriebsstopp für das Produkt zu erwirken. Und wenn man einen Kunden fragen würde, ob er bereit wäre, die Dokumentation separat zu bezahlen, würde er genauso sagen: "Ich kaufe Software - keine Dokumentation." Die Dokumentation hat natürlich auch noch einen anderen Zweck, nämlich den Aufwand für die Bearbeitung von Supportanfragen gering zu halten. Wie aber schon erwähnt, sind heutzutage viele Kunden viel zu bequem, selbst in die Dokumentation zu schauen. Hier im uC-Forum erleben wir es doch auch ständig, dass viele Bastler oder gar "profesionelle" Entwickler nicht einmal mehr in die Datenblätter ihrer Bauteile schauen, sondern einfach hier nachfragen. Deswegen benötigt die Supportabteilung natürlich geeignete Unterlagen, sprich Dokumentation. Vollständig würde die Aussage eines GF daher vielleicht lauten: "Wir verkaufen Software - keine Dokumentation. Trotzdem müssen wir viel Aufwand in die Dokumentation stecken, da wir sie liefern müssen."
Andreas S. schrieb: > Vollständig würde die Aussage eines GF daher vielleicht lauten: "Wir > verkaufen Software - keine Dokumentation. Trotzdem müssen wir viel > Aufwand in die Dokumentation stecken, da wir sie liefern müssen." Richtig! Und der minimale Aufwand zur Erstellung dieser Dokumentation ist eine rechtzeitige und vollständige Einbindung des Redakteurs in den Entwicklungsprozess. Wer meint, sich das sparen zu können, der hat das Gehalt für den Redakteur zumindest zum Großteil aus dem Fenster geschmissen. Die Frage andersherum gestellt: Alle (Controller, Vertriebler, die GF, das Marketing, sogar der Kunde) wollen von den Entwicklern wissen: Was ist denn an der neuen Version so endgeil, dass ihr wieder nen Jahr darüber gebrütet habt? Was hindert die Entwickler, ChangeLogs zu erstellen und aufzubereiten, Redakteure zu informieren, um nicht permanent von allen Seiten gelöchert zu werden? Was zum Henker hält sie davon ab?
Andreas S. schrieb: > Trotzdem müssen wir viel > Aufwand in die Dokumentation stecken, da wir sie liefern müssen." Die Erstellung der 1. Doku ist noch einfach. Später die Änderungen regelmäßig einzupflegen wird oft vergessen od. bleibt liegen weil es Aufwand macht, der auch bezahlt werden muß?
Hannes J. schrieb: > Wühlhase schrieb: >> 1. Fehler: >> Du "darfst" dort deine Bachelorarbeit schreiben. So? Ist es nicht eher >> so, daß deine Firma ein Problem gelöst haben will, wofür aber sowieso >> viel zu teure Ings zu teuer sind? > > Da überschätzt du die Leitungsfähigkeit von Bachelor-Kandidaten und die > Anforderungen an sie aber gewaltig. > > Es wird immer wieder behauptet, dass es in der Industrie weit verbreitet > ist, dass man Ingenieurarbeit durch Bachelor-Kandidaten machen lässt. > Das stimmt aber nicht. Die Bachelor-, wie früher die Diplomarbeit, > handelt im Normalfall vom ersten praktische Problem das der Kandidat je > lösen muss. Noch dazu mit einem pseudo-wissenschaftlichen Anspruch, den > in der Industrie eigentlich keinen interessiert. > > Die Wahrscheinlichkeit, dass der Kandidat wirklich eine industriereife > Lösung findet ist gering. Der Betreuungsaufwand meist so hoch, das es im > Normalfall billiger ist es einfach selber zu machen. Das war schon zu > Diplomzeiten so. Mit dem Bachelor sind die Anforderungen an > Bachelor-Arbeiten nochmal gesunken. Daher gibt man den Kandidaten > Aufgaben bei denen sie möglichst keinen Schaden anrichten könnten. Das > Ergebnis verschwinden zu 99% in der Schublade. Auch auf die Gefahr hin daß dein Weltbild zusammenbricht: Genau das erlebe ich aber in der Industrie. Bachelor-Arbeiten werden für Dinge vergeben, für die das mit dem Brot-und-Butter-Geschäft bereits überlasteten Ings keine Zeit haben. Da kommt zwar kein verkaufsfertiges Gerät raus, aber ein für eine bestimmte Aufgabe programmierter Mikrocontroller. Die Hardware nochmal überarbeitet, die Software bleibt wie sie ist. Was das Programm genau macht interessiert keine Sau, ob es besser (kleinerer Mikrocontroller?) geht interessiert entweder niemanden, oder der Mikrocontroller wird vorgegeben. Dann stellt sich die Frage anders herum: Kann der Controller das, was er soll? So gut wie niemand macht sich da bei der Aufgabenstellung Mühe. >> Deine BA ist der verdammte Zweck deines Dortseins, eine BA schreibt man >> nicht nebenbei, das ist ein Vollzeitjob. > > Nein, wie er selber schreibt > >>> zurzeit als Werkstudent tätig > > Das heißt, man bezahlt ihn als Werkstudent und erlaubt ihm schon einmal > nebenbei in ein Thema hineinzusehen. Der Trick ist nicht neu. Eigentlich > dürfen laut vielen Studienordnungen Abschlussarbeiten nicht bezahlt > werden. So umgeht man das zu einem gewissen Grad und lässt dem Studenten > ein paar Euro zukommen. > > Ansonsten, alle Studienordnungen, die ich im BA Bereich kenne, sehen die > Möglichkeit der Teilzeit-Bachelorarbeit vor. Dabei verdoppelt sich die > erlaubte Zeit. Ich hab keine Ahnug was die Themen der BAs so sind die du kennst. Meine BA und die eines anderen Werkstudenten bei uns sprengten jedenfalls den 40h/w-Rahmen gewaltig. >> Machen sich die Code-Affen > > An den Fragesteller: Nur falls es nicht klar ist, Kollegen als > Code-Affen zu beleidigen kommt nicht gut. Ich empfehle die > Ausdrucksweise nicht zu übernehmen. > >> in deiner Firma wenigstens mal ein >> paar Gedanken bezüglich Klassendiagrammen oder Entwurfsmuster? > > Ok, jetzt wissen wir dass du nicht in der Industrie arbeitest. Ich kenne die Pfuscherei, mit der in der achsoheiligen Industrie Geld verdient wird. Allerdings, Pfusch bleibt Pfusch, auch wenn jemand dafür Geld bezahlt. Das macht die Sache nicht besser. Und nicht/schlecht dokumentierte Software zähle ich unter Pfusch dazu. Wer würde denn Bauteile verwenden, wenn er kein Datenblatt dazu hat? Wer würde einen Mikrocontroller verwenden, zu dem es keine Doku gibt? Warum zur Hölle macht man das nur bei Software anders? >> Es ist doch scheißegal wieviele Bewerber in deiner Firma Schlange >> stehen- > > Nur wenn er selber Alternativen hat. Wenn er keine hat, dann muss er > sich halt anpassen. > >> überleg dir lieber, ob du unter diesen Bedingungen arbeiten >> willst. DAX-Konzern hin oder her... > > Ja, aber den Weg vom Studium direkt in die Rente schaffen wenige. Wo es sogar einen DAX-Konzern gibt, sollte es auch noch andere Firmen geben.
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.