Rabber

Theoretisch machbar, praktisch wird es schwierig. Da muss man sich schon ins Zeug legen, Vorbehalte überwinden und ggf. die eine oder andere Kröte schlucken.

Grundsätzlich gilt, dass die Beziehung Arbeitgeber <-> Arbeitnehmer keine Ehe ist, in der man sich treu bis in den Tod sein muss. Dein Arbeitgeber sucht Menschen, die X können und Du suchst einen Arbeitgeber, der Dir dafür Y bezahlt und Arbeitsumfeld Z bietet. Das scheint bei Euch aktuell zu passen, heißt jedoch nicht, dass dies auf ewig so bleiben muss. Von daher braucht ein Wechsel nicht zwingend tiefe Gründe, um sinnvoll zu sein. Auch, wenn ich die Meinung von @treffnix nur bedingt teile, hat sie einen wahren Kern. Gerade, wenn Du am Anfang Deiner Laufbahn stehst, ist dieser Ratschlag nicht verkehrt. Ab 30, spätestens 40, würde ich diesen dann jedoch nicht mehr unterschreiben, weil sich das eigene Leben und die beruflichen Spielregeln verändern. Wenn Du also das Bedürfnis verspürst, etwas anderes zu sehen, dann wage den Schritt. Allerdings solltest Du Dir vorher überlegen, was Du von Deinem neuen Arbeitgeber erwartest. "Einfach nur so" oder "weil es neu ist" wird Dich auf Dauer genau so wenig glücklich machen wie bei Deinem aktuellen AG und dann hast Du dasselbe Spiel in 2-3 Jahren wieder. Das ist auch nicht Sinn der Sache.

Vor allem wegen MVVM, Bindings, Templates, Styles und Co.. Das XAML selbst ist ja eher trivial, da wie XML. Die Art, wie man es richtig anwendet hingegen bietet schon massig Fallstricke und Probleme, wenn man es nicht von Beginn an richtig macht.

Gerade XAML ist etwas, bei dem ich kein "learning by doing" empfehlen würde. Auch Stack Overflow und Co. mögen Dir zwar helfen ein konkretes Problem zu lösen, vermitteln Dir aber selten das nötige Wissen, um anschließend eine passende Transferleistung zu erbringen. Ich würde in diesem Fall definitiv dazu raten, einen passenden Kurs zu buchen oder mit jemanden in Verbindung zu treten, der das kann. Also wirklich kann. Bei XAML gibt es so viele Wege, das Ziel zu erreichen, man tritt sehr schnell in falsche Pfade, die einem erst sehr viel später auffallen und dann kaum noch zu korrigieren sind.

Das jetzige Gehalt habe ich eher als Mittel in meinem Sinne eingesetzt. "Aktuell verdiene ich 40k, für 2k mehr wechsel ich nicht, deswegen müssen es schon 45k+ sein" und zwar immer so angepasst, dass am Ende die Beträge bei heraus kommen, die mich interessieren. Das genannte Beispiel würde ich also bringen, wenn ich 40-45k erzielen möchte, weil ich aktuell 35k verdiene. Hier muss man dann natürlich stringent sein und sich dann nicht auf Beträge einlassen, die darunter liegen. Ansonsten funktioniert das nicht.

Genau das. Ich habe schon vor Jahren gesagt und sage bis heute, dass weite Teile der HR überflüssige Jobs sind, die ein Großteil der Unternehmen gar nicht oder zumindest nur in deutlich reduzierter Fassung brauchen würde. Genau das wissen die Betroffenen wohl auch und dies äußert sich in den von Dir geschilderten Fragen und Wichtigtuereien, ohne jeden Mehrwert. Umso schlimmer ist es, dass die HR-Abteilungen häufig so groß, gut bezahlt und einflussreich sein, während dieselben Unternehmen gerne bei Finanzen und Einfluss der Fachabteilungen (welche die eigentliche Wertschöpfung erbringen!) sparen. Ja, ich weiß, Verallgemeinerung und so, aber das hat man leider schon viel zu oft so erlebt und ist jedes Mal aufs Neue nervig.

