Velicity

Am Ende streiten sich ja alle nur um die Definition und die wird zumindest von der Bundesregierung und Wissenschaft seit gut 20 Jahren so definiert, dass als (Einkommens)reich gilt, wer 200% des äquivalenzgewichteten mittleren Einkommen hat. Rein nach der Wortdefinition, sprich Reichtum als Überfluss bzw. mehr als der Bedarf wären wir ja schon viel früher da. Der Rest sind eben einfach unsere Bilder der Gesellschaft, meist gemessen an Extremen. Da Vermögen nicht richtig erfasst wird und es immer nur um Gehälter geht, reden wir eben eigentlich immer nur von Einkommensreichtum. Das ist es was erfasst wird und da sind die Zahlen nun einmal wie sie sind und darunter sind auch Aussagen korrekt wie reich sind immer die anderen und die meisten ordnen sich falsch ein. Problem ist also wahrscheinlich, dass das Kind meist nicht beim Namen genannt wird und wir eben nicht von einkommensreich sprechen. Also ja jemand mit einem mittleren Einkommen wird jemanden mit dem Doppelten höchstwahrscheinlich als reich ansehen. Derjenige wiederum sieht den über sich als reich etc. pp. Reich/arm usw. sind doch letztlich immer nur Worte die einen Sinn machen, wenn wir vergleichen. Wenn alle gleich viel haben ist keiner reich. Damit ist wohl jeder für sich schlicht die Mitte, sofern es nicht wirklich massiv drückt oder man Geld verbrennen kann, ansonsten wird sich wohl keiner klar als in Armut lebend oder im Reichtum lebend betiteln bzw. keinen finden den er im Vergleich zu sich selbst als reich oder arm ansieht. Wir können natürlich das Ganze auch umdrehen, wenn wir Reichtum so weit weg schieben, dass das erst jemand ist, der Milliarden auf der hohen Kannte hat, sprich zig tausend mal mehr als die Mitte, dann drehen wir das mal in Richtung Armut, sprich wer mehr als ein paar Cent hat, soll sich nicht anstellen, er gehört zur Mittelschicht. Oder vielleicht tut er das doch nicht und wir schieben den Begriff Reichtum ein wenig zu hoch, ebenso wie die obere Grenze der Mittelschicht? Ansonsten reden wir natürlich auch von Regionen. Bei sowas ala für 900k kriegt man kein ordentliches Haus, dafür gibt es im Norden oder Osten eben einen Palast, wo man wahrscheinlich auf Personal angewiesen ist um den Laden sauber zu halten. Das wird natürlich auch nicht im Detail unterschieden in so Berichten. Ggf. wie hier Westen/Osten, eigentlich haben wir in Deutschland aber gut 5-6 Bundesländer die man gruppieren könnte bzgl. Einkommen und Mietpreise und dann natürlich Hotspots innerhalb dieser, die noch mal deutlich raus stechen.

Ist doch diesmal mit der Eingabemöglichkeit da unten sehr gut zu filtern. Die 5.160 Euro gelten da laut Artikel für Paare ohne Kinder. Finde das mal eine vergleichsweise gute Darstellung. Klar auf alles kann man nie eingehen, sonst hat man schlicht keine oder zuwenige Vergleichswerte.

