Fachkräftemangel - Gründe und Auswege

[0x0A]

vor 6 Minuten schrieb Velicity:

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.

Wenn da 3 Leute für das Unternehmen so wertvoll sind, dann könntet ihr ja verlangen was ihr wollt?!

Fänd ich als Chef ja eher schlecht mich so abhänig von wenigen Mitarbeiten zu machen.

[Rabber]

vor 8 Minuten schrieb Velicity:

...und da das alles so schon 30 Jahre klappt, geht es so auch weiter....

Und da Du auch im wesentlichen darüber redest, warum etwas NICHT geändert werden kann, wer was NICHT bezahlt und wie NICHT wartbar alles ist, lieferst ausgerechnet Du - der sich darüber vehement beklagt - stets die besten Gründe, dass es auch so bleibt. ?

[Th0mKa]

vor 2 Minuten schrieb Errraddicator:

[...], lieferst ausgerechnet Du - der sich darüber vehement beklagt - stets die besten Gründe, dass es auch so bleibt. ?

Sigmund Freud nannte es Projektion

[allesweg]

Man kann einen Monolithen nicht binnen weniger Wochen/Monate mal schnell umstellen. 

Man kann aber sehr wohl einen solchen hinter modernden Schnittstellen "verstecken" und dann langsam aushöhlen. 

Oder aber aus dem Monolithen heraus Funktionalität auslagern und in moderner Architektur implementieren - bis nur noch die blöde Hülle darum existiert.

 

Viele Wege sind möglich - man muss nur schauen, welchen man davon gehen kann - nur das "dürfen" machen kann hier stark bremsen...

[Rabber]

vor 12 Minuten schrieb allesweg:

Viele Wege sind möglich - man muss nur schauen, welchen man davon gehen kann - nur das "dürfen" machen kann hier stark bremsen...

Ich habe auch schon in Betrieben mit starken Controlling, Budgetierung und minutengenauem Tickettracking gearbeitet. Wenn ich der Meinung war, ich musste eine Funktion/Klasse refactoren, dann habe ich das gemacht, ganz ohne jemanden darum zu fragen, nachher sogar entsprechend dokumentiert und das Ticket dauerte eben eine Stunde länger. Diese Stunde am Tag hat man immer zur Hand, auch wenn der Kunde es bezahlen oder man seine Zeit dokumentieren muss. Später habe ich entsprechende Tickets direkt x Stunden höher geschätzt, wenn ich wusste, dass dort viel Aufarbeitung stattfinden wird. Das kann man begründen, das versteht jeder, das bringt was und das bezahlt auch der Kunde, denn der muss ja nichts davon wissen, wenn das Refactoring in Ticket x enthalten ist. Das ist konstruktiv.

Eine Stunde am Tag klingen für sich genommen wenig? Ok, aber sie entspricht bereits 200+ Stunden je Entwickler und Jahr. Da kommt etwas zusammen und genau das macht nach Jahren den Unterschied zwischen unwartbaren und gut gealterten Code, der auch nach 10 Jahren noch funktioniert.

Es ist so einfach wie es klingt: Man muss etwas ändern wollen und nicht bevorzugt Gründe finden, warum es eigentlich gut ist wie es ist und am Stillstand immer die anderen Schuld sind. Wer will, der findet Mittel und Wege, sein Ziel zu erreichen. Wer nicht, der suhlt sich weiter in seinem eigenen Elend. ?

Bearbeitet 7. August 2019 von Errraddicator

[Velicity]

@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.

Bearbeitet 7. August 2019 von Velicity

[JimTheLion]

vor 16 Minuten schrieb Velicity:

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.

Es geht eher darum, die Methoden und Umsetzungen fachlich zu beschreiben um dann eine bessere Umsetzung zu entwickeln.

vor 17 Minuten schrieb Velicity:

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.

"gut umgesetze Sachen" .. "von der Grundüberlegung komplett falsch". Das ist doch schonmal ein Ansatzpunkt! Bei "gut umgesetzt" gehe ich einfach mal von "sauber programmiert" aus, dann sollte es doch nicht so schwierig sein da mall ein paar Sachen zu refactoren. Dann nimmt man dafür halt mal zwei Tage in die Hand, so viel Zeit kann jede Bude irgendwann mal aufbringen.

vor 16 Minuten schrieb Velicity:

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.