Das Thema Software Engineering ist eines der üblichen, wenn es um Theorie vs. Praxis geht. In der Theorie finden alle Design Patterns, ordentliche Planung/Vorgehensmodelle, Clean Code, die gang of 4, Unit Tests/Test Driven Development, usw. ganz toll und schwärmen davon. Sobald es dann an die reale Entwicklung geht und der Kunde/Projektleiter/Chef auf seine Anwendung wartet, wird all das gerne über den Haufen geworfen und es muss "schnell, schnell" und "viel, viel" Output generiert werden. Schließlich müssen Deadlines sowie Kosten gehalten werden, Bugs können gefixed werden, Code Quality kann immer noch später kommen (also nie) und die nächste Spaghetti-Software ist geboren. Das habe ich bisher fast ausschließlich so erlebt, egal ob in der 5-Mann-Bude, dem 500 Mann KMU oder 5.000 Mann-Konzern. Der Grund ist auch ganz einfach: Quality Assurance und Code Quality kosten enorme Summen Geld und bringen vordergründig wenig Mehrwert. Das möchte kaum ein Kunde/Chef bezahlen, so dass es hinten rüber fällt. Und selbst die meisten Teamleiter klemmen sich kaum dahinter. Von daher ist dies eine meiner wichtigsten Lektionen, welche ich lernen musste und gerne allen weiter gebe: Die berufliche Softwareentwicklung hat häufig wenig mit dem gemein, was man in der Ausbildung, Fachliteratur, hier im Forum oder auch im Studium vermittelt bekommt. Und am Ende entwickelt kaum ein Unternehmen nach den sinnvollen und schönen Prinzipien, worüber wir Techniker uns den lieben langen Tag streiten. 😎

Als Eignung wird bei uns im Regelfall anerkannt, sobald man wahlweise dieselbe Ausbildung absolviert hat, die man prüfen möchte, oder ein artverwandtes Studium, inkl. Berufserfahrung, vorweisen kann. Ein Benefit ist der weiter vorne genannte Ausbilderschein, was ich nur logisch finde. Somit kannst Du zeigen, dass Du bereits im eigenen Betrieb mit dem Thema vertraut bist. Wann Du die Prüfungen absolvierst, Dokus liest, usw. hängt in erster Linie von Deinem Betrieb ab. Es gibt Betriebe, die Dich für alles genannte bezahlen, also das als Arbeitszeit werten. Das ist der Idealfall, jedoch selten. Dann gibt es welche, die Dich gar nicht unterstützen, wodurch Du alles während Deiner Freizeit, Urlaub, Unbezahlt, etc. absolvieren musst. Das ist der Worst Case und kaum zu stemmen. Das macht folgerichtig auch so gut wie keiner. Oder auch alles dazwischen. Da gibt es keine einheitliche Regelung, das ist Verhandlungssache und musst Du mit Deinem Betrieb klären. Die Vergütung wird gerne von Prüfern und IHK klein geredet, aber so wenig ist das nicht. Da kommen schnell einige hundert Euro je Prüfungsintervall zusammen und da hier Brutto=Netto gilt, ist das ein relevantes Zubrot. Wenn Du viele Prüflinge absolvierst, kann es sogar vierstellig werden. Das kann den einen oder anderen Tag Freizeit wieder gut machen, vor allem wenn Du als Arbeitnehmer noch keine 100k Jahresbrutto verdienst. Je nach Tätigkeit gibt es unterschiedliche Pauschalen (für je eine Doku, je Stunde, usw.), anhand derer wird das berechnet. Nein, Du musst nicht alles wissen und man wächst mit seinen Aufgaben. Das gilt für Azubis genau wie Prüfer. Allerdings solltest Du schon einiges an Erfahrung und Wissen mitbringen, weshalb ich nicht empfehlen würde, direkt nach der Ausbildung Prüfer zu werden, auch wenn man Dich lassen würde. Alleine, weil der Background und das Niveau der Prüflinge so schwankend ist. Da ist von Leuten, die gerade einmal wissen was eine Klasse ist, bis hin zu welchen, die detaillierte Kenntnisse über die Informatik-Theorie dahinter besitzen alles dabei. Von der Desktop- über die Web- bis hin zur Spieleentwicklung, von kleinen bis großen Betrieben, etc.. Da solltest Du mindestens mithalten können und im Idealfall mehr wissen. Natürlich kannst Du Dich als Prüfer im Zweifel auf die Basics der Ausbildung zurückziehen und die Leute dazu etwas fragen, aber das wird den Azubis nicht gerecht, weshalb ich empfehlen würde, erst einige Jahre im Beruf gewesen zu sein und die eine oder andere Fortbildung absolviert zu haben, bevor Du Dich als Prüfer versuchst. Du hast hier eine Pflicht und Verantwortung gegenüber dem Azubi, für den es um sehr viel geht. Das zu verhunzen, weil Du Deine eigene Expertise überschätzt, wäre für den Betroffenen bitter.