@Crash2001 Genau das ist ja mein Reden. Das muss dann von oben entschieden werden, es brauch entsprechende Richtlinien, woran sich Entwickler, auch die eher nicht so starken lang hangeln können. Wirklich Sinn macht es nur, wenn gute Software schreiben nicht viel schwerer und unbequemer ist, als irgendwas zusammenfuschen bzw. man überhaupt die Möglichkeit dazu hat. So kämpft man eher darum, dass es sich nicht so schnell verschlechtert, als dass man wirklich was verbessert. @Errraddicator Der "Fancy OO-Kram" ist eben oft nützlich, gerade wenn man bei jeden Projekt kundenspezifischen Code in den Core reinferkelt. Den Code dann frei von diesen Sachen zu haben und entsprechende Funktionen übergeben zu können, für kundenspezifischen Code, würde es an vielen Stellen sehr viel einfacher machen. Davon ab müsste wie gesagt auch das Interface der meisten Sachen geändert werden, weil Stand nun Funktionen z.B. mit einem Datensatz arbeiten, intern etliche Abfragen für diesen einen Datensatz ausführen usw. Sprich willst du sowas für 100 verschiedene Daten machen kannst du nicht einfach ein Array übergeben, mit holistischer Abarbeitung arbeiten, sondern hast dann von außen rum eine Loop über deine 100 Sachen, die diese tolle Funktion aufrufen. Sorgt natürlich auch für viele Kontextwechsel und entsprechender Performance. Heißt konkret es ist kein seltener Vorgang, dass du bei uns in der Anwendung auf einen Button klickst und das UI für 5-10 Minuten einfriert und du wartest bis der Kram fertig ist. Daher arbeitet z.B. auch im Fehlerfall keiner von uns mit unserer eigenen Anwendung, sondern alle direkt auf der Datenbank, was auch ein Unding ist. Auch ist so eben nix testbar, da ich nix vorgeben kann. Wenn ich eine dieser größeren Funktionen testen wollen würde, so muss ich erstmal dafür sorgen, dass in 20+ Tabellen stimmige Daten sind. Sprich die Änderung der API ist einfach ein großer Punkt, der viele Sachen besser machen würde. So hast du ein Fehler, kannst reinsteppen, weißt gar nicht welche Daten von welcher Tabelle ausgewertet werden und zu deinen Fehler führen. Intern kannst du natürlich umstellen was du möchtest. Wobei gerade bei den großen Routinen eh keiner weiß was da alles passiert und es sicher auch viele Kombinationen gibt, die so nie gedacht waren, weil sie eben auch über die Daten gesteuert werden und nicht ausschließlich über das was von außen reinkommt. Davon ab möchte ich als Aufrufer auch gar nicht wissen müssen was iMode1 und iMode2, die jeweils 4-5 Modes haben in welcher Kombination was machen und welche der 10 Parameter ich für die jeweilige Kombination füllen muss und in welcher Tabelle welche Datensätze verfügbar sein müssen usw. Weiter geht es dann zum Datenbankschema wo viele Sachen drin sind, die redundant sind, für Fehler sorgen oder schlicht technisch nicht möglich sind mit aktuellen Aufbau aber oft gebraucht werden. Aber auch da gleiche Thema, es würde viele Funktionen im inneren beeinflussen, als auch die APIs, da bestimmte Felder in einigen Tabellen nicht mehr verfügbar wären, sie in anderen wären, ggf. noch Tabellen dazwischen wären usw. Natürlich auch die Gruppierungen in welchen Packages die einzelnen Funktionen sind, was nun ein paar generische Dinger sind ala Tools, Libraries usw. die jeweils hunderte Funktionen beherbergen. Fix ein Fehler bei einer Sache und es wird erstmal etwas kompiliert, was hunderte Rechner betrifft, die Connection Pools sind im Eimer, die Clients müssen neu connecten usw. Konflikte in der Versionsverwaltung macht es natürlich auch nicht seltener. Das Ecosystem ist natürlich auch kleiner. Viele Funktionen, z.B. für Arrays und Strings sind so fertig nicht vorhanden, ergo selbst implementieren. Soviel OpenSource gibt es da auch nicht, also Rad meist neu erfinden. Auch hast du natürlich kein generisches Array. Der eine arbeitet mit einem Array wo drin ein VARCHAR2 Feld ist von TabelleA.FeldB%TYPE, der andere hat eine andere Tabelle, ein anderes Feld, eine andere VARCHAR2 Größe. Wenn du nun eine Funktion zur Sortierung schreibst, dann ist die an dieses Interface gebunden. Du hast also kein ArraySort, sondern ein ArrayTyp1Sort, ArrayTyp2Sort etc. pp. Oder es muss eben jeder zu seinem speziellen Fall zwei Konvertierungsfunktionen schreiben zu einem Standard VARCHAR2 Array, das mit der maximalen VARCHAR2 Größe arbeitet. Oder wir arbeiten alle gleich mit diesen und haben keine Überprüfung auf die erlaube Größe, was dann im späteren Programmverlauf für Probleme sorgt. Es gibt einfach viele Punkte die es einen schwerer machen, sagen wir es mal so. Und das sind ja nur Kleinigkeiten die mir nun On-The-Fly einfallen, da gibt es ja im täglichen Einsatz noch viel, viel, viel mehr. Wie gesagt um kleine Änderungen geht es mir bei dem Ganzen nicht, die mache ich wo ich kann. Mir geht es um große Änderungen. API Umstellen, das als Firmenagenda mal durchziehen, Richtlinien und Tools schaffen, die dafür sorgen, dass der neue Code sauberer ist, das kundenspezifische Sachen entsprechend ausgelagert sind, das man ggf. ein Core hat, den man hirnlos abgleichen kann zwischen den aktuellen Projekten, wo man Fehler nicht per Hand in zig Projekten nachziehen muss, dass man bei neuen Projekten nicht Wochen lang Sonderlocken vom alten Kunden ausbaut, das vor allem große Funktionen testbar sind, so dass man sich wieder traut an diese ran zu gehen, dass die Performance einen akzeptablen Rahmen bekommt. Aber selbst wenn das dann alles optimal innerhalb von PL/SQL gemacht wäre, so findest du doch schwerer PL/SQL Entwickler, als welche für andere Sprachen, gerade ein holistischer Ansatz, anstatt Row-By-Row Abarbeitung ist vielen auch Fremd, die von anderen Sprachen kommen. Davon ab, dass die Performance immer noch bescheiden ist, gerade für Kommunikation mit Partnern die andere Zeiten gewohnt sind, wie SPSn usw. Unabhängig von PL/SQL oder nicht, so oder so gibt es viele Stellen und Entscheidungen, die da über die Verantwortung des einzelnen Entwicklers weit hinaus gehen. Und am Ende gibt es nur zwei Optionen BEI DIESEN Themen. So lassen, weil haben wir immer schon so gemacht oder anpacken, was sich MEINER Meinung nach definitiv lohnen würde und viele Bereiche positiv beeinflussen würde. So wird das Problem eben schlimmer. Die API gibt das was du brauchst nicht her, da will keiner ran, ergo ein Ranzen drum rum, den auch kaum wer kennt und weiß dass es existiert, weil dann irgendwo in einen Job oder Trigger oder was weiß ich kundenspezifisch nochmal was oben drauf passiert oder aus einen String in der Datenbank irgendeine Logik geparst wird oder was weiß ich. Auch hier drehen wir uns aber wieder im Kreis. Ich sage Kleinkram geht, das Problem sind in meinen Augen vor allem die großen Sachen und dann kommt als Antwort Kleinkram geht doch ohne Probleme. Diesbezüglich sind wir uns einig, viele Probleme gehen aber darüber hinaus. Aber am Ende kann ich eh nur jammern, denn entscheiden kann ich das nicht. Ggf. muss ich einfach lernen mich weniger daran zu stören, wenn der Gleiche Mist immer wieder passiert, der dann natürlich auch zu den Sachen führt, die im anderen Thread schon kritisiert wurden, wie Überstunden und ständige Erreichbarkeit.