Sorry, aber das ist Unsinn.

In welcher Sprache entwickelt ihr denn, dass die interne Implementierungen die externe API verändert? Das kann man doch alles abstrahieren - spätestens sobald man auf Adapter, Proxy oder Facade Patterns aufmerksam wird. Und selbst wenn man nichts dynamisch laden kann, dann ist der Adapter zur neuen Implementierung halt fest verdrahtet, das Interface nach außen ist dann aber immer noch unverändert.

vor 16 Minuten schrieb Velicity:

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.

Ich traue mich fast nicht zu fragen :p

Mit wem da "oben" müssen technische Sachen abgesprochen werden? Kennen sich die entsprechenden Leute mit der Technik aus? Die technischen Sachen gehen meines Wissens nach gerade noch den CTO etwas an, ansonsten müssen noch so ein paar Kleinigkeiten wie Datenschutz usw beachtet werden... aber wer gibt denn bitte die API, Richtlinien oder Sprachen vor?

vor 16 Minuten schrieb Velicity:

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.

Ich verstehe nicht, wie ein Rewrite mit Verzicht "auf ein paar größere Projekte" möglich wäre, wenn an anderer Stelle von mega komplexer Software mit millionen LOC und x verschiedenen Webanwendungen und Apps gesprochen wird. So wie du das bisher immer darstellst, würde ich bei einem Rewrite von Jahren an Arbeit ausgehen. Dass das nicht sinnvoll ist sollte ja recht klar sein, sobald man damit fertig ist kann dann der nächste Rewrite starten.

 

Man könnte da jetzt noch andere Punkte raussuchen... aber ich verstehe es nicht. Das ist immer so eine Diskussion im Kreis... Refactoren geht nicht weil dann nichts mehr läuft oder die Projekte dann still stehen und keiner kann sich in den komplexen Code einlesen und auch kleinere Refactorings bringen nichts weil das System in12sprachengeschriebenwurde3davonwarenschonbeimerstenreleasedeprecatedunddieAppsundWebanwendungensindwahrscheinlichauchallemitCoffeeScriptgeschrieben außerdem mag der Geschäftsführer es nicht wenn man nur kein Pascal nicht nutzt weil sein Sohn auch so heißt.

Ich glaube aber, das weicht auch schon wieder deutlich zu weit vom Thema ab  

[Velicity]

vor 2 Minuten schrieb PVoss:

Es geht eher darum, die Methoden und Umsetzungen fachlich zu beschreiben um dann eine bessere Umsetzung zu entwickeln.

 

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.

vor 5 Minuten schrieb PVoss:

Sorry, aber das ist Unsinn.

In welcher Sprache entwickelt ihr denn, dass die interne Implementierungen die externe API verändert? Das kann man doch alles abstrahieren

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.

vor 15 Minuten schrieb PVoss:

Mit wem da "oben" müssen technische Sachen abgesprochen werden?

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.

vor 16 Minuten schrieb PVoss:

Ich verstehe nicht, wie ein Rewrite mit Verzicht "auf ein paar größere Projekte" möglich wäre, wenn an anderer Stelle von mega komplexer Software mit millionen LOC und x verschiedenen Webanwendungen und Apps gesprochen wird. So wie du das bisher immer darstellst, würde ich bei einem Rewrite von Jahren an Arbeit ausgehen.

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.

[Crash2001]

vor 20 Stunden schrieb JustALurker:

Je nachdem wie umfangreich ein Projekt ist, kann das komplette Neuschreiben fatale Folgen für das Unternehmen haben. Joel Spolsky hat das mal in einem Blogeintrag meiner Meinung nach sehr gut zusammengefasst: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

Aber nur durch Aufarbeiten der Probleme kommt man auf lange Sicht weiter.

@Velicity:
Bringt natürlich auch nicht wirklich viel, wenn nur einer Rewrite der Module macht, sondern das müssten schon mehr Leute machen, damit man dagegen ankommt. Und natürlich müssen da dann auch schon einmal Sachen umgestellt werden, so dass sich für die Kunden etwas ändert.
Dass dein Chef sich den Stress bis zur Rente nicht mehr antun will - seine Entscheidung. Und was ist, wenn er in Rente geht? Hat er irgendjemanden aus der Familie, der den Laden dann übernimmt, oder will er die Firma verkaufen?
Wenn man nur noch seine Zeit absitzen will und die Firma dann verkaufen, dann ist es natürlich verständlich - wobei sie dann vermutlich auch besser verkauft werden könnte, bzw. mehr wert wäre.

 