Ich hatte bis dato unterschiedliche Modelle. Von Stundenkonten über bezahlte Überstunden (sogar inkl. Aufschlag), Vertrauensarbeitszeit bis hin zu meiner jetzigen Regelung, bei der Überstunden genullt werden. Die Konsequenz daraus ist für mich, dass ich fast keine Überstunden mehr mache. Wenn, dann belaufen sich diese auf wenige Stunden im Monat und auch nur dann, wenn es sich absolut nicht vermeiden lässt. Für mich ist diese Regelung irre, auch aus Arbeitgebersicht, denn ich habe schon mehr als einmal die Arbeit liegen lassen, weil mein Stundenkonto zu voll war und ich wusste, dass es demnächst verfällt. Hätte ich etwaige Überstunden bezahlt bekommen, hätte ich mit Sicherheit die eine oder andere Stunde mehr gearbeitet und beide Seiten hätten etwas davon gehabt: Ich mehr Geld und das Unternehmen einige Patches/Updates mehr. Nun ja, wer nicht will, der hat schon. Die Regelungen verliefen bezüglich des Gehalts so, wie man es erwarten würde: Bei noch ca. 45k hatte ich bezahlte Überstunden, ab ca. 50k Vertrauensarbeitszeit und ab ca. 60k genullte Überstunden. Nachtrag: Bei der Vertrauensarbeitszeit habe ich übrigens ebenfalls keine Überstunden gemacht. Ich hatte einen Vertrag für 40 Stunden die Woche und die habe ich gemacht. Unterm Strich wohl sogar eher etwas weniger als mehr. Man muss es nur zu nutzen wissen und sich selbst keinen Druck gegenüber Kollegen oder Vorgesetzten machen.

@0x00 Ich kann nur für mich sprechen, aber so eine Bewerbung würde bei mir direkt in Ablage P landen. Nicht, weil ich den Humor dahinter nicht sehen würde, sondern weil das am Thema vorbei geht. Du bewirbst Dich nicht als Komiker oder Pausenclown, sondern als Fachkraft bei mir. Und so sollst Du bitte auch auftreten. Ehrlich gesagt mag ich nicht glauben, dass Du mit so einem übertriebenen Humor groß punkten wirst. Die ersten ein, zwei Sätze sind noch völlig in Ordnung und mögen mit Sicherheit eine gewisse Klientel ansprechen. Spätestens ab dem zweiten Absatz wird es jedoch abstrus.

Ich finde das Anschreiben durchaus wichtig und streng genommen wichtiger als Noten in Zeugnissen. Ein "befriedigend" in Mathematik, an einer mir unbekannten Schule, vergeben durch einen mir unbekannten Lehrer, sagt mir schlussendlich fast nichts aus. Ich weiß weder, welcher Stoff dran kam, wie benotet wurde, noch die persönlichen Umständen zu jener Zeit. Im Gesamtbild aller Noten ergibt sich zwar ein Muster, aber Einzelnoten sind fast egal, solange wir nicht von einer ungenügend reden. Und selbst da kenne ich sehr kompetente Softwareentwickler, die in Einzelbereichen tatsächlich eine sechs abgestaubt haben, aber fachlich und beruflich eine Menge Kollegen hinter sich lassen. Bei einem Anschreiben hingegen ist es für mich gänzlich anders. Hier hat der Bewerber die Chance, sich, seine Lage und Motivation zu präsentieren. Verwendet er nur abgeschriebene Floskeln oder textet er selbst? Versteckt er sich hinter Floskeln oder wird er konkret? Ist die Sprache und deren Verwendung auf dem Niveau eines Schülers, Erwachsenen oder Meisters? Nimmt er überhaupt Bezug auf "mein" Unternehmen oder sind wir eine Bewerbung von vielen, ohne jegliche Mühe auch nur den Schein einer Anpassung zu wahren? Ist es glaubhaft, dass er sich für den Job oder unser Unternehmen interessiert? usw. usf. Kurzum: Noten können im besten Fall einen groben Überblick über die Leistungsfähigkeit des Bewerbers geben und sind, gerade bei Noten im Mittelfeld, häufig frei jeder Aussagekraft. Zu viele mir unbekannte Variablen und Maßstäbe spielen hier mit herein. Ein Anschreiben hingegen hat eine von mir verwertbare Aussage, über den Bewerber selbst, seine Lage, Motivation und lässt idealerweise Rückschlüsse auf seine Arbeitsweise/Mentalität zu. Gleiches gilt übrigens für das Foto. Macht sich jemand die Mühe, in ein Fotostudio zu gehen oder nimmt er einen Handyschnappschuss? Ist das Foto im alltäglichen Stil gehalten, professionell oder evtl. sogar zu übertrieben für die eigene Branche?

