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