[Rabber]

Was ist an PL/SQL so schlimm, dass man damit keinen verständlichen Code schreiben könnte?

Natürlich hat man dort keinen Fancy OO-Kram oder cutting edge Design Patterns, aber dafür hast Du einen Code, den so ziemlich jeder Entwickler verstehen sollte, weil es ausserhalb von Funktionen und klassischen Kontrollstrukturen wenig Möglichkeiten gibt. Das ist nicht nur Nach-, sondern auch ein Vorteil. Meiner Meinung nach sogar ein ziemlich großer. Gerade bezüglich der Verständlichkeit für Dritte oder Einsteiger, welche Du stets in Abrede stellst.

Gerade bei PL/SQL sollte ein Refactoring möglich sein, weil die Funktionen überschaubar komplex sind. Das fängt oben an, dann kommen Verzweigungen, Bedingungen sowie Schleifen und hört unten auf. Ideal geeignet, um die eine große, parameterisierte 1.000 Zeilen Funktion in zehn Funktionen zu je 100 Zeilen oder kleiner zu kapseln.

Und da PL/SQL klassischerweise in einer Datenbank liegt, brauchst Du nicht mal groß kompilieren oder Dir Gedanken um das Rollout/Patchen machen. Du schießt die Befehle ab und das Ganze geht live. Besser geht es nicht. Und denjenigen, der Deine PL/SQL-Funktion aufruft, interessiert es genau gar nicht wie diese von innen programmiert wurde und ob Du dort ein refactoring durchgeführt hast oder nicht.

[Velicity]

@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.

Bearbeitet 8. August 2019 von Velicity

[Crash2001]

Ganz ehrlich?
Wenn es von oben so gewünscht ist, dass da nichts dran geändert wird, dann würde ich an deiner Stelle meine persönliche Konsequenz daraus ziehen und auch keine Überstunden mehr leisten, die bei einem verbesserten System nicht mehr notwendig wären. Klar braucht es Zeit für eine Umstellung, aber davon profitiert man danach doch umso mehr - vor allem bei den von dir geschilderten Zuständen und Laufzeiten. Vielleicht würde dann mal bemerkt werden, dass das "historisch gewachsene Konstrukt" einfach nicht mehr sinnvoll wartbar ist und etwas gemacht werden MUSS, damit ihr die Kunden weiterhin behalten könnt.

Ich weiß nicht mehr, was ihr nochmal für Software anbietet, aber mir als Kunde wäre es doch zu doof, minutenlang auf die API zu warten. Da würde ich mir doch auf kurz oder lang eine andere Firma suchen, bei der das Ergebnis schneller zurückgeliefert wird.

[Listener]

vor 15 Minuten schrieb Crash2001:

Wenn es von oben so gewünscht ist, dass da nichts dran geändert wird, dann würde ich an deiner Stelle meine persönliche Konsequenz daraus ziehen und auch keine Überstunden mehr leisten

Und dann gibts es das üppige Weihnachtsgeld nicht mehr - na super.

Bearbeitet 8. August 2019 von Listener

[Crash2001]

Da würde ich eh auf kurz oder lang gesehen mir eine andere Firma suchen, in der meine Leistung geschätzt wird und wo sie nicht als selbstverständlich angesehen wird und zudem der Fortschritt nicht blockiert wird.
Ich meine wenn der Firmeneigentümer die Firma irgendwann dann verkauft, ist eh die Frage, ob dann die Mitarbeiter bleiben können, oder ob der Käufer nur die Kunden haben will und dann z.B. seine eigene Software dann einsetzt.

[allesweg]

@Listener 1x Monitor bearbeiten bitte danke.

 

Es liegt nicht an der Sprache, dass der Code schrecklich ist. Wenn man eigene Datentypen schafft, muss man auch die entsprechenden Methoden für diese schaffen. Entweder man schafft hierfür eine für alle verfügbare generische Implementierung, die verpflichtend einzubinden ist, oder man baut jedes Mal ein neues Vieleck (je mehr Ecken, desto näher am Rad. Dieses Jahr gehen 500 Ecken, vor 3 Jahren waren es nur 42).