Verstehe die Intention zwar immer noch nicht, aber ich wünsche Dir viel Erfolg. ?️‍♂️

Muss ein FIAE autodidaktisch erlernen können? Ja, auf jeden Fall. Ein Entwickler, der sich neue Themen nicht mithilfe von Internet, Probieren, etc. beibringen kann, hat ein Problem. Learning by doing ist unser aller täglich Brot und wer z. B. 5 Jahre lang komplett stehen geblieben ist, wird es ggf. schwer haben, noch einmal Anschluss zu finden. Muss ein FIAE alles autodidaktisch erlernen können? Nein, auf keinen Fall. Wie bei so vielen Dingen gibt es Grundlagen, Muster oder Technologien, welche man ordentlich lernen sollte, also mithilfe von Schulungen oder erfahrenen Kollegen, die einem etwaige Fallstricke und Hintergründe erklären können. Learning by doing hat seine Grenzen und die sollte man nicht überschreiten, wenn man nicht nur mit gefährlichem Halbwissen prahlen möchte. MVVM z. B. ist so ein Paradebeispiel dafür oder auch asynchrone Programmierung/Threads.

Das würde ich ebenfalls nicht dramatisieren wollen. Es gibt ganze Berufsgruppen, die auf diesen Modellen basieren und bei denen die Arbeitnehmer am Ende des Monats doch immer noch genug Geld verdienen. Selbst, wenn Du am Jahresende "nur" auf 55k anstelle der 65k kommst, ist das denke ich ein solider Wert. Und in ein paar Jahren fragt keiner mehr nach der Ausbildung, dann kann man im Zweifel etwas anderes, mit weniger variablen Anteilen, suchen.

DevOps ist für mich wie agile Softwareentwicklung. Grundsätzlich eine tolle Sache, in der Praxis viel zu häufig eine Ausrede, um Kosten zu sparen (DevOps) und keine ordentlichen Prozesse/Strukturen bilden zu müssen (Agil) ?

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.

Schimpft sich dann neudeutsch "DevOps" und soll der ganz heiße Scheiß sein. ?

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

@Tiangou Ehrlich gesagt verstehe ich die Frage nicht, wenn Du anschließend doch genau das Problem bestätigst, welches ich ursprünglich beschrieben habe. ? Unter den von Dir geschilderten Bedingungen kann bestenfalls Bewältigung des Tagesgeschäfts stattfinden und keine Weiterentwicklung, die den Namen auch verdient hat. Leider ist das in viel zu vielen Betriebne Realität, weil es vordergründig einfacher, billiger und produktiver ist.

Ich denke, ob Du nun 10, 20 oder 30 Minuten brauchst, ist relativ Wurscht. Wichtig ist, dass es diese Phasen gibt und gerade für Entwickler, um in unserer Branche zu bleiben, ist diese Phase essenziell. Ohne kann man zwar kleinere Bugfixes oder 0815 Arbeit leisten, aber wirklich dolle Dinge kommen so selten heraus. Da wird es in der Realität häufig kritisch, denn dafür sind viele Firmen zu unterbesetzt, Entwickler machen noch Support oder andere Tätigkeiten "nebenbei", welche diese Phase weitgehend unterbinden und dann wundern sich die Chefs, warum die Entwickler kaum produktiven Code zustande bringen und die Produkte auch ein Jahr später kaum vorwärts gekommen sind. Deswegen bin ich dazu übergegangen, nur zu Entwickeln, wenn ich eine hohe Wahrscheinlichkeit sehe, dass ich min. den halben Tag "frei" habe. Wenn ich z. B. in 1,5 Stunden ein Meeting habe, brauche ich davor gar nicht erst mit dem Programmieren anfangen. Das bringt nix. Verstehen aber leider die wenigsten.

