KurantRubys
Legende
Ist jetzt aber schwer vergleichbar ohne Referenzwert
[Sammelthread] Der Gehalts- und Arbeitsplatzthread
- Ersteller 1up
- Erstellt am
sidewinderdxii
Legende
Heute kam nach einer gefühlten Ewigkeit (ca.6 Monate) mein Ergänzungsvertrag als Fahrtrainer. 200€ Brutto mehr, plus höhere Zahlung, wenn ich einen Azubi mit habe.
Ultink
Profi
- Mitglied seit
- 06.01.2025
- Beiträge
- 356
Wirklich nur für den Werterhalt oder war da auch Modernisierung und Renovierung dabei? Ich erwarte in einem Forum natürlich keine ehrliche Antwort
Ich lege für meine vermieteten MFH ca. 10-15% der Mieteinnahmen zurück.
Zwei Häuser haben in den letzten Jahren neue Heizungen bekommen und dann noch eins ein neues Dach.
Selbst dafür habe ich die 10-15% nicht voll ausschöpfen müssen.
wie oft denn jetzt noch? Wie heißt der Titel von dem Thread hier?
Ultink
Profi
- Mitglied seit
- 06.01.2025
- Beiträge
- 356
Was willst du denn in diesem Thread sehen?
Ein Foto vom Arbeitsplatz und dem Lohnzettel?
Selbst im 1.Beitrag ist das Thema Miete dabei, weil es zum Lebensunterhalt gehört, wie alle Ein- und Ausgaben.
Genauso wie Finanzieung von Eigentum.
der nächste der was zu einem haus schreibt bekommt eine threadsperre... wirklich schlimm wie hier wirklich alle immer seitenweise beim off topic mitmachen...
und jetzt wieder zum eigenlichen thema des threads.
und jetzt wieder zum eigenlichen thema des threads.
Cyrrel
Urgestein
IG Metall? ;-)
Cyrrel
Urgestein
So wenig?? Spaß bei Seite, der Unterschied innerhalb einer Stufe ist ja krass, über 40k. 115% scheint ja laut dem Text das automatisch das Minimum zu sein nach 24 Monaten aber was muss man tun um auf 150% zu kommen? Einfach ein paar Jahre den Arsch platt sitzen, oder ist das irgendwie an Performance gekoppelt? Vermute ja ersteres, weil wenn er Betriebsrat Performance hört wird bestimmt sofort der Anwalt ausgepackt
Cyrrel
Urgestein
kein Plan, wusste nur dass IGM im April erhöht... für den Rest hab ich Onkel Google befragt ;-)So wenig?? Spaß bei Seite, der Unterschied innerhalb einer Stufe ist ja krass, über 40k. 115% scheint ja laut dem Text das automatisch das Minimum zu sein nach 24 Monaten aber was muss man tun um auf 150% zu kommen? Einfach ein paar Jahre den Arsch platt sitzen, oder ist das irgendwie an Performance gekoppelt? Vermute ja ersteres, weil wenn er Betriebsrat Performance hört wird bestimmt sofort der Anwalt ausgepackt
- Mitglied seit
- 05.03.2023
- Beiträge
- 148
Wenn ich mir die für mein Gewerk artverwandten TV anschaue, bin ich auch gottfroh, dass ich selbst verhandeln kann.Habe mir die Tage den IG Metall TV angeschaut: dafür steh ich nicht auf
Selbst bei 40h und 14% Leistungszulage nicht
In meinem Leben (nach Stand jetzt) würde ich in keinen Tarifvertrag einsteigen. 20% weniger und noch weitere Einschränkungen (insgesamt wären es 30-35% weniger)? Die wollen mich doch veräppeln!
da haben wir den ersten kandidaten mit einer woche pause
Geforce3M3
Urgestein
- Mitglied seit
- 28.09.2012
- Beiträge
- 111
Ich brauche dafür max 2h.Ist jetzt aber schwer vergleichbar ohne Referenzwert
Man muss dazu sagen: bis die ganze Software mal läuft können 3 Tage vergehen für das erste installieren. Bis das mal alles ohne Probleme läuft, tausend dependencies hier und da zig Probleme je nach Betriebssystem etc.
Hatte auch schon Studenten die dann doch wieder abgebrochen haben da es ihnen alles too much wurde. Die haben dann doch was ganz anderes gemacht (andere berufliche Richtung).
@Geforce3M3 Koennt ihr keine dedizierten, gesharten Build-Umgebungen dafuer nutzen?
Iwelche DevOps/GitHub Pipelines mit den passenden Nodes und allen benoetigten Capabilities. Dann brauchst ihr euch den Mist nichtmehr antun jeden einzelnen PC 'lauffaehig' zu bekommen.
Iwelche DevOps/GitHub Pipelines mit den passenden Nodes und allen benoetigten Capabilities. Dann brauchst ihr euch den Mist nichtmehr antun jeden einzelnen PC 'lauffaehig' zu bekommen.
Geforce3M3
Urgestein
- Mitglied seit
- 28.09.2012
- Beiträge
- 111
Ich kenne mich damit zu wenig aus um beurteilen zu können inwieweit das gut machbar wäre. Aber ich vermute dass das nicht gut ginge.
Ein Grund ist da man in allen möglichen Einstellungen zig Details an die eigene Hardware und an die eigenen Analyseziele anpassen muss. D.h. eine Einstellung die für alle User dann passt gibt es nicht. Man kann da auch schlecht "preconfigured" settings anbieten, denn was wie wo passt muss auch immer neu entdeckt werden – eben je nach neuer Analyse.
Das ist der Vorteil und gleichzeitig der Nachteil. Vorteil ist dass man sehr nahe an die Daten kommt und alles selbst individuell über Code einstellen und analysieren muss. Damit wird der User quasi gezwungen tief in die Daten einzutauchen und alles selbst zu kontrollieren. Der Nachteil ist dass die Lernkurve sehr steil ist, dass es keine out of the box Lösung für alle User gibt, usw.
Dazu kommt: niemand wird dafür bezahlt sowas bereitzustellen. Wir sind ja kein Unternehmen mit ITlern die für sowas bezahlt werden und die sich vor allem mit der Software auskennen. Im Gegenteil: die Wissenschaftler werden für die eigene Forschung bezahlt und das war es. Da setzt sich niemand hin und entwickelt sowas mal nebenbei und pflegt sowas dann auch stets. In einem normalen Unternehmen wäre das anders; da hätte man ITler für die sowas Teil der primären Arbeit wäre und die dafür auch bezahlt werden.
Man gewöhnt sich aber dran und wird immer besser und schneller. Es ist nur schwer zu Beginn. Beispiel: wenn du Leute aus dem Psychologiestudium hast die in den Bereich Neuroimaging/Neurowissenschaft wechseln wollen. Die können meistens nicht programmieren, haben vielleicht ein bisschen mit R/R Studio für Statistik gemacht und das war es. Für die ist es dann am Anfang hart, aber so ist das eben. Man kommt als Wissenschaftler in diesem Bereich ohnehin nicht herum sehr gut im programmieren zu werden. Warum? Man kann theoretisch ja die tollsten Ideen haben wie Gehirnaktivität sich verhält, wie es Stimuli aus der Umwelt verarbeitet, etc. pp. Man kann das aber alles nur testen wenn man die eigenen Ideen auch in Code umsetzen kann. D.h. man muss Gehirnaktivität und Stimuli auch analysieren können. Wie gut oder interessant eine Studie wird hängt also insbesondere auch davon ab wie gut die jeweilige Person programmieren kann.
Ein Grund ist da man in allen möglichen Einstellungen zig Details an die eigene Hardware und an die eigenen Analyseziele anpassen muss. D.h. eine Einstellung die für alle User dann passt gibt es nicht. Man kann da auch schlecht "preconfigured" settings anbieten, denn was wie wo passt muss auch immer neu entdeckt werden – eben je nach neuer Analyse.
Das ist der Vorteil und gleichzeitig der Nachteil. Vorteil ist dass man sehr nahe an die Daten kommt und alles selbst individuell über Code einstellen und analysieren muss. Damit wird der User quasi gezwungen tief in die Daten einzutauchen und alles selbst zu kontrollieren. Der Nachteil ist dass die Lernkurve sehr steil ist, dass es keine out of the box Lösung für alle User gibt, usw.
Dazu kommt: niemand wird dafür bezahlt sowas bereitzustellen. Wir sind ja kein Unternehmen mit ITlern die für sowas bezahlt werden und die sich vor allem mit der Software auskennen. Im Gegenteil: die Wissenschaftler werden für die eigene Forschung bezahlt und das war es. Da setzt sich niemand hin und entwickelt sowas mal nebenbei und pflegt sowas dann auch stets. In einem normalen Unternehmen wäre das anders; da hätte man ITler für die sowas Teil der primären Arbeit wäre und die dafür auch bezahlt werden.
Man gewöhnt sich aber dran und wird immer besser und schneller. Es ist nur schwer zu Beginn. Beispiel: wenn du Leute aus dem Psychologiestudium hast die in den Bereich Neuroimaging/Neurowissenschaft wechseln wollen. Die können meistens nicht programmieren, haben vielleicht ein bisschen mit R/R Studio für Statistik gemacht und das war es. Für die ist es dann am Anfang hart, aber so ist das eben. Man kommt als Wissenschaftler in diesem Bereich ohnehin nicht herum sehr gut im programmieren zu werden. Warum? Man kann theoretisch ja die tollsten Ideen haben wie Gehirnaktivität sich verhält, wie es Stimuli aus der Umwelt verarbeitet, etc. pp. Man kann das aber alles nur testen wenn man die eigenen Ideen auch in Code umsetzen kann. D.h. man muss Gehirnaktivität und Stimuli auch analysieren können. Wie gut oder interessant eine Studie wird hängt also insbesondere auch davon ab wie gut die jeweilige Person programmieren kann.
Das wäre mit virtualisierten bzw. containerisierten Anwendungen ja weiterhin möglich. Du musst den Mist dann halt nicht mehr jedesmal manuell (und wie du selber sagst) mit haufenweise nervigen Dependencies manuell zusammenfrickeln. Aber wenn du "nur" der Anwender bist der sich hier selber was basteln muss und es bei dir an der Uni? keine Infrastruktur für sowas gibt wird das wahrscheinlich auch schwierig.
@Geforce3M3
Stark vereinfacht steht ihr doch vor folgender Herausforderung:
Du / Ihr schreibt code. Dieser Code muss irgendwo ausgefuehrt werden, damit hinten ein Ergebnis rausfaellt.
Und genau diese ausfuehrende Umgebung ist in so nem CI/CD Konstrukt nichtmehr dein eigener Rechner, sondern ein remote-rechner, der genau fuer diese Aufgabe maßgeschneidert ist.
Das einzige was du als User tust: Du pushed und commitest deinen Code in ein Repository. Danach rennt die Pipeline los, checked den Code aus und fuehrt ihn auf dem Buildagent aus.
Diesen Buildagent zu bauen kostet am Anfang recht viel Zeit und Aufwand. Doch danach profitierst du nur noch.
Der Agent kann beispielsweise nen bare-metal Server sein (macht man heute nichtmehr) auf dem python, alle dependencies etc.. installiert sind - quasi wie dein eigener Computer.
Du kannst de Agenten aber auch in nen Docker Container packen (diese lassen sich dann auch fuer eure unterschiedlichen Anforderungen parametrisieren/unterschiedlich voneinander gestalten).
Aber es ist halt super flexibel und du musst dich nichtmehr mit den eigenen User-Umgebungen herumschlagen. Kann naemlich sein dass bei dir der Code laeuft und bei deinem Kollegen halt nich, weil ihm ne env-variable oder sonstwas fehlt. Und dann muss man halt immer rumfrickeln.
Weitere Vorteile sind: Es ist egal ob du nen Mac nutzt und dein Kollege ne Windows buechse. Ihr braucht nur ne Entwicklungsumgebung auf euren Maschinen, das ist alles. Der Rest passiert wo anders - standardisiert, fuer alle gleich.
Soll nicht belehrend sein hier, evtl. hilfts dir ja weiter
//edit: Je mehr User damit arbeiten oder je hoeher die Fluktuation der Kollegen ist, desto mehr lohnt es sich sich mit dem Thema auseinanderzusetzen.
Stark vereinfacht steht ihr doch vor folgender Herausforderung:
Du / Ihr schreibt code. Dieser Code muss irgendwo ausgefuehrt werden, damit hinten ein Ergebnis rausfaellt.
Und genau diese ausfuehrende Umgebung ist in so nem CI/CD Konstrukt nichtmehr dein eigener Rechner, sondern ein remote-rechner, der genau fuer diese Aufgabe maßgeschneidert ist.
Das einzige was du als User tust: Du pushed und commitest deinen Code in ein Repository. Danach rennt die Pipeline los, checked den Code aus und fuehrt ihn auf dem Buildagent aus.
Diesen Buildagent zu bauen kostet am Anfang recht viel Zeit und Aufwand. Doch danach profitierst du nur noch.
Der Agent kann beispielsweise nen bare-metal Server sein (macht man heute nichtmehr) auf dem python, alle dependencies etc.. installiert sind - quasi wie dein eigener Computer.
Du kannst de Agenten aber auch in nen Docker Container packen (diese lassen sich dann auch fuer eure unterschiedlichen Anforderungen parametrisieren/unterschiedlich voneinander gestalten).
Aber es ist halt super flexibel und du musst dich nichtmehr mit den eigenen User-Umgebungen herumschlagen. Kann naemlich sein dass bei dir der Code laeuft und bei deinem Kollegen halt nich, weil ihm ne env-variable oder sonstwas fehlt. Und dann muss man halt immer rumfrickeln.
Weitere Vorteile sind: Es ist egal ob du nen Mac nutzt und dein Kollege ne Windows buechse. Ihr braucht nur ne Entwicklungsumgebung auf euren Maschinen, das ist alles. Der Rest passiert wo anders - standardisiert, fuer alle gleich.
Soll nicht belehrend sein hier, evtl. hilfts dir ja weiter
//edit: Je mehr User damit arbeiten oder je hoeher die Fluktuation der Kollegen ist, desto mehr lohnt es sich sich mit dem Thema auseinanderzusetzen.
Zuletzt bearbeitet:
Geforce3M3
Urgestein
- Mitglied seit
- 28.09.2012
- Beiträge
- 111
@p4n0. Erst einmal danke für die Erklärung.
Das allgemeine Problem ist folgendes:
1. Die Daten (input für den Code) sind nie exakt gleich. Code A funktioniert bei Person/Gehirn X. Bei Person Y (anderes Gehirn) benötigt du Code A1.
Beispiel: du hast 40 Personen in einer Studie gescannt. Bei 20 Personen funktioniert der Code. Bei anderen 20 kommt Unsinn bei raus. D.h. Code muss individuell je nach Person angepasst werden.
2. Die genauen Ziele der Analyse sind immer anders. Was heißt das? Das heißt dass du, wenn du erstmal brauchbare Ergebnisse hast, am Ende die gesamte Pipeline von A bis Z auf deine spezifische Analyse anpasst/tailorst! Alleine das gesamte Preprocessing der Daten, d.h. die Vorverarbeitung/Aufbereitung bevor du die eigentlichen Analysen beginnst musst du individuell auf die Analysen anpassen die du nacher eben anstellen willst.
Welche Preprocessing Schritte sind optimal für Messung X oder Y? Da scheiden sich je nach Fall schon die Geister. Bei manchen Schritten stimmen alle überein, bei anderen gibts Diskussionen und unterschiedliche Ansichten.
D.h. es kann keine Codepipeline geben die allgemein zu guten oder sehr guten Ergebnissen führt. Die ganze Pipeline hängt von individuellen Analysen und Zielen ab. Dazu von Eigenschaften des Datasets. Mit welchen Scannersettings wurde aufgenommen etc? All das und viel mehr beeinflusst den notwendigen Code.
Und was in welchem Fall ideal ist kann man a priori nicht vollständig sagen da auch viel trial and error dabei ist. Stattdessen muss du immer wieder neu coden und anpassen. Ansonsten könnte ich natürlich einfach Code auf github und co hochladen oder sogar wie du sagst eine ideale "workenvironment" auf einen Server schaffen.
Jetzt verstanden? Oder reden wir aneinander vorbei und ich verstehe dich nicht?
Das Problem ist weniger dass die Software hier und da mal "verkackt" weil beispielsweise ne dependency fehlt, sondern weil die Daten die verarbeitet werden komplex sind und individuelle Handhabung benötigen, quasi no one code to rule them all.
Keine Sorge, habe ich so nicht verstanden, freue mich über Feedback.Soll nicht belehrend sein hier, evtl. hilfts dir ja weiter
Das allgemeine Problem ist folgendes:
1. Die Daten (input für den Code) sind nie exakt gleich. Code A funktioniert bei Person/Gehirn X. Bei Person Y (anderes Gehirn) benötigt du Code A1.
Beispiel: du hast 40 Personen in einer Studie gescannt. Bei 20 Personen funktioniert der Code. Bei anderen 20 kommt Unsinn bei raus. D.h. Code muss individuell je nach Person angepasst werden.
2. Die genauen Ziele der Analyse sind immer anders. Was heißt das? Das heißt dass du, wenn du erstmal brauchbare Ergebnisse hast, am Ende die gesamte Pipeline von A bis Z auf deine spezifische Analyse anpasst/tailorst! Alleine das gesamte Preprocessing der Daten, d.h. die Vorverarbeitung/Aufbereitung bevor du die eigentlichen Analysen beginnst musst du individuell auf die Analysen anpassen die du nacher eben anstellen willst.
Welche Preprocessing Schritte sind optimal für Messung X oder Y? Da scheiden sich je nach Fall schon die Geister. Bei manchen Schritten stimmen alle überein, bei anderen gibts Diskussionen und unterschiedliche Ansichten.
D.h. es kann keine Codepipeline geben die allgemein zu guten oder sehr guten Ergebnissen führt. Die ganze Pipeline hängt von individuellen Analysen und Zielen ab. Dazu von Eigenschaften des Datasets. Mit welchen Scannersettings wurde aufgenommen etc? All das und viel mehr beeinflusst den notwendigen Code.
Und was in welchem Fall ideal ist kann man a priori nicht vollständig sagen da auch viel trial and error dabei ist. Stattdessen muss du immer wieder neu coden und anpassen. Ansonsten könnte ich natürlich einfach Code auf github und co hochladen oder sogar wie du sagst eine ideale "workenvironment" auf einen Server schaffen.
Jetzt verstanden? Oder reden wir aneinander vorbei und ich verstehe dich nicht?
Das Problem ist weniger dass die Software hier und da mal "verkackt" weil beispielsweise ne dependency fehlt, sondern weil die Daten die verarbeitet werden komplex sind und individuelle Handhabung benötigen, quasi no one code to rule them all.
Das ist kein Problem. Gesondertes Repo, Forks, Staging Branches etc.. Kann man mit nem passendem GitHub Setup abbilden.
Die Pipeline laesst sich parametrisieren durch welchen 'Compiler' dein Input-Code durchgenudelt wird.
Ich verstehe zwar nicht ganz im Detail was ihr da genau tut aber auch hier ist ne Pipeline parametrisierbar in unterschiedliche Stages.
Du kannst unterschiedliche Pipelines bauen (Kannst du dir wie ein Kochbuch vorstellen).
Um das etwas zu veranschaulichen:
1.) Code auschecken. Das sollte fuer alle Faelle allgemeingueltig sein.
2.) Pre-Processing. Hier kann es sein, dass das eine Gericht erst kochendes Wasser braucht. Also wird die Pipeline erst den Herd einschalten damit das Wasser kocht.
Dieser 2. Schritt MUSS nicht in jeder Pipeline vorkommen. Bei ner anderen Pipeline kann der Code direkt durch den Compiler gejagt werden.
etc. etc..
Diese Schritte koennen aber auch generelle Themen wie Codeanalysis, securitychecks oder sonstwas sein. z.B: Pruefen ob sich jeder an eure Programmier-Regeln haelt etc. Unit tests etc..
Ich glaube schon langsam zu verstehen dass ihr recht flexible Anforderungen an eure 'Build-Umgebung' habt. Warscheinlich waere das in deinem Fall mit Kanonen auf Spatzen geschossen. Steckt wohl zuviel Arbeit dahinter das sauber zu 'Verpipe-Linen'.
Ich versteh was du meinst, hab damit ja auch täglich zu tun, aber ich versuchs trotzdem mal extremst zu vereinfachen, damit "Fachfremde" das einfach verstehen können.
Man stelle sich n Trichter an einer Maschine vor, dort kann man unterschiedliche Ergebnisse reinwerfen. Für die variablen Sachen kann man zwei drei Hebel an der Maschine verstellen, der Rest funktioniert automatisch.
Diese Maschine mit den Hebeln zu bauen ist dass was mit Pipeline, Scripts, etc. gemeint ist. Trichter ist dann dein "Commit der Daten auf einen Branch ins Repository" :P
Geforce3M3
Urgestein
- Mitglied seit
- 28.09.2012
- Beiträge
- 111
Ich weiß, das ist mir klar. Ich drücke das mal als Laie wie folgt aus. Man kann eine Pipeline über zig "if elif else" stages variabel anpassen lassen. Das meinst du, korrekt?
Genau, das ist das Problem. Und ich habe gerade eine Wall of Text geschrieben um zu erklären wie verdammt flexibel das sein muss und man das eben nicht über nen paar parametisierbare Pipelines schaffen kann. Aber dann habe ich den ganzen Text wieder gelöscht weils einfach too much ist und hier eh die wenigsten interessiert. Deshalb glaube mir einfach dass es zu komplex ist und jede Analyse im Endeffekt einzigartig ist, d.h. nicht standardisierbar ist. Ich habe für jede Studie neue Scripts, da ist fast nichts was ich einfach plug and play wieder nutze, auch nicht mit nen paar geänderten Parametersettings. Das ist immer eine endlose Anpassung bis man die Daten so durchgemelkt hat dass man gute Ergebnisse erzielt. Was in dataset A gut funktioniert verkackt in dataset B vollkommen. Klar, bei der Vorverarbeitung der Daten kann einiges ähnlich sein, da kann man eher noch gewisse variable Pipelines bauen wie du sagst, das stimmt. Aber wenn es nacher auf die einzelnen Messungen zugeht wird das sowas von individuell, da ist quasi fast alles immer anders.
sidewinderdxii
Legende
Also am einfachsten ist es eine Woche nachzulesen. Es besteht allerdings die Gefahr, danach blöder zu sein, als vorher.
Es gibt nen Freibetrag pro Arbeitnehmer im Jahr. Auf diesen bezahlt man keine Steuern. Wenn man verheiratet ist, kann man sich gemeinsam veranlagen, dabei werden beide Einkommen und beide Freibeträge zusammengerechnet. Verdient eine Person sehr wenig oder gar nichts, ist das von Vorteil da die zweite Person dann quasi den zweiten Freibetrag mit "aufbrauchen" kann und weniger Steuern zahlt. Die Steuerklassen sind dafür gar nicht so relevant weil das nur regelt ob man diesen Abzug sofort bekommt (also bei der Berechnung vom Arbeitgeber für das Gehalt direkt mehr ausbezahlt wird), oder erst mit der Steuererklärung im nächsten Jahr.
*edit*
Falls du es nicht wusstest, als Single bist du in DE in Stkl1. Nur zur Info, falls du nen Bruttorechner nutzen willst und das da abgefragt wird.
*edit*
Falls du es nicht wusstest, als Single bist du in DE in Stkl1. Nur zur Info, falls du nen Bruttorechner nutzen willst und das da abgefragt wird.