Mir ging es mit hier um hier im Forum, sorry wenn das missverständlich war. Innerhalb des Unternehmens kommuniziere ich so Sachen, sehr, sehr konkret mit möglicher Lösung oder entsprechenden Ansätzen aber auch inklusive der Konsequenzen. Natürlich kannst du das. Irgendwann will man die API aber auch aufräumen und keine Funktion haben mit 10+ Übergabeparametern, die je nach Fall gefüllt sind oder nicht in Kombination mit iMode1 und iMode2, die Fluss im Programm steuern. Oder ggf. Daten von außen vorgeben, als sie innerhalb der Funktionen aus der Datenbank aus zig Tabellen zusammen zu selektieren. Was die Sprache angeht, wir reden was die Geschäftslogik angeht zu 99% von PL/SQL und 1% von C würde ich sagen. Mit dem Entwicklungsleiter/Geschäftsführer. Ist eben nur ein 10-15 Mann Unternehmen. Dadrüber haste noch den Vorstand aber "mein Chef" sitzt eben keine 10 Meter weiter und der entscheidet wo es lang geht. Ich besitze da schon relativ große Narrenfreiheit und bei allen überschaubaren wird eigentlich fast alles so umgesetzt, wie ich mir das wünsche aber an die großen Probleme will man eben nicht ran. Ich sag nicht 1-2 Projekte skippen und dann haben wir unseren Stand. Eher ein Stand mit den man dann kleinere Projekte umsetzen kann, muss dann eben wachsen. Die Projekte sind hier eh sehr stark kundenspezifisch, am Ende arbeitet man eh nen halbes Jahr am neuen Projekt. Nebenbei kommen ja auch noch Erweiterung, Wartung, Support und alles mögliche rein.

