0x00

Doch, auf jeden Fall. Wie willst du sonst mit Legacysystemen arbeiten? Nicht alles ist neu, schön und gut strukturiert. Und was du jetzt schreibst mag dir in 2 Jahren auch wie Spaghetticode vorkommen. So schlimm war der Code auch wieder nicht. Wenn man die ganzen Variablendeklarationen und WriteLn Statements ausklammert, dann bleiben 20-30 Zeilen relativ einfacher Code. Machbar denke ich. Bei diesem Niveau (Variablendeklarationen, WriteLn, If, For und Wertänderungen) benötigt man auch keine Kommentare, die eigentlich dazu da sein sollten zu beschreiben WIESO etwas so ist wie es ist, nicht WAS es macht. Guter Code dokumentiert sich selber und so gut war der Code dann doch.

Rein aus Interesse: Was programmiert man denn so spannendes, wenn man ein "echter" SRE ist?

Wer DNS und VPN nicht kann sollte sich auch nicht Systemintegrator nennen dürfen. Und die Programmieraufgabe... Wir reden hier ja nicht davon irgendwelche Pathfinding Algorithmen in C zu implementieren, nein, es geht um einen for-loop mit Counter. Benötigte Syntax im Beiblatt. Wer das nicht hinbekommt ist noch nicht reif für den Gesellenbrief. Die selbe Schule und die selben Lehrer, die dir nichts beigebracht haben denken also du bist gut? Und darauf gibst du was? Wieso sollten die selben Lehrer, die dir nichts für die Abschlussprüfung beigebracht haben, beurteilen können inwiefern du gut gerüstet für eben diese bist? Finde ich eine sehr naive Einstellung, vor allem wenn gefühlt jeder nur Einsen in der Berufsschule schreibt. Bei einigen Sachen muss ich dir allerdings zustimmen: Auch ich fände ein wenig mehr Transparenz auf Seiten der IHK hilfreich, gerade eine Liste mit relevanten Themen wäre sinnvoll. Ebenso wären öffentliche Kriterien anhand dessen dein Projekt und dessen Dokumentation bewertet werden sinnvoll. Abkürzungen abfragen finde ich auch nur bedingt gut, aber das kann man durchaus als Einserbremse sehen. Von mir aus noch in Ordnung. Und dann das Problem mit den fähigen Lehrern... Gut, welcher fähige und arbeitswillige ITler will auch den ganzen Tag damit verbringen irgendwelchen Halbstarken Adam und Eva zu erklären? Das alles ändert aber nichts daran, dass die Prüfung genauso war wie alle anderen davor: Absolut machbar. Danke!

