Kleiner Tipp: schaff dir Methodik und Werkzeuge drauf, beides quelloffen als Wissen oder Software verfügbar. 90% der Quereinsteiger scheitern daran, dass sie zwar irgendwie halbwegs programmieren können, aber den Rest nicht (Teamarbeit, Workflow, eigenständige Organisation, Dokumentation lesen und schreiben, Nutzung gängiger Werkzeuge) und der ist mindestens genauso wichtig.
Ich bin auch genau der Typ Quereinsteiger, den Du beschreibst. Ich hab das halt in meinem ersten Job gelernt.
Ja, sehr viele Tools sind Open Source; manche aber auch kommerziell. In beiden Fällen ist es nicht leicht, das alleine im Keller zu lernen; weil du ja keinen Bedarf hast für das große Werkzeug. Und dann unterscheiden sich die Unternehmen eben doch in Ihrer Methodik und den Tools; von außen ist das schwer zu erraten. Deswegen bleiben viele ja auch in ihrer Nische (ein Ökosystem, eine Programmsprache, ein Betriebssystem, eine Branche, eine Cloud). Nicht weil das lernen der Technologie ein riesiges Hindernis wäre, sondern weil es einfach ist einen Job zu finden, wenn man dieselbe Sprache spricht.
Ich würde OP einen anderen Tipp: Ein Skill genügt für den Einstieg. Wenn ein Unternehmen einen Windows-Admin sucht (egal was für fancy buzzwords in der Stellenbeschreibung stehen) und du kannst das oder auch nur überzeugend darlegst, dass du dich einarbeitest, dann hast du gute Chancen.
Du musst nur herauslesen, was sie wirklich suchen. Oft ist der Bedarf gar nicht so groß; man hat halt ein paar offene Stellen, dass man jammern kann. Ne Chef, du bekommst keinen neuen Laptop; da haben wir keine Kappa für.
Hab ich doch gesagt: beides quelloffen als Wissen oder Software verfügbar. Ich hätte noch “im Internet” dazuschreiben können, aber ich dachte, das ist selbsterklärend.
Und dann unterscheiden sich die Unternehmen eben doch in Ihrer Methodik und den Tools
Das kann ich so überhaupt nicht bestätigen. Gerade die großen Unternehmen sind extrem konservativ und nutzen nur die gängigstens Sachen. Mir kommt es nur selten unter, dass ich hier exotische Werkzeuge oder Frameworks im Einsatz sehe und ich arbeite mit mehreren Konzernen völlig unterschiedlicher Herkunft zusammen.
Deswegen bleiben viele ja auch in ihrer Nische (ein Ökosystem, eine Programmsprache, ein Betriebssystem, eine Branche, eine Cloud).
Das tun sie meiner Meinung nach eher deshalb, weil die Felder heutzutage so groß und fragmentiert geworden sind. Es ist einfach viel zu viel, als dass man noch “alles” können könnte und eine Spezialisierung ist immer sinnvoll. Ist ja nicht so, dass Leute mit irgendeiner offiziellen Berufsqualifikation das weniger machen würden.
Nicht weil das lernen der Technologie ein riesiges Hindernis wäre, sondern weil es einfach ist einen Job zu finden, wenn man dieselbe Sprache spricht.
Doch. Gerade mit wenig Wissen über allgemeingültige Strukturen, das man schnell auf neue Domänen anwenden und somit diese effizienter erschließen kann (aka Fachwissen), ist das Lernen von neuen Technologien eine nicht zu unterschätzende Herausforderung. Qualitativ hochwertige Arbeitsergebnisse sind eine Merkmal, das üblicherweise nicht gerade in Hülle und Fülle auftritt, wenn man eine Materie nicht gut für sich erschlossen hat.
Ich würde OP einen anderen Tipp: Ein Skill genügt für den Einstieg. Wenn ein Unternehmen einen Windows-Admin sucht (egal was für fancy buzzwords in der Stellenbeschreibung stehen) und du kannst das oder auch nur überzeugend darlegst, dass du dich einarbeitest, dann hast du gute Chancen.
Das steht nicht gegen das, was ich sagte. Ich sage ja nur: Lerne den Skill gut und auch die Werkzeuge, die du dafür brauchst.
Dinge die ich (System Administrator / DevOps) in den Raum werfen kann:
Generell unabhängig vom Job:
Git, SQL, Bash / Python, Linux, SSH, PGP, Generell Netzwerke (Wie sie funktionieren und wie man Sie konfiguriert.)
Wenn Windows Management dabei is:
Active Directory
Dann Spezifischer
Software Entwicklung (Nicht mein Bereich kanns nur einschätzen):
CI/CD tools. Eine Gängige IDE (VSCode, JetBrains) sicher nutzen können, “Die Sprache in der die Software Entwicklung stattfindet”. “Speicher Management verstehen”, Algorithmen, Datenstrukturen, “Dokumentation schreiben können”, “Kunden und Kollegen beraten können was falsch läuft”, Make / CMake, “Wie funktioniert eine CPU”
Praktisch, schreibe eine kleine Anwendung passend zum Bereich: z.B was Graphisches bei einer Videospielfirma oder einen Datums umrechner für einen Mikrocontroller. Und das Ganze dann über CI/CD tools automatisiert bauen lassen.
DevOps:
Docker (!) (Podman sollte OK sein), CI/CD tools, Kubernetes, Ansible, Mehr Linux, Mehr Netzwerke und Mehr Bash, IT-Sicherheit, “ISO 27001 wird nicht schaden aber kann man auch vor Ort sich holen”, Umgang mit VM’s, Datenbanken, bissl Softwareentwicklung (hängt dann von der Stelle ab).
Praktisch: Einen Docker Service aufsetzten, z.B Selber Nextcloud Hosten, einen Reverse Proxy davor packen. Mikro Architekturen ausprobieren.
Das sind so n Paar Dinge die mir eingefallen sind.
Ich bin an vielen der von dir beschriebenen Fronten unterwegs oder unterwegs gewesen in den letzten 20 Jahren. Ja gut, ehrlich gesagt würfelst du da im Bereich Software-Entwicklung ein paar Dinge rein, die nicht immer und überall erforderlich sind. Configure/Make und CMake braucht man überwiegend dann, wenn man mit C/C++ arbeitet (gibt natürlich Ausnahmen). Ich würde das hier lieber ersetzen wollen durch “Toolchain der jeweiligen Umgebung/Sprache”, denn das schließt gleich Maven, Gradle, Webpack und wie sie alle heißen, mit ein. Und das mit dem Kunden beraten ist ja streng genommen schon wieder Consulting, aber naja, wo zieht man da schon eine klare Linie…
Aber dein praktisches Beispiel finde ich gut, das sagt ja nämlich genau, dass man sich auf einen relevanten Bereich fokussieren soll, wenn man sich bewirbt. Dem stimme ich voll zu.
Podman ist ja ein Docker-Replacement. Ich behaupte mal: wer sich mit Podman auskennt, wird schon wissen, wie es mit Docker funktioniert. Man muss ja erstmal überhaupt wissen, weshalb man Podman überhaupt will oder auch nicht. Sonst aber auch hier volle Zustimmung. Ich würde vielleicht noch Monitoring mit dazu stellen wollen, das ist besonders für den Betrieb wichtig.
Ich spreche nicht von weichen IT-Skills, ganz im Gegenteil. Ich meinte Fachwissen über Standards und standardisierte Werkzeuge. Git ist ein berüchtigtes Beispiel.
dass sie zwar irgendwie halbwegs programmieren können, aber den Rest nicht (Teamarbeit, Workflow, eigenständige Organisation, Dokumentation lesen und schreiben, Nutzung gängiger Werkzeuge)
Gängige Werkzeuge hast du literally zum Schluss einer Liste von weichen Skills genannt und ob gänige Werkzeuge zu beherrschen überhaupt ein harter Skill ist, ist da auch noch lange nicht entschieden. Sei es drum, fassen wir das mal knackig zusammen. Du arbeitest also in einem Unternehmen, das ein Programmiertalent nicht einstellen würde, wenn es keine Git-Erfahrung hat. Wow.
Naja, wenn du das verkürzt darstellen möchtest, wäre das wohl so. In der Realität hab ich das aber nicht gesagt. Weil diese Ebene aber nichts bringt, lass uns gern nochmal darauf eingehen, was ich wirklich gesagt habe, diesmal mit mehr Hintergrund:
Teamarbeit: Kann man in Open Source Projekten erlernen. Hier eignet man sich die nötigen Soft Skills an, um mit anderen zu kollaborieren.
Workflow: Ist für mich vereinfacht gesagt erstmal eine Mischung aus Teamarbeit und Tooling
eigenständige Organisation: Das ist fachübergreifende Kompetenz. Gute Organisation braucht keinen IT-Hintergrund, nützt aber umgekehrt viel vor diesem.
Dokumentation lesen und schreiben: sollte implizit bei vielen der anderen Punkte inbegriffen sein, aber aufgrund der Wichtigkeit guter Arbeitsdokumentation habe ich das nochmal separat angeführt
Nutzung gängiger Werkzeuge: Die Nutzung von git oder ähnlichen Dingen ist für mich ein eindeutiger Hard Skill und lässt sich auch im Vorfeld erlernen.
Und darauf aufbauend nun meine Antwort auf deine Frage: Wenn du dich bei mir bewirbst und noch nie vorher was von Git gehört hast, dann hast du in meinen Augen einige der o.g. Punkte übersprungen und wärst damit in mehrerer Hinsicht a priori aus meiner Position nicht geignet. Du müsstest schon etwas mitbringen, was diesem Manko entgegenwirkt, sonst wäre meine Frage an dich, wie du es geschafft hast, Programmiertalent zu erwerben, ohne dabei jemals Grundvoraussetzungen zu tangieren. Ich habe den Fall aber noch nie erlebt.
Kleiner Tipp: schaff dir Methodik und Werkzeuge drauf, beides quelloffen als Wissen oder Software verfügbar. 90% der Quereinsteiger scheitern daran, dass sie zwar irgendwie halbwegs programmieren können, aber den Rest nicht (Teamarbeit, Workflow, eigenständige Organisation, Dokumentation lesen und schreiben, Nutzung gängiger Werkzeuge) und der ist mindestens genauso wichtig.
Quelle: ich, ehemaliger Quereinsteiger
Und wo lernt man das?
Sagst du ja selber, in einem Team.
Ich bin auch genau der Typ Quereinsteiger, den Du beschreibst. Ich hab das halt in meinem ersten Job gelernt.
Ja, sehr viele Tools sind Open Source; manche aber auch kommerziell. In beiden Fällen ist es nicht leicht, das alleine im Keller zu lernen; weil du ja keinen Bedarf hast für das große Werkzeug. Und dann unterscheiden sich die Unternehmen eben doch in Ihrer Methodik und den Tools; von außen ist das schwer zu erraten. Deswegen bleiben viele ja auch in ihrer Nische (ein Ökosystem, eine Programmsprache, ein Betriebssystem, eine Branche, eine Cloud). Nicht weil das lernen der Technologie ein riesiges Hindernis wäre, sondern weil es einfach ist einen Job zu finden, wenn man dieselbe Sprache spricht.
Ich würde OP einen anderen Tipp: Ein Skill genügt für den Einstieg. Wenn ein Unternehmen einen Windows-Admin sucht (egal was für fancy buzzwords in der Stellenbeschreibung stehen) und du kannst das oder auch nur überzeugend darlegst, dass du dich einarbeitest, dann hast du gute Chancen.
Du musst nur herauslesen, was sie wirklich suchen. Oft ist der Bedarf gar nicht so groß; man hat halt ein paar offene Stellen, dass man jammern kann. Ne Chef, du bekommst keinen neuen Laptop; da haben wir keine Kappa für.
Hab ich doch gesagt: beides quelloffen als Wissen oder Software verfügbar. Ich hätte noch “im Internet” dazuschreiben können, aber ich dachte, das ist selbsterklärend.
Das kann ich so überhaupt nicht bestätigen. Gerade die großen Unternehmen sind extrem konservativ und nutzen nur die gängigstens Sachen. Mir kommt es nur selten unter, dass ich hier exotische Werkzeuge oder Frameworks im Einsatz sehe und ich arbeite mit mehreren Konzernen völlig unterschiedlicher Herkunft zusammen.
Das tun sie meiner Meinung nach eher deshalb, weil die Felder heutzutage so groß und fragmentiert geworden sind. Es ist einfach viel zu viel, als dass man noch “alles” können könnte und eine Spezialisierung ist immer sinnvoll. Ist ja nicht so, dass Leute mit irgendeiner offiziellen Berufsqualifikation das weniger machen würden.
Doch. Gerade mit wenig Wissen über allgemeingültige Strukturen, das man schnell auf neue Domänen anwenden und somit diese effizienter erschließen kann (aka Fachwissen), ist das Lernen von neuen Technologien eine nicht zu unterschätzende Herausforderung. Qualitativ hochwertige Arbeitsergebnisse sind eine Merkmal, das üblicherweise nicht gerade in Hülle und Fülle auftritt, wenn man eine Materie nicht gut für sich erschlossen hat.
Das steht nicht gegen das, was ich sagte. Ich sage ja nur: Lerne den Skill gut und auch die Werkzeuge, die du dafür brauchst.
Das halte ich für ein Gerücht.
Dinge die ich (System Administrator / DevOps) in den Raum werfen kann:
Generell unabhängig vom Job:
Git, SQL, Bash / Python, Linux, SSH, PGP, Generell Netzwerke (Wie sie funktionieren und wie man Sie konfiguriert.)
Wenn Windows Management dabei is:
Active Directory
Dann Spezifischer
Software Entwicklung (Nicht mein Bereich kanns nur einschätzen):
CI/CD tools. Eine Gängige IDE (VSCode, JetBrains) sicher nutzen können, “Die Sprache in der die Software Entwicklung stattfindet”. “Speicher Management verstehen”, Algorithmen, Datenstrukturen, “Dokumentation schreiben können”, “Kunden und Kollegen beraten können was falsch läuft”, Make / CMake, “Wie funktioniert eine CPU”
Praktisch, schreibe eine kleine Anwendung passend zum Bereich: z.B was Graphisches bei einer Videospielfirma oder einen Datums umrechner für einen Mikrocontroller. Und das Ganze dann über CI/CD tools automatisiert bauen lassen.
DevOps:
Docker (!) (Podman sollte OK sein), CI/CD tools, Kubernetes, Ansible, Mehr Linux, Mehr Netzwerke und Mehr Bash, IT-Sicherheit, “ISO 27001 wird nicht schaden aber kann man auch vor Ort sich holen”, Umgang mit VM’s, Datenbanken, bissl Softwareentwicklung (hängt dann von der Stelle ab).
Praktisch: Einen Docker Service aufsetzten, z.B Selber Nextcloud Hosten, einen Reverse Proxy davor packen. Mikro Architekturen ausprobieren.
Das sind so n Paar Dinge die mir eingefallen sind.
Ich bin an vielen der von dir beschriebenen Fronten unterwegs oder unterwegs gewesen in den letzten 20 Jahren. Ja gut, ehrlich gesagt würfelst du da im Bereich Software-Entwicklung ein paar Dinge rein, die nicht immer und überall erforderlich sind. Configure/Make und CMake braucht man überwiegend dann, wenn man mit C/C++ arbeitet (gibt natürlich Ausnahmen). Ich würde das hier lieber ersetzen wollen durch “Toolchain der jeweiligen Umgebung/Sprache”, denn das schließt gleich Maven, Gradle, Webpack und wie sie alle heißen, mit ein. Und das mit dem Kunden beraten ist ja streng genommen schon wieder Consulting, aber naja, wo zieht man da schon eine klare Linie…
Aber dein praktisches Beispiel finde ich gut, das sagt ja nämlich genau, dass man sich auf einen relevanten Bereich fokussieren soll, wenn man sich bewirbt. Dem stimme ich voll zu.
Podman ist ja ein Docker-Replacement. Ich behaupte mal: wer sich mit Podman auskennt, wird schon wissen, wie es mit Docker funktioniert. Man muss ja erstmal überhaupt wissen, weshalb man Podman überhaupt will oder auch nicht. Sonst aber auch hier volle Zustimmung. Ich würde vielleicht noch Monitoring mit dazu stellen wollen, das ist besonders für den Betrieb wichtig.
Ich halte das für keinen guten Rat. Woher nimmst du die Einschätzung, dass 90% der Quereinsteiger an den weichen Computer-Job-Skills scheitern?
Ich spreche nicht von weichen IT-Skills, ganz im Gegenteil. Ich meinte Fachwissen über Standards und standardisierte Werkzeuge. Git ist ein berüchtigtes Beispiel.
Gängige Werkzeuge hast du literally zum Schluss einer Liste von weichen Skills genannt und ob gänige Werkzeuge zu beherrschen überhaupt ein harter Skill ist, ist da auch noch lange nicht entschieden. Sei es drum, fassen wir das mal knackig zusammen. Du arbeitest also in einem Unternehmen, das ein Programmiertalent nicht einstellen würde, wenn es keine Git-Erfahrung hat. Wow.
Naja, wenn du das verkürzt darstellen möchtest, wäre das wohl so. In der Realität hab ich das aber nicht gesagt. Weil diese Ebene aber nichts bringt, lass uns gern nochmal darauf eingehen, was ich wirklich gesagt habe, diesmal mit mehr Hintergrund:
Teamarbeit: Kann man in Open Source Projekten erlernen. Hier eignet man sich die nötigen Soft Skills an, um mit anderen zu kollaborieren.
Workflow: Ist für mich vereinfacht gesagt erstmal eine Mischung aus Teamarbeit und Tooling
eigenständige Organisation: Das ist fachübergreifende Kompetenz. Gute Organisation braucht keinen IT-Hintergrund, nützt aber umgekehrt viel vor diesem.
Dokumentation lesen und schreiben: sollte implizit bei vielen der anderen Punkte inbegriffen sein, aber aufgrund der Wichtigkeit guter Arbeitsdokumentation habe ich das nochmal separat angeführt
Nutzung gängiger Werkzeuge: Die Nutzung von git oder ähnlichen Dingen ist für mich ein eindeutiger Hard Skill und lässt sich auch im Vorfeld erlernen.
Und darauf aufbauend nun meine Antwort auf deine Frage: Wenn du dich bei mir bewirbst und noch nie vorher was von Git gehört hast, dann hast du in meinen Augen einige der o.g. Punkte übersprungen und wärst damit in mehrerer Hinsicht a priori aus meiner Position nicht geignet. Du müsstest schon etwas mitbringen, was diesem Manko entgegenwirkt, sonst wäre meine Frage an dich, wie du es geschafft hast, Programmiertalent zu erwerben, ohne dabei jemals Grundvoraussetzungen zu tangieren. Ich habe den Fall aber noch nie erlebt.