@Errraddicator hier im Rahmen lief das natürlich anders ab. Hier hilft es aber wohl kaum, wenn ich jede Methode und jedes Konzept und jede Umsetzung beschreibe und sage was daran falsch ist und wozu das führt. Mit der Zeit hat sich aber gezeigt das selbst gut umgesetzte Sachen hier aufgrund der technischen Limitierung noch sehr bescheiden sind und viele Sachen eben sehr, sehr tief im System stecken oder von der Grundüberlegung komplett falsch sind. Das sich das in einen halben Jahr ändert, das glaube ich auch nicht und erwarte ich auch gar nicht. Wenn es nach mir geht sehe ich aber ein Rewrite hier am Sinnvollsten. Dafür muss man aber auf ein paar größere Projekte verzichten und das wohl an kleinen Projekten entwickeln und den Funktionsumfang dann Stück für Stück aufstocken. Hängen ja wie gesagt auch andere Probleme dran, dass wir hier zig Sprachen haben, du nicht mal eben paar Kollegen dazu nehmen kannst, wenn nen Projekt droht gegen die Wand zu laufen, sondern das nur mit massiven Überstunden zu retten ist. Da hilft dir kein kleines Refactoring für. Kleine Verbesserungen kommen rein, auf der anderen Seite kommen neue Probleme rein, da bremst du maximal, davon ab, dass an den wichtigen Stellen nur wenige Leute ran können und es eben auch nicht unbedingt gewollt ist, weil i.d.R. was kaputt geht, wenn daran was geändert wird. Ergo kommen 20 Jobs oben drauf die Fehler aufräumen. Die kleinen Sachen mache ich schon nach besten Gewissen und Zeit, die Probleme sind dann aber die großen APIs, technische Limitierung, fehlende Richtlinien usw. Sachen die man gemeinsam bequatschen muss, die von oben beschlossen und abgesegnet werden müssen usw. So kommen natürlich auch viele Probleme nach. Hohe Stundensätze, ergo wird es als wenig Aufwand verkauft. Ergo läuft es hinaus auf Fusch in kostenpflichtig und anschließend als Gewährleistung noch etliche Stunden reparieren, wenn der Kunde Probleme hat. Am Ende ein Kampf gegen Windmühlen, wenn es kein Bruch gibt. Und bzgl. Projektion, dass ich Gründe verstehe heißt nicht, dass ich Sachen richtig finde. Glaube das versteht ihr teilweise falsch. Ich hinterfrage warum jemand so handelt und verstehe das. Mir ist klar, dass große Änderungen bedeutet Projekte ablehnen, weil sonst gar keine Zeit dafür da wäre. Mir ist klar das es dann kein "Weihnachtsgeld" gibt, weder für mich, noch für sonst wen. Ich für meinen Teil würde darauf verzichten. Mir wäre es lieber nicht bei jeden Projekt die gleichen Probleme zu haben. Nicht Wochen lang Sonderlocken vom Leitprojekt ausbauen. Nicht feststellen, dass man doch etliche übersehen hat. Nicht bei jeden größeren Update etliche Probleme einbauen, nicht alles noch langsamer machen, weil man sich an Stellen nicht ran traut, weniger Überstunden, weniger Supportanrufe, was vor allem Nachts angenehm wäre. Für mich wäre mal auf ein paar Tausender verzichten und anschließend mehr Spaß bei der Arbeit haben und das Unternehmen voran bringen können ein Gewinn. Neue Leute suchen und einarbeiten wäre leichter. Man könnte Projekte schneller umsetzen, würde weniger Zeit verschwenden mit Fehlerbehebungen etc. pp. Ich verstehe aber auch wenn mein Chef sagt den Stress tue ich mir die letzten Jahre vor der Rente nicht an und das Geld dran hängt, sowohl Umsatz als auch das Weihnachtsgeld von uns allen. Ebenso das man ein paar Altkunden hat, die man trotzdem noch pflegen muss. Wie gesagt um Kleinkram geht es mir nicht. Da nehme ich mir Zeit, sowohl bei neuen Sachen oder wenn ich über was stolpere. Es gibt aber einfach große Sachen, wo klar ist, dass etwas kaputt gehen wird, wo etliche Leute ihre Aufrufe ändern müssen und kein Mensch auch nur weiß, wo das alles aufgerufen wird und Technologien oder generelle Abläufe ändern ist noch einmal eine ganz, ganz andere Geschichte.