Ganz ehrlich: Ich finde es gut, wenn die IHK gewisse Anforderungen an angehende Fachinformatiker stellt. Der Zettel ist ja keine Teilnahmeurkunde für 3 Jahre Ausbildung sondern eine Wissensbescheinigung. Und wenn das halt bedeutet, dass 90% der Leute durchrasseln, weil sie den Standards nicht gerecht werden, dann ist es halt so. Die Standards zu senken kann ja wohl nicht die Lösung sein. Ich verstehe aber, wenn Leute sagen, dass es schlechte Kommunikation gibt und teilweise nicht klar ist, was die IHK von einem erwartet. Ich verstehe auch, wenn gesagt wird, dass die Berufsschule nicht alle Inhalte richtig vermittelt. Das finde ich ein sehr großes Problem. Auch fände ich es gut, wenn die Berufsschule deutlich anspruchsvoller wäre. Es ist allseits bekannt, dass die IHK Abschlussprüfung schwieriger ist als die Berufsschule, andersrum wäre es in meinen Augen vorteilhafter. Dennoch haben wir es nicht mit Prüfungen zu tun, bei denen man jede einzelne Frage wissen muss. Wenn man gut gelernt hat, die Kernthemen beherrscht und ein wenig logisch kombinieren kann sind die Prüfungen sehr schaffbar - auch wenn man nicht alles weiß. Vielleicht nicht mit einer 1,0, aber dennoch sehr schaffbar. Wenn FiSis erzählen, dass sie in der Prüfung Probleme mit VPN, DNS, VLANs und DHCP haben, oder AEs, dass SQL und Pseudocode Probleme bereiten, dann ist auch nicht davon auszugehen, dass hier das Problem bei der Schule oder der IHK liegt. Das sind wirklich Standardthemen. Selbst wenn das nicht in Genüge vermittelt wurde sollte dennoch jedem klar sein, dass man das können sollte. Das mit dem Blue/Green Deployment war vielleicht etwas speziell, aber der Angabe und der Grafik war zu 100% zu entnehmen, was hier passiert. Komischerweise sind die Leute, die sich hinterher über Aufgaben oder Zeit beschweren immer die Leute, die 2 Tage vor der Prüfung anfangen SQL zu lernen, Pseudocode auf IHK Niveau als sehr schwierig erachten und darauf pokern, dass Thema X nicht drankommt. Würden diese Leute nur halb so viel Zeit vor der Prüfung in die Vorbereitung stecken, wie hinterher in Beschwerden über eben jene, dann müsste man sich auch nicht beschweren. Ich habe noch nicht alle Prüfungen dieses Jahr gesehen, aber das was ich gesehen habe war echt machbar, wenn man nicht 3 Jahre lang in der Schule geschlafen hat. Klar gab es hier und da mal die Einserbremse, aber eine 2 oder 3 sollte hier jeder erreichen, der sich Fachinformatiker nennen will. Falls man das trotz Lernen nicht geschafft hat, dann hat man nicht gut genug gelernt. Und wenn dann Leute erzählen, dass sie den Bachelor einfacher fanden als die IHK Prüfung, dann frage ich mich eher was für einen Bachelor die bitte machen... Und ihr seid ja auch nicht die Einzigen. Die selbe Diskussion mit der absolut schwersten Prüfung aller Zeiten kommt zwei Mal jedes Jahr. Mit jeder Prüfung. Und guess what? Die Leute vor euch sind auch nicht auf die perfekte Berufsschule gegangen, wurden perfekt vorbereitet oder hatten alle Themen 100% parat. Ich zum Beispiel hatte keine Ahnung, was die IHK eigentlich in Doku + Abschlusspräsentation von mir erwartet und auch im Forum konnte mir damals keiner als AE qualifiziertes Feedback zu meinem Antrag liefern. Mittlerweile gibt es hier mehrere Leute, die so etwas machen, aber dennoch habe ich damals mit einer guten Note bestanden. Von dem was ich in meiner Berufsschulzeit erlebt habe: Ich hätte vermutlich noch deutlich mehr Leute durchfallen lassen.

Und die finde ich wo? Außer in ein paar Monaten beim U-Form Verlag?

Ist das so? Ist Java/.NET denn wirklich so schlecht bezahlt? Ich habe da andere Erfahrungen gemacht, aber vielleicht ist es bei mir noch das ganze drumherum. Man wird nicht zwangsläufig heruntergehandelt und wenn du kein Gehalt angeben musst, dann kannst du auch durchaus mal die Firma fragen, was sie dir denn so bieten können. Basierend darauf kannst du immer noch eine Verhandlung starten (oder akzeptieren). Eine gute Firma kann dir auch von sich aus ein Gehalt nennen. Bewirb dich doch einfach auf alle drei? Anschreiben mit Vermerk, dass du dir alle drei gut vorstellen könntest und gerne im Bewerbungsprozess herausfinden würdest, was dir am Besten liegt. So würde ich es machen.

Richtig. Dennoch kann das am Anfang eine attraktive Option sein um schnell zu lernen was man will und - vielleicht noch wichtiger - nicht will. Langfristig kann Spezialisierung Vorteile bringen, es ist aber wie alles ein zweischneidiges Schwert.

