Eure größte Veränderung (Stack/Branche) beim Jobwechsel (Softwareentwicklung)?

[Velicity]

Moin,

mich würde mal interessieren was bei euren Jobwechseln so die größten Veränderungen waren. Seid ihr seit jeher in Unternehmen der gleichen Branche? Oder habt ihr da auch größere Sprünge gemacht und auf angeeignetes Branchenwissen  für die neue Stelle verzichtet. Ggf. weil euch ein anderer Bereich interessiert hat? Oder weil ihr das einfach für Beiwerk haltet, dass man mit der Einarbeitung eh draufkriegt?

Ebenso interessiert mich, in wie weit ihr euren Tech-Stack beim Wechsel geändert habt? Gerade wenn ihr mal was gemacht habt, was nicht gefragt ist und euch eine große Auswahl an Jobs bietet. Immer in der gleichen Sprache geblieben und ggf. nur ein anderes Framework als Fokus? Ein Wechsel in Sprachen mit halbwegs ähnlichen Aufbau ala C# <-> Java. Oder auch mal was komplett unterschiedliches? Quasi von einer stark OOP dominierenden Sprache zu was komplett Prozedurales oder zu was Funktionalen oder eben in die jeweils andere Richtung? Und wie gut war euer Wissen dann in diesen Bereichen? Etwas, dass ihr ggf. mal hier und da im Job zu ein paar Prozent gemacht habt aber mehr machen wolltet? Etwas dass ihr nur ein wenig nebenbei privat gemacht habt? Und wie habt ihr das im Vorstellungsgespräch verkauft? Ggf. auch ein Wechsel der eher weitsichtiger betrachtet wurde und gar finanziell ein Rückschritt war, um in einen Bereich zu wechseln der gefragter ist und mehr Möglichkeiten bietet in Zukunft?

[Funfare1337]

Ich habe bisher Branche und Frameworks gewechselt, nur der Programmiersprache bin ich aktuell treu geblieben (PHP bzw Webentwicklung).

Gelernt habe ich im Energiebereich, dann zu einem kleinen laden mit eigenem CMS für Kommunen gewechselt, dann eine Druckerei und nun bei der Polizei.

Frameworks dann von Zend Framework 1, über selbstgebastelten Kram hin zu Inder-Code, das habe ich selbst zu Laravel transferiert und dem Framework bin ich beim letzten Wechsel treu geblieben.

Die konkrete Branche oder das Framework waren für mich nie so krass der Wechselgrund bzw Auswahlgrund einer Firma.

Branchenwissen kann man sich wieder aneignen. Und war für mich jetzt auch noch nicht so systemrelevant. Ich bin ja nicht der Verantwortliche für den fachlichen Kram. Dafür gibts Product Owner, Fachlichkeit oder wie man es auch immer nennen möchte. Die ganzen Fachbegriffe die eingesetzt werden lernt man irgendwann, auch wie das ganze System tickt. Andererseits war der Blick "von außen", als jemand der noch gar keine Ahnung von dem Thema hat, auch sehr hilfreich. Dann überdenkt man auch mal Sachen, die man schon lange so macht oder halt einfach so akzeptiert hat. Man ist die ersten Monate im normalfall eh nicht produktiv bzw halt gewinnbringend. Man muss das Team, die Technologie, das ganze System, die fachlichen Anforderungen und Begriffe etc lernen, das alles dauert seine Zeit. Und ich bin mir sicher, selbst wenn ich in der gleichen Branche nen anderen Job anfangen würde, müsste ich trotzdem fast alles neu Lernen. Keine Firma tickt genauso wie die andere, es gibt andere Prozesse, Anforderungen, Wünsche und evtl. sogar gleiche Begriffe mit unterschiedlicher Bedeutung, also lernen muss man so oder so.