Klingt schön aber wie gesagt schon die Limitierungen der Sprache sind ein großes Problem. Dann der Code der nachkommt, da bräuchte es erstmal Richtlinien und Systeme, das neue Sachen anders gelöst werden, Leute müssten entsprechend erzogen werden. An die großen APIs kann man nicht ran, da darauf zig Anwendungen zugreifen und verschiedenste Leute ihre Anwendungen ändern müssen. Davon ab kommt es da sicher auch zu Fehlern, die auch ihren Weg ins Produktivsystem finden würden. Ist der Kunde natürlich auch nicht amused, wenn ne Stelle kaputt geht, wo eigentlich nix geändert werden soll, weil man es sich wartbarer strickt. Verbessere schon soweit ich kann aber an die Stellen, die wirklich wichtig wären, kann ich so nicht nach eigenen ermessen ran. Und sofern das keiner zahlt, ist eben Finger weg angesagt und da das alles so schon 30 Jahre klappt, geht es so auch weiter. Ist in Summe einfach was, das man größer aufziehen müsste und wie gesagt ich sehe da auch nicht unbedingt den Wert in der aktuellen Codebase/Sprache, kannst eben nur hart verdrahten. Schon alleine weil man bei Projekten sehr unflexibel ist und nur mit Überstunden gegen an kommt und nicht einfach weitere Kollegen dazu nehmen kann, weil die mit anderen Sprachen, IDEs usw. arbeiten.

Gibt sicher immer Risiken und ich verstehe auch meinen Chef, immerhin würde das bedeuten keine Boni usw. will auch keiner bei ohnehin schon niedrigen Gehalt drauf verzichten und eben die auch dort erwähnten Risiken. Fängt aber bei uns schon bei der Sprache an. Starr, imperativ, langsam, sehr langsam. Überhaupt nicht testbar und von 15 Leuten trauen sich ggf. 2-3 an die komplexeren Sachen ran und selbst für uns ist das kritisch, weil ausschließen, dass am Ende gar nix mehr geht kann man schlecht. Gerne riesige Methoden mit mehren Modi, die dann komplett andere Sachen machen usw. Alles auch immer abhängig von aktuellen State der Datenbank, was intern in den Funktionen ermittelt wird. Fehlendes Logging oder an anderen Stellen Exzessives und Unsinniges. Viele Fehler lassen sich kaum erfassen und man darf quasi beim Debuggen 30 Minuten lang zig Variablen rauskopieren um den Fehler nachzuvollziehen. Da steht dann auch gerne mal was anderes, während man debugged. Um viele Probleme wird nen Rucksack drum rum gemacht, weil man sich nicht traut die eigentlichen Problemstellen anzufassen. Macht das System auch immer verteilter, schlechter wartbar und langsamer. Quasi Jobs, die dann die Problemfälle finden und die kaputten Daten hinterher korrigieren.. Benutzerfreundlichkeit, Optik und Geschwindigkeit der UI ist auch kaum funktional. Kryptische Bezeichnungen aus dem Code und Stati gehen teilweise in die UI über, sprich der Benutzer muss was von Stati und Modi verschiedener Funktionen wissen. Und das ganze Datenbankmodel ist auch wenig konsistent, was immer wieder für Fehler sorgt und weit, weit, weit mehr Verantwortung in die Hand des Entwicklers als nötig. Und das sind nur einige Probleme. Datenschutz, Backupkonzept und viele andere Sachen sind auch mäh. Das läuft dann auch alles mit einem Leitprojekt, das den größten Funktionsumfang hat und am meisten Erweiterungen kriegt. Beim neuen Kunden wird das kopiert und angepasst. Natürlich sind da noch 10000 Sonderlocken vom letzten Kunden drin und das fliegt ein jedes mal wieder um die Ohren. Ganz ehrlich, wäre es meine Entscheidung. Rewrite und zwar in einer anderen Sprache, alle hier an einen Tisch holen und langsam mit ein paar kleineren Projekten starten. Gucken welche Sprachen und Technologien Sinn machen. Meiner Meinung nach könnte man leichter Leute einarbeiten, leichter neue Features implementieren, leichter neue Projekte umsetzen und hätte eine deutlich höhere Kundenzufriedenheit. Sind aber vermutlich mittlerweile Millionen von Zeilen an Code, gut 40-50 Prozesse, 20-30 Jobs, nen paar Webanwendungen, ne Android Anwendung und ne C# Anwendung und nen paar alte C Sachen. Aber eh alles Entscheidungen über meiner Gehaltsstufe und leider nicht in meiner Hand. Vielleicht stelle ich mir das auch zu einfach vor, wobei einfach ist es jetzt auch nicht 🤣