Also wenn du grundsätzlich Bock auf COBOL hast, dann würde ich einfach mal versuchen die Schiene zu fahren. Lesendes COBOL ist schon mehr COBOL als 99% aller Entwickler und die Stellen sind ja so gut bezahlt, weil die meisten Leute absolut gar keine Ahnung von COBOL haben. Insofern dürften deine Chancen - trotz der teilweise fehlenden Erfahrung - gar nicht so schlecht sein. Ich würde es einfach mal versuchen.

Wenn du ein Projekt vorzeigen willst solltest du es meiner Meinung nach richtig machen oder sein lassen. So halbe Sachen kommen nicht gut. Was spricht dagegen eine Anwendung ohne (großes) Frontend zu schreiben, wenn du eh lieber Backend machen willst?

Hoher 6-Stelliger Bereich? 600k+?

Guter Code dokumentiert sich selber! (SCNR)

Ich stehe zu meiner Aussage, ein Cloud Engineer braucht kein Studium. Trotzdem ist was du hier schreibst Käse. Das Ziel eines Studiums ist nicht AWS oder sonst irgendeine Public Cloud zu lernen. Für einen guten Cloud Engineer ist es aber enorm wichtig zu verstehen, wie das ganze "under the hood" funktioniert - um gute, fundierte Entscheidungen treffen zu können. Und ich rede nicht davon den Unterschied zwischen SNS und SQS erklären zu können, abzuwägen ob man Fargate oder EC2 nimmt, oder eine Lambda anzulegen. Mir geht es um viel feingranularere Unterschiede. Wenn du zum Beispiel einen neuen Data Store brauchst, dann kann es Sinn machen die Performance verschiedener Produkte zu vergleichen. Testing ist sicher ein wichtiger Teil davon, ebenso wichtig ist aber zu wissen, wo die Stärken und Schwächen des gewählten Produkts liegen. Hier ist es definitv hilfreich wenn man die zugrundeliegenden Algorithmen & Datenstrukturen für den entsprechenden Data Store kennt. Zudem du dich ja immer im AWS Universum befindest, wenn du AWS lernst. Vielleicht ist AWS aber gar nicht die beste Lösung? Vielleicht kommt AWS an der ein oder anderen Stelle schon an seine Grenzen? Oder du arbeitest in Projekten mit Leuten von AWS ProServ zusammen und musst mit denen auf Augenhöhe diskutieren und deren Lösungen fundiert hinterfragen können? Woher weißt du, dass AWS dir nicht nur irgendwas verkaufen will, obwohl es bessere Alternativen gibt? Wie willst du das herausfinden, ohne zu wissen, wie das ganze tief drin funktioniert? Um das ganze zu lernen braucht man kein Studium, sicher nicht. Aber es kann ein guter Weg dahin sein, kontraproduktiv ist es in keinem Fall. Praxiserfahrung ist auch wichtig, klar, aber nur Praxis kommt irgendwann an seine Grenzen. Ein paar AWS Services in IaC anlegen kann jeder drittklassige Entwickler.

Zum installieren? Ja. Hinterher selbstverständlich nicht mehr.

Für Windows empfehle ich die "Awake" Funktion der Microsoft PowerToys.