Bei Frameworks bin ich auch entspannt. Der Wechsel ist nicht so gravierend, klar muss man lernen wie das neue Framework funktioniert. Aber im Kern sind die meisten doch recht ähnlich. Es sind andere Begriffe, manchmal etwas andere Konzepte, aber trotzdem doch ähnlich. Das gilt ja sogar für Programmiersprachen. Kann man Objektorientierung, also hat man verstanden was man da warum wie tut, kann man das auf so ziemliche jede Programmiersprache übertragen. Die Konzepte, Pattern etc. sind die gleichen, die sind abstrakter als die konkrete Programmiersprache. Man muss sich halt neue Syntax und Namen merken (mal mehr mal weniger, Wechsel von C# zu Java ist ähnlicher als C# zu Python, aber ich persönlich mag den Syntax von Python aber absolut nicht)

Was ich gelernt habe in den letzten Jahren, ist viel wichtiger das man ins Team und zu der Arbeitsweise des Teams passt. Ich will sowas wie Versionsverwaltung, Tests, CI/CD und Zeugs außenrum und nicht jeden kleinscheiß per Hand machen müssen. Auch brauche ich einen gewissen Grad an Freiheit, auch mal selbst eine Idee umzusetzen oder mal was auszuprobieren, dass auch fehlschlagen kann. Genauso könnte ich nicht strikt nach Wasserfall programmieren.

Wie gearbeitet wird, wie die Stellung bzw Wertschätzung abläuft und wie man sich selbst entwickeln kann, ist für mich viel wichtiger als welche Branche oder Framework. Lernen musste eh am Anfang wieder viel, da ist auch sowas kein Problem.

[0x00]

Die Unternehmensbranche ist mir relativ egal, meist kommen die Anforderungen eh von einem Product Owner, da brauche ich kein superspezifisches Wissen für. Und wenn doch, das kann man lernen.

Ich hab C# gelernt, hab mich dann für 3 Monate in JS und PHP probiert bis ich gemerkt hab, dass das nichts für mich ist und fang jetzt bald nen Job als DevOpsler/Cloud Heini an.

Zum Zeitpunkt meines ersten Wechsels hatte ich kaum Ahnung von JS und PHP, ich hab dann alles on the fly gelernt bzw. ca 5 (ne da fehlt keine Null) Stunden auch privat investiert. Ich hatte vor meinem zweiten Wechsel schon Kontakt zu sowohl Azure als auch AWS, deren IaC Tools, Cloud First Entwicklung und erstellen von CI/CD Pipelines, bin also halbwegs gut vorbereitet. Trotzdem ist Scripting relativ neu für mich und auch meine Linuxkenntnisse sind eher oberflächlicher Natur.

Frameworks, Programmiersprachen und weiter gefasst auch IT-Systeme sind alle relativ ähnlich bzw. gibt es nur wenige Varianten (z.B. prozedural vs OOP vs funktional). Zudem sind die Grenzen oft schwimmend. Hast du eine verstanden kannst du dich relativ einfach auch in eine andere Einarbeiten.

Im Vorstellungsgespräch hab ich betont was ich kann und wie ich denke, dass ich das einbringen kann. Aber ich habe auch viel Fokus darauf gelegt zu betonen was ich noch nicht kann, wo meine Lücken sind und was ich definitiv noch lernen will.

Wenn man wechselt braucht man immer(!) Einarbeitungszeit, ob neue Sprache oder nicht. Bei einer neuen Sprache ist diese vielleicht länger, aber auch nicht viel wenn man sich ein wenig anstrengt. Man braucht dann aber definitiv einen festen, fachlichen Ansprechpartner und regelmäßige CRs, nur dann funktioniert das optimal. Das ist in vielen Firmen eh schon Standard, wenn allerdings nicht würde ich mir das sehr genau überlegen. Wichtig ist, dass man das ganze Thema offen im Vorstellungsgespräch angeht, damit beide Parteien wissen worauf sie sich da einlassen und damit keine falschen Vorstellungen entstehen.

[Rabber]

Ich war, bin und bleibe Softwareentwickler, in unterschiedlicher Ausprägung. Das kann also Developer sein, aber auch Product Owner oder Team Lead. Aktuell ist es (wieder) letzteres. Je nachdem wie man Branche definiert, bleibe ich dieser also treu.

Betrachtet man hingegen die Branche des Arbeitgebers habe ich quasi mit jedem AG-Wechsel die Branche gewechselt. Am Ende war es allerdings relativ egal, ob mein Code nun für die Industrie, die Pharmabranche oder die Versicherung zum Einsatz kommt. Code ist hier tatsächlich Code.

Das wird höchstens dann interessant, wenn man in Richtung PO/TL schielt, weil man dann viel Kundenkontakt erhält. Aber auch das kann man lernen. Die Anforderungen und Probleme der Digitalisierung sind über die Branchen hinweg ähnlicher als man glauben mag.

—

beim Tech-Stack sieht es hingegen komplett anders aus. Da habe ich von Batch- über Desktop- bis hin zur Webanwendungen schon alles gemacht. Von C# und Delphi, PHP und Angular/TypeScript bis hin zu Java. Von Monolithen mit Millionen Codezeilen über Ein-Mann-Projekte mittlerer Größe bis hin zu Microservices in einer virtualisierten Container-Farm und interdisziplinären Teams.

auch hier fand ich die Änderungen jedoch weit entspannter als man es gemeinhin denkt. Wenn man erst einmal ein paar Jahre auf dem Buckel hat, stellt man fest, dass viele Probleme unterm Strich doch sehr ähnlich sind in der IT. Und wie Ochso weiter oben gesagt hat: Einarbeitung benötigt man immer. 😎

Bearbeitet 12. April 2022 von Rabber