Wie es schön aussehen sollte ist keine Frage. In der Realität ist es das aber nicht. Ein Leitprojekt, das schon mit etlichen Sonderlocken, was immer als Clone für neue Projekte genutzt wird. In Summe 30 verschiedene Services, nochmal gut 20 Background Jobs drauf, Nutzereingaben von zig Geräten, hunderte Dialogmasken, verschiedene andere Gewerke die bei jeden Kunden über andere Schnittstellen direkt angesprochen sind, natürlich ohne abstrahierende Schicht dazwischen usw. Und am Ende hängen eben mehre Standorte und zig Leute dran und der Kunde kann ggf. nicht arbeiten wenn es steht. Es ist wirklich ein verdammt riesiger komplizierter Haufen und ja das ist zum großen Teil Schuld des Unternehmens. Ist eben über 20-30 Jahre gewachsen. Wirklich fit sind hier in Summe auch nur 2-3 Leute. Richtig in allen kommt kaum wer rein, so stemmen wir 2-3 den Laden und der Rest kriegt schon sehr leichte Aufgaben und starke Anleitung, auch noch nach vielen Jahren. Was hier falsch läuft dazu habe ich bei uns schon intern in Besprechungen mal ne 30 Seiten Ausarbeitung fertig gemacht. Mal drüber gesprochen, geändert wird aber nix, klappt auch so und ist eben alles zu zeitaufwendig. Denke zwar in Summe würde es sich lohnen, sowohl um neue Leute fixer einzuarbeiten, als auch neue Projekte schneller umzusetzen usw. Aber man denkt eben ans jetzt und da kostet es Geld, schlägt in den Umsatz rein, bedeutet keine Jahresboni usw. Sind eben alles große Baustellen. Aber wie gesagt unabhängig was bei mir im Unternehmen abgeht, es gibt denke ich viele Unternehmen, wo es viel unwartbaren Code gibt. Wenn es dann größere Projekte sind und nicht viele kleine Produkte, dann kommt es eben zu so Problemen.

Das bedeutet nicht, das alles steht, sondern liegt eben am Kunden, der das Ganze nicht analysieren kann. In der Regel werden eben die Keyuser bei der Inbetriebnahme Vorort geschult. Der Kunde stellt aber auch neues Personal ein, dann gibt es stille Post und eine neue Schulung will er nicht zahlen, da ruft er lieber 24/7 hier an. Problem liegt i.d.R. komplett woanders aber genau darum geht es, dass der Mitarbeiter die Kenntnisse brauch um das zu verstehen und diese logische Kette verfolgen kann. Geht dann bis hin zu Firmenpolitik der Kunden und Leute, die an unser System gar nicht bei dürfen, wo du dann in bestimmten Schichten schlicht niemanden beim Kunden Vorort hast usw. Dem widerspreche ich nicht. Bei uns läuft eine Menge falsch, würde mir hier auch vieles anders wünschen aber das will auch keiner bezahlen. Die Kunden gehen ja selbst so noch mit den Rotstift bei. Sparen wollen am Ende alle, der Kunde, das Unternehmen etc. pp. Raus kommt komplexer verfuschter Core, der über 20-30 Jahre gewachsen ist in einer imperativen Sprache und zusätzlich drauf eben immer stark kundenindividuelle Anpassungen und viele, viele verschiedene Schnittstellen zu anderen Anbietern. Die Gründe sind aber auch egal. Groß was ändern kannste nicht, außer alles neu, dann darfst du mehre Welten pflegen und betreuen. Davon ab, dass du erstmal Jahre bräuchtest um dem Funktionsumfang zu implementieren und irgendwo das Geld herkommen muss. Es ändert nix daran, dass es Firmen gibt die einfach Systeme haben, die ein paar Jährchen erfordern, bis du einen größeren Überblick hast.

@Errraddicator Das ist korrekt aber erstmal legt man da drauf. Natürlich kann derjenige erst einmal leichtere Arbeiten ausführen. Dafür könnte man dann aber auch Remote nen Inder für ein paar Dollar am Tag nehmen. Ist natürlich nicht so als dreht man vorher Däumchen oder arbeitet nicht. Aber so Sachen wie den typischen Kundenanruf ala bei uns steht alles kann man dann eben noch nicht analysieren und sich da groß am System lang hangeln, dafür brauch es viel tiefes Wissen. Und das brauch Zeit und Wiederholung. Ebenso Erweiterungen, wenn man das Rad nicht neu erfinden möchte, immerhin muss man wissen, was es alles schon in der Codebase gibt. Ergo wird man bei sehr vielen Sachen noch sehr viel Anleitung brauchen. Oder sage ich es mal so, wenn alle Leute die länger dabei sind zeitgleich für zwei Wochen in den Urlaub gehen und nicht erreichbar wären und nur Leute da wären, die 1-2 Jahre da sind, dann würden bei den Kunden vermutlich so gut wie alle Standorte stehen und die Mitarbeiter hätten quasi kaum eine Möglichkeit daran was zu ändern. Wahrscheinlich bräuchte der Rest anschließend auch nicht mehr aus dem Urlaub kommen. Klar arbeiten die Leute relativ fix mit aber es fängt eben erstmal mit leichten Hilfsarbeiten an. Vollwertige Mitarbeiter sind sie noch lange, lange nicht. Wer nach 2-3 Jahren hier gehen würde, würde so gut wie immer gehen, bevor er das System verstanden hat und alle Kunden betreuen könnte.