Wenn man unbedingt Schätzungen abgeben muss, dann bin ich ein Fan von drei verschiedenen Schätzungen: Best, worst und average case. Die drei können auch identisch sein, aber ein "Wenn X passiert, dann brauchen wir Y Manntage" ist realistischer anstatt pauschal eine Zahl zuzuweisen. Witzigerweise habe ich aber auch die Erfahrung gemacht, dass man sich für eine Deadline (unterbewusst?) mehr reinhängt, einem Task mehr Zeit zuzuweisen resultiert i.d.R. darin, dass er auch länger braucht. Ich glaube bei den meisten ist das noch nicht einmal Absicht, das ist einfach die menschliche Natur. Erlebe ich bei mir selbst auch immer wieder so. Wie @bigvic schon sagte: "Work expands so as to fill the time available for its completion". Es ist aber auch nicht so, als das man dann bis zur letzten Stunde nichts tut und dann auf einmal alles hektisch abarbeitet, ich zumindest versuche Sachen sauberer/besser zu machen, wenn ich weiß, dass ich mehr Zeit habe. Vielleicht refactored man dann mal den anliegenden Code, der einem schon immer ein Dorn im Auge war, anstatt nur die benötigte Funktionalität einzubauen, wenn man zwei Tage mehr Zeit hat. Das ist so nicht richtig: Das wiederrum ist völlig richtig: Habe ich auch so schon ähnlich erlebt. Da waren es keine Selbstständigen, sondern externe Dienstleiser, aber trotzdem. Mein Kollege ist seit fast einem Jahr in einem Kundenprojekt (großes, börsennotiertes deutsches Unternehmen) und laut eigener Aussage hätte er seine gesamte Arbeit in einer Woche erledigen können. Natürlich hat er auch anfangs nachgehakt ob das wirklich notwendig ist, wieso so wenig passiert, wieso alles überschätzt wird, wieso sie dauernd das Rad neu erfinden und zudem am User vorbeientwickeln, das ganze Paket halt. Aber wenn die (vokale) Mehrheit (inkl. Management) das anders sieht, dann hörst du irgendwann auf diese Fragen zu stellen. Es gibt halt sinnvolleres als jedes Mal wieder gegen die gleiche Wand zu rennen. Dennoch ist das ganze auch für ihn sehr frustrierend, er will ja was machen. Stattdessen gibt es einen Haufen überschätzter Bullshit-Tasks. Kein Wunder, dass er mit dem Gedanken spielt die Kündigung einzureichen. Was eigentlich eine gute Überleitung zu den Punkten von @bigvic ist: Ich (und viele meiner Kollegen) träumen davon spannende Aufgaben zu lösen. Wenn ich das nicht haben kann, dann will ich wirklich fürs Nichtstun bezahlt werden. Heißt ich brauche gar nicht aufzukreuzen und kann irgendwas machen. So zu tun, als würde man arbeiten, ist definitv einfach nur extrem frustrierend und wahnsinnig kräftezehrend. Geht oft mit dem ersten Punkt einher und korrelliert stark mit der Anzahl der Meetings. Also ja, definitv. Erstens vielleicht das - je nachdem wie rebellisch man selber ist. Aber selbst der Rebellischste hört irgendwann auf, weil es nichts bringt und einen selbst nur zermürbt. "Love it" oder "Leave it" ist oft einfacher als "Change it". Könnte sein, keine Ahnung. Oft sind das Problem aber auch die Geschäftsleute (sprich Management) selbst. Diese sind ja für einen Großteil der Meetings verantwortlich und damit einer der größten Zeitfresser. Auch kann von der Seite extrem viel Motivation gekillt werden, wenn das Management versucht den Technikern die Technik zu erklären, unnötige Requirements stellt und Micromanagement betreibt. In allen mir bekannten Fällen ist das Management der Hauptverursacher des Problems. Weiß ich nicht. Kommt denke ich ganz stark auf die Person und deren aktuelle Lebenssituation drauf an. Ich kenne mehrere Leute, die nicht lange gefackelt und dann auch gewechselt haben, als sie gemerkt haben, dass sie hier nichts ändern können. Ich kenne aber auch Leute, die immer noch den selben (laut eigener Aussage unnötigen) Job machen oder lange gezögert haben. Kann man so pauschal nicht sagen, aber 100k bei langweiligen oder unnötigen Aufgaben ist halt oft attraktiver als 70k und dafür Bleeding Edge Themen in einem motivierten Team. Wie gesagt, ich habe das Problem zum Glück (aktuell) nicht, kenne aber leider Einige, die genau damit kämpfen. Manchmal kann man etwas ändern, manchmal hilft aber auch nur ein Team- oder Projektwechsel. Wenn es hart auf hart kommt, muss man aber leider Gottes oft zur Kündigung greifen. Das ist oft so tief im Mindset der entscheidenden Personen verankert, da trifft man auf unbewegliche Fronten. "Change it" ist da selten eine Option, bleibt also nur "Love it" oder "Leave it". Und wenn genug Personen "Leave it" wählen, vielleicht findet dann auch irgendwann ein Change statt. Hey, man wird ja noch träumen dürfen...