[NotKnown]

Back 2 topic? Anyone?

[Showtime86]

https://www.handelsblatt.com/technik/it-internet/bitkom-statistik-124-000-offene-stellen-mangel-an-it-spezialisten-nimmt-dramatisch-zu/25278122.html

 

Da sind wir wieder

Wann werden die "Experten" Gehälter angepasst? Nahezu Jede der mittlerweile 4-5 wöchentlich zugesendeten "Interessanten Möglichkeiten" auf Xing haben Salary Ranges von maximal 65k, bei Banken oder Industrie wenn man Glück hat mal 75k.

Eine Anfrage stach besonders heraus, Consulting Stelle bei pwc. Da hatte ich zuerst gedacht "Wenn ich will und wenn die wollen, gehaltlicher Jackpot!" Und was war? Oh, da müssen wir nochmal mit denen reden, Salary war eigentlich nur bis 70k angedacht. Consulting. Bei pwc. alles klar. Achja, es handelte sich um eine Experten Stelle Bereich Azure.

Bearbeitet 28. November 2019 von Showtime86

[Bitschnipser]

Zitat

Dass Angebot und Nachfrage nicht im Gleichgewicht sind, bestätigen die Preise: Als größtes Problem bei Personalsuche bezeichnen die Unternehmen die hohen Gehaltsvorstellungen der Bewerber (72 Prozent). 52 Prozent sehen eine Diskrepanz zwischen den Forderungen und den Qualifikationen der IT-Spezialisten.

Thema abgehakt. Artikel widerlegt sich selbst.
Wenn es euch so dringend wäre, wären sie euch das Gehalt wert.
Mal wieder die typische "Fake Räfte Mangel"

[Velicity]

Ist doch soweit alles korrekt. Es mangelt an gut ausgebildeten Leuten, die für wenig Geld arbeiten. Ergo muss man dafür sorgen, dass deutlich mehr junge Menschen in die Branche kommen, so kann man die Preise dann nach unten korrigieren, wenn der Bewerber weiß, dass noch 20 andere dort sitzen, die das im Zweifel für weniger machen. Innerhalb diesen Kontext ist der Mangel ja durchaus vorhanden.

Sicher auch durch das Internet, da Leute heute besser informiert sind und man was von den Topgehältern der großen mitbekommt usw. War davor sicher einfacher für die Arbeitgeber.

[Kwaiken]

vor einer Stunde schrieb Showtime86:

"Wenn ich will und wenn die wollen, gehaltlicher Jackpot!"

Das ist ein weit verbreiteter Irrglaube.

Die Big4 zahlen erst ab Senior Manager vergleichbar (~120k). Davor heißt es mit den anderen um die wenigen Managerpositionen in der Tretmühle strampeln; mit viel Arbeit und wenig Geld. Das können die sich leisten, weil ein weiterer Gehaltsbestandteil der Name im CV und die Kontakte zur Industrie sind. "Gehaltlicher Jackpott" bei den Big4 erst ab Director/Partner mit Gewinnbeteiligung.

vor einer Stunde schrieb Bitschnipser:

Thema abgehakt. Artikel widerlegt sich selbst.

Teilweise. 

Wenn ich einen Experten für ein Thema suche und weiß, dass ich ihn voll auslasten kann und der Kunde Summe Y dafür bezahlt, kann ich Ihm kein Gehalt > Y zahlen. Da gibt der Markt für dieses Thema eben nicht den Stundensatz her, den der Bewerber gerne hätte. So einfach ist das.

Meist sieht es jedoch anders aus. Da ist der Wasserkopf im Unternehmen so groß und die parasitären Nutznießer so zahlreich, dass der Kunde mit Summe Y dafür herhalten muss. D. h. Summe Y muss > Gehalt + Wasserkopf + Kosten für "Leistungsträger" sein. Da der Wasserkopf fix ist und das eigene Gehalt die Wichtigkeit der eigenen Person und nicht die Leistung widerspiegelt, dreht man eben an der einzig verbliebenen Variable in der Gleichung: dem Gehalt des Fließbienchens. Und wenn das Fleißbienchen es nicht einsieht, am Ende des Monats nur 25% des eigens erarbeiteten Umsatzes auf seinem Gehaltszettel wiederzufinden, dann nennt man das Fachkäftemangel!