Hängt ggf. auch stark von den Stellen ab. Wenn ich hier was lese von 1-3 Jahre, das brauchen hier viele bis sie überhaupt reinkommen. Ist ja neben den eigentlichen Skills, wo man selten 100% der Stellenausschreibung mitbringt, auch das Branchenwissen und ggf. sofern man nicht viele kleine neue Projekte hat, eine riesige Codebase, die ggf. über Jahrzehnte gewachsen ist. Die aktuellen Projekte, ggf. etwas von den alten Projekten, vielleicht übernimmt man Bereiche von einen Kollegen der demnächst geht usw. Wenn hier jeder nach 1-3 Jahren weg wäre, dann würde hier produktiv gar nix mehr geschehen. Danach kommt dann halt irgendwo der kritische Punkt. Für den AG haben wir nun quasi einen super AN, der ideal einsetzbar ist, da er quasi alle Fähigkeiten mitbringt, die benötigt werden. Der AN hingegen hat nix mehr zu lernen und je nach Firmenstruktur keine Aufstiegsmöglichkeiten, Gehalt bewegt sich natürlich ähnlich. Quasi ala so nun könnte ich richtig loslegen, ich bin dann mal weg.

Die Frage ist, solange es diesen Mangel nicht wirklich gibt, immerhin verschenken die Unternehmen ja kein Geld, warum sollte man dann mehr zahlen? Weil die Mitarbeiter alle die persönlichen Freunde sind und man möchte, dass sie ein schönes Leben haben, ggf. genug haben um Teilzeit zu arbeiten oder in Frührente zu gehen und sie nicht nur eine Dienstleistung sind, die man günstig einkauft und teurer verkauft, weil man ein Unternehmen ist und nunja unternehmerisch handelt?

Sehe ich ähnlich. Ebenso ist die Frage wie gut man auf der Strecke durchkommt usw. Für mich ist letztlich der Arbeitsweg nix anderes als unbezahlte Arbeitszeit, die ich da auch noch einmal reinrechnen würde. Wenn man bereit ist umzuziehen, schön und gut. So kann es aber je nach Strecke mit Sprit, Verschleiß und Zeit auch "real" fünfstellig weniger sein. Sofern man nicht sagt Arbeitsweg ist für einen Joyride und in seiner Freizeit würde man eh nix anderes tun als den Tank leer zu fahren.