Zwei Stunden Fahrt je Strecke finde ich richtig bitter. Das wäre für mich ein Ausschlusskriterium oder müsste mit sehr sehr viel Geld abgegolten werden. Alleine arithmetisch, denn aus einem 8,5 Stunden-Tag (inkl. Pause) wird somit ein 12,5 Stunden-Tag. Rechnet man nun noch das Mehr an KM und die Steuerprogression hinzu, müsste mir der betroffene AG schon fast das doppelte bieten, damit sich das lohnt. Da würde ich wahlweise umziehen oder einen anderen Job annehmen.

Ja, das ist machbar, aber nicht in jeder Region, in jedem Unternehmen und eher selten direkt zu Beginn. Nach einigen Jahren solltest Du allerdings durchaus Chancen haben, das zu erreichen. ?

Wir z. B. betreiben viel Eigenentwicklung und somit muss unser Support sich min. 50% der Zeit damit herumschlagen. Diese Anwendungen kennt vorher keiner und die Kollegen müssen erst eingearbeitet werden, so dass die ersten Wochen eher lernen denn Arbeiten angesagt ist. Woanders betreibt man 08/15 Support zu Windows oder anderer Standardsoftware und erwartet, dass Du ab Tag 1 produktiv helfen kannst, u. A. weil Du Checklisten zur Hand hast, welche Du abarbeiten kannst und sollst, etc.. Ich denke, da können wir Dir wenig zu sagen. Solche Anforderungen unterscheiden sich von Unternehmen zu Unternehmen.

100k+, Home Office und Dienstwagen, bei 3 Jahren Erfahrung, "nur" einer Ausbildung, kaum Reisen, kaum (und bezahlte) Überstunden und das alles ohne disziplinarische Verantwortung? Gehaltserhöhungen von ~15.000 p. a., mehrfach in Folge und das ohne den Job zu wechseln? Da melde ich leise Zweifel an. Wir haben hier und woanders eine Menge Zahlen gelesen, aber das toppt alles, was mir bisher über den Weg gelaufen ist und klingt viel zu gut, um wahr zu sein. Diejenigen, die ähnliche Arbeitsprofile erfüllen, verdienen im Regelfall die Hälfte und diejenigen, die so ein Gehalt verdienen sind Abteilungsleister, schieben Überstunden ohne Ende und/oder nur auf Reisen. Wir alle haben schon Einhörner gesehen und solltest Du so eines sein, gratuliere ich Dir herzlich. Sieh zu, dass Du den Job behältst. Aber Du musst mir verzeihen, dass ich Zweifel hege, weil es - wie weiter vorne geschrieben - schlicht zu gut klingt, um wahr zu sein.

Meiner Erfahrung nach sind Unit Tests und alles was dazu gehört eher nice-to-haves denn gutbezahlte must-have-skills. Die meisten Firmen kennen Testautomatisierung und erzählen auch, wie toll diese ist, aber praktisch und flächendeckend angewendet wird sie dann doch nur selten. Dazu frisst sie zu viel Zeit und Ressourcen, die man im Alltag nur selten übrig hat. Bitte nicht falsch verstehen: Testautomatisierung ist gut, wichtig und richtig. Allerdings eher als ein Skill unter vielen, nicht als der große Schwerpunkt. Die Frage nach dem warum ist übrigens einfach beantwortet: Mit Testautomatisierung verdient keiner Geld, mit produktivem Code hingegen schon. Deshalb ist klar, wo die Prioritäten der meisten Firmen liegen. Und bei Consultants sind die Budgets meist ausgereizt, so dass der Kunde es sich zwei Mal überlegt, ob er noch mal +30% oben drauf legt, nur um mehr Unit Tests implementieren zu lassen. Was anderes ist es übrigens für Dich persönlich, wenn Du in den Bereich Qualitätssicherung gehen möchtest. Dort sind Unit Tests ggf. wichtiger, aber auch nur ein Teil des Handwerkzeugs. Zudem sind dedizierte Testabteilungen wohl noch seltener anzutreffen als Entwickler, die ausgiebige Unit Tests schreiben. ... Die Daten von @Visar unterstreichen meine Aussage, wenn gerade einmal 10% der Stellen JUnit explizit benennen.