Nachdem ich das Original gelesen habe muss ich sagen, ich stimme in weiten Teilen zu. Vor allem der Punkt, dass in kleinen Firmen mehr Arbeit getan wird als in Großen würde ich so zu 100% unterschreiben. Je größer das Umfeld, desto einfacher ist es sich hinter der Arbeit anderer Leute zu verstecken. Ebenso fügen die zig Ebenen an Managern über den eigentlichen Arbeitern eher überschaubaren Wert hinzu. Auch wenn alles was @pr0gg3rsagt in der Theorie richtig ist sagt mir meine persönliche Erfahrung etwas anderes. Da wird dann ewig geschätzt, geplant und refined und das immer mit dem ganzen Team, auch wenn das vielleicht nur 2 bis 3 Leute betrifft und der Rest nur zuhört. Und ich frage mich immer warum? Warum ist es wichtig zu wissen wann was fertig ist und wie viel wir noch in den Sprint packen können? Am Besten finde ich da noch SAFe, da werden dann die nächsten zwei Monate geplant und spätestens ab Sprint 2 schießt eh irgendwas quer. Und Gott bewahre den, der dringend was vom SAFe Team braucht. Da muss dann erst ein Task erstellt, geschätzt und priorisiert werden und der wird dann auch allerfrühestens im nächsten Sprint abgearbeitet. Mir gefällt der Kanban Approach den wir mittlerweile fahren besser: Wir ziehen genug Sachen aufs Board, damit alle was zu tun haben und arbeiten einfach nach Prio von oben nach unten. Und wenn nicht mehr genug auf dem Board ist, ziehen wir einfach neue Sachen rein - ganz unabhängig davon welchen Tag wir haben. Refined wird regelmäßig gemeinsam, allerdings wird nur ein kleiner Task Breakdown gemacht, Aufwand wird nicht geschätzt. "It's done when it's done". Was würde ein Aufwand ändern? Wir arbeiten eh nach Prio immer am Wichtigsten. Und wenn was Wichtiges gemacht werden muss, dann wird halt auch mal neu priorisiert. Über Dailies lässt sich meiner Meinung nach streiten, was uns geholfen hat ist zu schauen, dass wir wirklich immer on Topic bleiben und ggf. Diskussionen auf nach dem Daily verschieben. Retros hingegen finde ich super wertvoll, wenn man offen reden kann und die Probleme dann auch angegangen werden. Bei uns hat sich dadurch schon einiges gebessert. Ich bin mittlerweile ganz glücklich in meinem Team, ich kenne aber auch ganz andere Beispiele. Wichtig ist, dass die Teammitglieder Bock auf das haben was sie tun, Entscheidungen gemeinsam getroffen werden (was nicht heißt, dass immer alle d'accord sein müssen) und nicht am User vorbei entwickelt wird. Wenn die letzten zwei Punkte nicht erfüllt sind, dann geht es ganz schnell bergab - erst Recht in Kombination. Tendenziell gilt auch je mehr Management involviert ist, desto schlechter. Management ist dafür da Ablenkungen von außen abzuwehren und dafür zu sorgen, dass das Team richtig arbeiten kann. Sobald es anfängt reinzureden wie gearbeitet werden soll wird's schwierig. Vor allem wenn das Management versucht die Techies zu überstimmen, das killt auch enorm viel Vertrauen und Motivation. Der letzte Punkt von mir ist noch die Teamgröße. Zu viele Köche verderben die Suppe. Ich finde Teams von im Optimalfall 4, maximal 6 Entwicklern gut. Bei allem darüber arbeiten die Leute nicht mehr an den gleichen Sachen, was zur Folge hat, dass man nicht weiß wovon der Andere spricht - gerade für Meetings ist das fatal, weil die eine Hälfte immer schläft. Was ich noch ganz interessant finde sind die Parallelen zu https://medium.com/@pravse/the-maze-is-in-the-mouse-980c57cfd61a

Willst du studieren? Wenn ja, warum? Warum will dein Arbeitgeber, dass du studierst? Ein Cloud Engineer braucht erstmal kein Studium, falls du doch studieren willst würde ich (angewandte) Informatik wählen.

Ich stimme vielem Gesagten hier zu, allerdings fehlt mir bis jetzt eine Option: Quereinstieg als Consultant für Business Intelligence/Data Analytics/Data Engineering. Viele Consultingfirmen suchen händeringend Personal und mit ein wenig Vorbildung (z.B. private Projekte) könnte es sein, dass der Quereinstieg als Trainee klappt. Dir sollte nur klar sein, dass du dann mit "KI" relativ wenig zu tun hast, auch wenn besagte Firmen gerne alles als KI labeln - insbesondere die Recruiter. Lass dir an der Stelle nichts verkaufen. Ich bin mir aber auch nicht sicher inwiefern du überhaupt wirklich was mit KI machen willst bzw dir im Klaren bist, was das bedeutet. Wenn du dich selbst aber eher in die Kategorie "Labertasche" stecken würdest könnte das ganz gut passen. Dass das Ganze finanziell nicht sinnvoll ist sollte aber klar sein. Solltest du es trotzdem durchziehen wollen kenne ich zumindest eine Firma, die für dieses Vorhaben vielleicht eine ganz gute Anlaufstelle ist. Bei ernsthaftem Interesse gerne PN an mich - auch wenn ich persönlich ebenfalls davon abraten würde.

Machst du in deiner Bewerbung klar worum es hier geht? Also das es eben kein Schülerpraktikum ist, sondern 6 Monate geht und du bald danach eine ausgelernte Fachkraft bist? Vielen Firmen dürfte das Konzept eines Umschulungspraktikums schlicht unbekannt sein.

Alternativ dann direkt die 5k nennen. Zwölf mal gibt es das ja in jeder Firma und sollte noch was oben drauf kommen - umso besser!

Und werden die Professoren anhand ihrer Forschung oder ihrer Vorlesungen bewertet? Weil die Forschung deines Professors dürfte für die allermeisten Bachelor- und auch Masterstudenten relativ egal sein. Ist fast wie bei der Berufsschule: Hier (zumindest im Bachelor) geht es darum Grundlagen spannend zu vermitteln. Und ein guter Forscher ist noch lange kein guter Lehrer. Ich bin mal so dreist und stelle die Aussage auf, dass die Uni für deinen Bachelor vollkommen egal ist. Sind eh nur Grundlagen...

Kommt in etwa hin. Ich bekomme nur ~60% mehr als der Rechner ausspuckt!

Bin ich der einzige, der Leute, die Wörter wie "Lowperformer", "Highperformer" und "High-Potentials" unironisch verwenden, nicht ernst nehmen kann?

Oh, da wäre ich mir nicht so sicher. Von unbezahlten Überstunden bis hin zu Weiterbildung in der Freizeit ist mir auch so Einiges aus anderen Berufen bekannt.

Grundsätzlich steht dir alles offen wofür man keinen akademischen Hintergrund braucht. Hier mal ein paar Ideen die alle mehr oder weniger mit Softwareentwicklung zu tun haben: - Weiter Webentwicklung (kann auch spannend sein) - Embedded Engineering - DevOps/SRE oder einfach nur Entwickler mit Schwerpunkt Cloud - Data Engineering oder Softwareentwickler mit Schwerpunkt "Big Data" oder IoT Zeugs - Softwareentwickler mit Spezialisierung auf bestimmte Frameworks oder Sprachen, z.B. Rust, Erlang, Akka usw Schau doch einfach mal die Stellenanzeigen bei dir in der Gegend an und bewirb dich auf das was interessant klingt.