Ich sehe immer mehr Job-Angebote für „Fullstack“-Entwickler, und finde diesen Trend sehr befremdlich. In allen anderen Branchen sieht man eine stärkere Spezialisierung, nur in der IT scheint es die Idee zu geben, dass wir mehr Generalisten brauchen, sowohl in Richtung DevOps (was ich in einem gewissen Umfang noch nachvollziehen kann) oder eben „Fullstack“.
Ganz ehrlich, ich bin ganz gut beschäftigt, bei den aktuellen Entwicklungen in Java dranzubleiben. Natürlich kann ich JavaScript, HTML und CSS schreiben, aber nicht auf einem Niveau, das ich als „professionell“ beschreiben würde. Ich denke auch, dass sich Schwerpunkte, Vorgehensweisen, Konventionen u.s.w. in Backend und Frontend erheblich unterscheiden. Hin und wieder sitze ich auch neben dem „Frontendler“ in unserem Team, und habe ausreichend Respekt vor den Sachen, mit denen er sich so herumschlagen muss. Und auch er ist gut beschäftigt, auf der Höhe zu bleiben.
Jetzt mag es sicher Menschen geben, die so gut sind, dass sie beides virtuos beherrschen, keine Frage. Aber ich denke, die breite Masse kann es nicht. Ich würde soweit gehen und sagen, dass die Code-Qualität und Quantität von zwei Fullstack-Entwicklern im Schnitt einfach schlechter sein muss als die eines Backend/Frontend-Teams, einfach weil es dann weniger Kontextwechsel gibt und sich jeder auf das konzentrieren kann, was einem wirklich liegt.
Was meint ihr, ist das Berufsbild „Fullstack-Entwickler“ objektiv sinnvoll, oder nur Ausdruck einer „ich will bitteschön eine eierlegende Wollmilchsau“-Mentalität seitens der Arbeitgeber?
~ ~ ~ ~
Folgebeitrag, durch Forumsoftware nicht wiederherzustellen:
Fullstack bedeutet nicht, dass du von allem ein bisschen kannst, dafür aber nichts richtig. Es bedeutet, dass du dich in allem relevanten ein bisschen auskennst, aber schon Experte auf einem Gebiet bist.
Bei mir in der haben ALLE Mitarbeiter (vom Entwickler, über die Finanzabteilung bis ins Marketing) ein eigenes T-Shape. Wenn du dir ein “T” vostellst, hast du einen vertikalen Strich in die Tiefe und zwei kleinere horizontale Striche. Der vertikale Strich steht für ein Gebiet in dem du Experte bist (oder werden willst) und die horizontalen stehen für Themengebiete, die dich auch interessieren. Bei mir zum Beispiel ist das in die Tiefe Java-Backend mit Spring, links Frontend-Development und rechts DevOps. Andere Mitarbeiten haben in die Tiefe andere Themen, z.B. Frontend, oder DevOps oder oder…
Bei den Mitarbeitergesprächen wird dann anhand des T-Shape nach Weiterbildungsmaßnahmen gesucht.
Es geht dabei nicht darum, den Super-Entwickler zu haben, der alleine jedes Projekt machen kann, sondern darum dass wir in crossfunktionalen Teams arbeiten und viel mit einander kommunzieren müssen. Da hilft es ungemein, wenn man die gleiche Sprache spricht. Beispielsweise designe ich als Backendentwickler Schnittstellen ganz anders, wenn ich weiß, dass im Frontend eine Flux-Architektur existiert. Oder wenn ich Microservices bauen möchte, kann ich in Zusammenarbeit mit einem DevOps-Engineer eine Docker-Swarm Umgebung aufstellen.
Ich kenne es von meinen vorherigen Firmen auch anders. Da herrschte immer eine “über den Zaun werfen”-Mentalität. So finde ich es aber viel angenehmer zu arbeiten.
Das hört sich schon vernünftiger an, deckt sich aber nicht mit dem, was ich üblicherweise in den Stellenbeschreibungen lese. Da entsteht genau der Eindruck, dass dieser „Super-Entwickler“ gesucht wird. Meine Schlussfolgerung daraus war, dass entweder die Recruiter keine Ahnung haben (wobei inzwischen einige sogar schon gelernt haben, zwischen Java und JavaScript zu unterscheiden, also besteht da noch Hoffnung), oder dass das Unternehmen das tatsächlich so vorsieht, wo meiner Meinung nach nur Stümperei herauskommen kann.
Unser Stack ist an sich sehr schlank (Hadoop, MySQL, etwas Spring, JavaScript mit React), aber unser Produkt beinhaltet jede Menge Konnektoren zu den unterschiedlichsten Systemen (relationale und NoSQL-Datenbanken, Zeugs aus dem Hadoop-Ökosystem, verschiedene Dokumentformate, REST-Schnittstellen u.s.w.) und muss auch mit verschiedensten Sicherheitsarchitekturen der Kunden umgehen können.
Genaugenommen habe ich (in meinem vorigen Job) auch schon frontendseitig programmiert, es war allerdings kein JavaScript, sondern Vaadin - aber das ist dann schon etwas gemogelt, da von „Fullstack“ zu sprechen…
Zuerst mal der Titel und die allgemeine Frage: Das ist auch mein Eindruck. Auch wenn ich nicht wirklich viele Vergleichsmöglichkeiten oder einen „Überblick über den Stellenmarkt“ habe. Also ist alles, was ich sage, subjektiv und vielleicht eingefärbt - aber wer kann bei diesem Thema schon das Gegenteil von sich behaupten?
So ein “Full Stack DevOps-Experte”, wie er ja oft gefordert wird, kann aus meiner Sicht nichts davon richtig können, sondern eben alles nur ein bißchen. Und das ist schlecht (bis verheerend).
oder auch
Es scheint, als hätte der größte Teil der Aufgaben, die (schwammig: ) “Ein Informatiker heute übernimmt” nichts mehr mit Softwareentwicklung zu tun. Stattdessen geht es wohl eher um Bullshit labern, PowerPoints zeigen, Diagramme malen, und das, was wohl gelegentlich als “DevOps” bezeichnet wird, oft wohl noch durchsetzt mit ein bißchen Sekretariatsarbeit, Buchhaltung, Werbung, CRM, und natürlich wird einem im Rahmen des letzteren auch die ehrenvolle Aufgabe zuteil, dem Kunden zu erklären, warum die Software Murks ist (nämlich, weil niemand mehr seine Zeit dafür aufwendet, vernünftige Software zu entwickeln…)
Ich denke, der Aufwand, der betrieben werden muss, um gute Software zu entwickeln, wird gnadenlos unterschätzt. Und die Arbeitsleistung bzw. Qualität wird verwässert, dadurch, dass jemand eine vernünftige Lösung innerhalb von 4 Wochen implementieren kann, aber jemand anderes innerhalb von 4 Tagen eine Lösung implementiert, die vermeintlich das gleiche macht…
Wie du schon sagtest ist es schwierig, in einem Bereich an den Entwicklungen dranzubleiben. (Java 9 Module System anyone?). Die Trennung von „Frontend“ und „Backend“ finde ich dabei manchmal etwas sperrig (als alter Swing-Fan ). Aber im Backend scheinen zumindest einige Sachen etwas „träger“ zu sein (d.h: nachhaltiger). Wenn man sich sowas wie
ansieht, erscheint es fast klar, dass es gar keinen Sinn macht, zu versuchen, ein „React-Experte“ zu werden. Das kommt und geht, morgen wird die nächste Sau durch’s dorf getrieben. Aber das ist nicht (ab)wertend gegenüber den Frontendlern gemeint, im Gegenteil: So ein Framework (schnell) in einer Form zu lernen, die es einem erlaubt, damit „vernünftigen Code“ zu erstellen, ist schwierig.
Man hört und liest immer wieder mal von Leuten, die Sachen sagen wie „Wenn du X kennst, kannste dich in einer Woche in Y einarbeiten“. Man sieht diese Aussage mit (X,Y), die sich stark darin unterscheiden, wie haarsträubend sie sind. Von (Angular, Angular2) über (MongoDB, CouchDB) und (Angular, React) bis hin zu (C++, Java). In den meisten Fällen (und umso mehr, je weiter sie zu den letzteren tendieren) stammen diese Aussagen von selbstherrlichen Idioten, die gnadenlos von sich selbst überzeugt sind, aber von dem, was sie machen, schlicht keine Ahnung haben. Die Anforderung, dass man „schnell Sachen lernt“ bzw. sich „schnell in etwas einarbeiten kann“, kann nur erfüllt werden, wenn man die Latte da entsprechend niedrig legt. (Ich beschäftige mich seit ~20 Jahren sehr viel mir „core Java“, und kann auf die
public static synchronized ArrayList<Customer> x = new CustomerArrayList();
von jemandem, der sich mal kurz in Java eingearbeitet hat, gut verzichten).
(Das schweift wohl gerade etwas ab…)
Ich stimme zumindest zu, dass jemand, der in den letzten 5 Jahren 5 verschiedene Web-Frameworks gelernt und nebenbei mit Java das Bakend von SQL auf MongoDB umgestellt hat, und das ganze aus einer Vagrant-Maschine in 5 Docker-Container verwandelt hat, sicher sein kann, dass da irgendwo eine Zeitbombe aus „zusammengeschustertem Murx“ dabei ist.
Das „Pareto-Prinzip“ von @ionutbaiu mag wie ein gutes Argument klingen. Es gibt da etwas, was ich als „Iteriertes Pareto-Prinzip“ bezeichne: Man weiß, dass man eigentlich nur 80% erreichen kann. Also ist das das, was man antizipiert. Und dann erreicht man 80% - davon. Also insgesamt 64%. Diesen ganzen Aussagen Sinn zu geben scheitert aber daran, dass niemand die Frage beantworten kann, was „80%“ denn sein soll. 80% des Pflichtenhefts? 80% grüne Tests? 80% eingehaltene Sprachkonventionen und Best Practices?
Das T-Shape von @anon65336368 macht auch Sinn. Das hat man ja fast schon automatisch: Man kennt sich immer mit irgendwas besser aus, und mit dem „umgebenden“ Dingen ein bißchen. Aber… ach, ein Bild sagt mehr als 1000 Worte:
Gestern noch SQL gegen ein Postgres geschrieben, dann die config parameter von Postgres optimiert, heute „IX Design“, morgen neue images fuer AWS brennen, zwischen drinnen fuer nodejs Projekte von npm auf yarn umstellen…
„Fullstack“ ist Code fuer „flexibel, macht alles was wir gerade brauchen“.
Nebenbei, „DevOps Engineer“ oder gar „SRE - Site Responsibility Engineer“ ist nix anderes als die Farce von DevOps, genau das Gegenteil eben, anstatt Silos einzustampfen (Operations, Development, …), hat man ein neues Silos eingefuehrt.
Das in den Stellenbeschreibungen immer völlig übertrieben wird ist doch nichts neues. Sich davon nicht abschrecken lassen ist die erste Stufe. Ich sehe in der Praxis das genaue Gegenteil. Aktuell bereiten wir als Team unsere Kunden auf die DSGVO vor bzw wie technische Produkte bestimmte Anforderungen bereits abdecken. Die Produktpalette zieht sich durch den M$ Stack und es ist völlig unmöglich, diesen Stack zu beherrschen. Und tatsächlich tut das bei unseren Kunden auch keiner. Da gibts den Exchange-Spezi, den Sharepoint-Spezi, den Kommunikations-Spezi etc pp. Je nach Erfahrung kennt man die Produkte natürlich auch tiefer. Bei mir genauso. Ich sehe zwar den Security Bereich bei mehreren Produkten aber könnte keines der Produkte komplett alleine betreiben/implementieren. Dafür ist das zu komplex.
Ob das jetzt speziell an diesen Produkten liegt und bei Entwicklern anders ist, kann ich nicht sagen. Aber ich sehe eine extreme Spezialisierung auf Teilbereiche der Informatik.
Die extreme Spezialisierung betrifft eher „Produkte“ deiner Beschreibung nach, und dem kann ich zustimmen, aber auch das gab es schon immer, wer hatte nicht schon
mit einem Oracle DBA zu tun?
Oft sind die ProduktSpezies auch externe bzw. Selbststaendige.
„FullStack“ ist ein Versuch von Firmen wieder etwas mehr „generische“ Entwickler anzustellen, der flexibilitaet wegen.
~ ~ ~ ~
Folgebeitrag, durch Forumsoftware nicht wiederherzustellen:
Deine Aufgaben
Evaluation und Implementierung neuer Technologien, Tools und Prozesse
Co-Design der Systemarchitektur
Entwicklung von Microservices in JEE, Spring, JPA u.a. Sprachen/Frameworks
Entwicklung von SPAs mit Angular/ Vue.js/ React und vergleichbaren Technologien
Dokumentation und Testen von Software
Umsetzung des DevOps-Ansatzes durch Übernahme der kompletten CI/CD Pipeline Konfiguration für bestimmte Module/Feature Sets
Dein Profil
Master/ PhD in Informatik o.ä.
7+ Jahre Entwicklungserfahrung in verschiedenen Sprachen, hauptsächlich JEE u. Javascript
mehrjährige Erfahrung mit Spring, Spring Boot, JEE, JPA, ORM (vorzugsweise Hibernate)
mehrjährige Erfahrung mit plain JavaScript und Angular 2/4
Erfahrungen mit React oder Vue.js und anderen JavaScript frameworks/libraries sind von Vorteil
sehr gute Kenntnisse in relationalen und nicht relationalen Datenbankmanagementsystemen
idealerweise Erfahrung mit Big Data und Event streaming
Interesse an neuen Technologien und künstlicher Intelligenz
analytisches Denken und Problemlösekompetenz
gutes Selbstmanagement & Teamfähigkeit
fließendes (technisches) Englisch ist Bedingung
Ein Senior-Fullstack-BigData-AI-DevOps-Entwickler: Eine eierlegende Wollmilchsau ist da ja ein Scheiß dagegen. Fehlt eigentlich nur noch, dass zwei, drei Nobelpreise vorausgesetzt werden…
). Aber im Backend scheinen zumindest einige Sachen etwas „träger“ zu sein (d.h: nachhaltiger). Wenn man sich sowas wie