[Kwaiken]

Eine Aussage, die ich spannend finde:

Jährlich wandern rund 180.000 Deutsche aus - und 130.000 kommen zurück.

Von einem "brain drain", also einem dauerhaften Verlust von Fachkräften aus Deutschland, könne man aber nicht sprechen, sagte Andreas Ette vom Bundesinstitut für Bevölkerungsforschung. Es sei eher eine "brain circulation", denn für zwei Drittel der Auswanderer sei der Auslandsaufenthalt zeitlich befristet. Zudem wanderten auch qualifizierte Fachkräfte aus anderen Ländern nach Deutschland ein. "Es gehen die Besten, es kommen aber auch die Besten", so das Fazit der Forscher.

https://www.spiegel.de/karriere/auswandern-deutsche-gehen-laut-studie-vor-allem-fuer-den-job-ins-ausland-a-1299686.html

[Rabber]

Das ist übrigens eine These, welche ich tatsächlich teilen würde.

Auch, wenn der Brain Drain gerne postuliert wird und ich ebenfalls gerne an den Arbeitsbedingungen, der Infrastruktur, Politik, usw. hierzulande mopper, ist das alles nicht schlimm genug, so dass sich die Deutschen in Scharen auf den Weg nach Frankreich, England oder sonst wo hin machen würden. Einen Brain oder Youth Drain gibt es in Deutschland wohl wirklich nicht. Wer so etwas sucht, kann z. B. nach Polen schauen, wo das viel deutlicher messbar ist.

Ob nun "die Besten kommen" ist eine Frage, bei der ich wieder deutlich kritischer bin. Aber das ist ein anderes Thema. ?

[TooMuchCoffeeMan]

Schade, gerade auf diese These, die ich auch sehr interessant finde, geht das Policy Brief nur im Fazit mit zwei Sätzen ein:

Die Ergebnisse zeigen, dass Auslandsaufenthalte meist nur für einige Jahre erfolgen und zeitlich befristet sind. Diese Form internationaler Migration führt gesellschaftlich folglich auf längere Sicht nicht zu einem „brain drain“ – also dem Verlust des gesellschaftlich in Deutschland verfügbaren Humankapitals – sondern zu einer „brain circulation“

Da fehlt mir die Auseinandersetzung mit den Gründen für die "Rückwanderung". Warum ist das so? Wenn der Nettoverdienst und die gefühlte Lebensqualität laut Studie doch der Grund zum Auswandern sind, warum wandern die Leute dann zurück nach Deutschland? Eine Antwort auf diese Fragen hätte mich interessiert.

[Rabber]

Das folgende ist anekdotischer Natur, aber als ich mich mit dem Thema beschäftigt habe, waren die Gründe der Rückwanderer wie folgt:

• Persönliche Natur (Familie, Heimat, etc.)
• Beruflich (das Visum war an die Arbeit gebunden und lief aus) oder
• Weil die Zielländer nach einigen Jahren finanzielle Hürden aufstellen (z. B. teure Kinderbetreuung, Altersvorsorge, Krankheit, etc.), die besonders schwer wiegen, wenn man nicht von klein auf in die dortigen Systeme eingezahlt hat und kein persönliches familiäres/soziales Netz vor Ort hat, was etwaige Lasten auffangen kann.

Die betroffenen Zielländer waren die üblichen Verdächtigen: USA, Kanada, Schweiz und Australien. Was ich dabei nie gehört habe, war dass die Leute wieder zurück nach Deutschland wollten, weil Kultur, Wetter, Landschaften oder Leute so toll wären. Es war fast immer eine Vernunftsrückwanderung.

Ich kann das nicht mit Zahlen untermauern, aber finde, das klingt stimmig.

Bearbeitet 6. Dezember 2019 von Errraddicator

[Maniska]

Was mir bei dem Thema auch immer fehlt ist die Frage wie viele der Auslandsaufenthalte von Anfang an "auf Zeit" geplant waren. Ich könnte mir z.B. durchaus vorstellen für ein paar Jahre ins Ausland zu gehen, aber den Gedanke "für immer" finde ich recht beängstigend (persönliche Meinung).

Tauchen in der Statistik die Grenzgänger eigentlich mit auf (Schweiz), oder zählen die nicht, weil nicht wirklich ausgewandert?