Werden sicher etwas mehr als 3 sein und so extrem sicherlich auch nicht. Aber eben einmal vernünftig fertig machen und die zwei Absätze im Anschreiben ändern, die firmenspezifisch sind, mehr gibt es bei mir stand jetzt nicht. Da werde ich sicher auch pro Stück 30-60 Minuten brauchen, weil irgendwas zusammenlügen einfach nicht meins ist. Nein trotzdem ist die Motivation eine andere. Wie war das so schön: Wenn ich in 4 Wochen Geld auf dem Konto haben möchte, um meine Miete und was zu futtern zu bezahlen, dann gehe ich eben anders vor, als wenn ich 18 Monate dafür Zeit habe. Und ja man kann die Ersparnisse genauso interpretieren aber für mich ist es ein Unterschied wenn Geld verschwindet, dass ich "besitze" oder ob zusätzliches Geld reinkommt von außen. Da motiviert mich das erste doch deutlicher. Keine Ahnung warum ihr die Sachen immer so in übertriebene Extreme ziehen müsst, es gibt mehr als schwarz und weiß. Aber in dem einen Fall gibt es erstmal nix anderes. In dem anderen ist das immer noch eine wichtige Tätigkeit aber wenn man mal einen Tag was anderes machen möchte und sich wirklich überhaupt nicht um die Jobsuche kümmert, dann ist es irrelevant. Ich rede nicht davon Monate lang die Füße hochzulegen aber man kann eben im direkten Vergleich viel entspannter an die Sache rangehen. Diese schwarz/weiß Geschichte ist mir hier schon ziemlich oft aufgefallen, auch wenn es um Gehälter und co. geht, ggf. eine ITler Krankheit, weil man zuviel mit Logik zutun hat? Auf Meinungen und Erfahrungen lässt sich nicht immer ein richtig oder falsch drauf drücken. Ansonsten ist doch bei allen so und heißt nicht das man etwas absichtlich schlechter oder langsamer macht aber Stress, Angst und co. sind nun einmal Motivationen. Ist bei der Arbeit nicht anders. Wenn ich ein Feature entwickle, dass in einem Jahr fertig sein muss oder ich einen Supportanruf habe, wo beim Kunden alles steht und ich wenige Zeit später den Geschäftsführer dran habe, der mit Verdienstausfällen, Regressansprüchen und sonst was kommt, dann kannst du glauben dass ich schneller tippe, nicht weil ich sonst absichtlich langsam arbeiten würden.. Nun ggf. macht man das vorher? Ich bin auch nach meiner Arbeit nun platt, daher wird alles, was mir in irgendeiner Weise wichtig wäre ab 4-5 Uhr Morgens gemacht, bevor der Alltag beginnt. Davon ab gibt es auch noch ein Wochenende. Wenn die Arbeit anfängt ist der Tag für mich eh so gut wie gelaufen. Wie gesagt wie wild ist so eine Bewerbung? Du hast ggf. zwei Absätze, die du auf den Arbeitgeber zuschneiden kannst und leicht umstellen kannst. An mir, meiner Qualifikation und co. ändert sich von Arbeitgeber zu Arbeitgeber wenig, sprich darf ich nur was anderes zusammenlügen, warum gerade dieser AG so besonders ist und warum ich dahin will. Warum wohl? Weil ich Arbeit suche und die eine Stelle anbieten, der Bereich passt und die Arbeitsentfernung passt. Also denke ich, dass man da vernünftige Unterlagen an einem Wochenende fertig kriegt und jeweilige Änderungen für ein einzelnes Unternehmen dann in 30-60 Minuten gebacken kriegt. Sicher mag Leute geben, die wollen Umziehen, sind vorher von Unternehmen zu Unternehmen gehoppt im Rhythmus von zwei Jahren, das über 20 Jahre, haben Familie dranhängen usw. Alles eine komplett andere Kiste. Ich kann erstmal nur von mir ausgehen. Ich sag auch nicht, dass irgendwer handeln soll wie ich es tue. Ich sage auch nicht mein Weg ist der korrekte. Darauf baue ich nicht, daher lege ich aktuell gut 1/3 meines Gehalts bei Seite, was sowohl bei einer Arbeitslosigkeit oder eben zur Rente greift. Wie gesagt es geht mir nicht darum Sachen Konsequenz zu verweigern aber solange ich mit meinem Geld auskomme, gehe ich nirgendwo hin und sage hier gibt mal ein Formular, ich möchte Xy beantragen. Vermutlich werde ich schlicht solange arbeiten, wie ich kann. Ob es in zig Jahren dann noch eine Rente gibt und ich dann noch lebe steht in den Sternen. Habe stand jetzt auch gar keine Ahnung, wie das mit der Rente läuft und solange ich genug Geld habe, will ich mich damit auch gar nicht auseinander setzen. Wenn ich wirklich bedürftig sein sollte, dann werde ich darauf zugreifen, dafür sind die Systeme da. Wenn ich ~70 sein sollte, nicht mehr arbeiten kann und Geld auf dem Konto bis 150 habe, dann gehe ich das Risiko ein, erstmal mein Geld zu verwenden. Sollte ich dann doch 150 werden, dann geht es dann halt über in die Grundsicherung. Es geht immer nur um das solange ich kann, mache ich, was mir aus eigenen Kräften möglich ist. Das ist für mich nun einmal Option Nr. 1. Wenn das alles bis dahin automatisiert ist und das Geld automatisch auf das Konto kommt, dann ist das schön und gut, dann schicke ich das Geld nicht zurück. Ich werde aber von mir aus nix beantragen oder ähnliches, was ich nicht brauch. Oder kurz gesagt ich behandle das ganze eben als "Bedarf" und nicht als "Anspruch". Wenn ich Bedarf habe greife ich drauf zu aber ich greife nicht aktiv drauf zu, weil ich Anspruch habe, ohne einen Bedarf zu haben.

Kann hier gelöscht werden, übertragen in den anderen Faden.