Fullstack: Alles ein bisschen, nichts richtig?


#1

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?


Joel Spolsky: "Die Power der Entwickler hat in den letzten Jahren dramatisch zugenommen"
#2

Ich nehme mal an du hast diesen Artikel irgendwo gelesen?

Es gibt da ein paar interessante Punkte, die ich mal lose gekoppelt einwerfen möchte.

Für einen Arbeitgeber ist es klar von Vorteil, wenn alle Mitarbeiter alles können. Ist einer krank dann kann er durch den anderen ersetzt werden.

Benötigt man für alles Spezialisten? Es gibt das Pareto-Prinzip (80/20-Regel). Mit 20% Aufwand kann man schon 80% abdecken. 20% Lernaufwand um 80 prozentiges JavaScript zu können ist doch mal nicht schlecht und reicht ja an vielen Ecken und Enden. Da braucht es den Spezialisten nur noch für die Spezialfälle. Zudem kann man die Strategie auch so wählen, dass man die Spezialfälle vermeidet.

In dem Artikel geht es unter anderem um Adam Smith (Wealth of Nations). Es ist klar, dass ein Team das die Arbeit aufteilt, effektiv ist und viele Nadeln herstellt. Was ist aber wenn ich nur eine Nadel benötige? Lohnt sich dann einen Prozess zu erstellen der genauso effizient ist? Und wenn man heute den Markt beobachtet, dann kann man auch seine Nadel irgendwo kaufen. Für einen Developer sind dies Bibliotheken, Frameworks, SaaS, PaaS, Serverless usw. Dies macht es auch, wenn man ein Problem hat! und sich eine (1!) Lösung dafür raussucht, die das Problem löst auch einfach, das ganze zu erlernen und zu beherrschen.

Wie sieht der Stack aus? Typisch wäre zum Beispiel Frontend, Backend, Storage. Beim Backend gibt es schon die Varianten JEE, Spring oder ein Micro-Framework.
Beim Frontend, z.B. Serveranwendung oder SPA. Hier dividiert es sich dann in Angular, React, Vue, Legacy, Vanilla/WebComponents. Und beim Storage wenn man nur bei SQL bleibt, hat man Plain-SQL oder einen OR-Mapper. Dies dann mit Stored-Procedures für Oracle, MSSql oder ohne. Wenn man alles in Perfektion können möchte und bei SQL, dann auch die Sachen beherrschen will die ein Lukas Eder so zeigt. Dann wird man wohl niemanden finden. Geht man aber dazu über das ganze zu reduzieren, dann bekommt man einen Stack der so aussieht: React, Jax-RS, JPA. Das ist meiner Meinung nach ganz gut beherrschbar und auch ein Full-Stack. Und dass kann auch in diversen Details noch einigermassen erlernt werden. Die Firma muss dann aber die Stabilität bieten, dass nicht jedes Projekt auf einem anderen Gaul geritten wird.

Java Desktop ist ähnlich.Swing, JavaFX und Eclipse RCP wird kaum jemand parallel einsetzen und in alle untiefen beherrschen. Wenn eine Firma sich aber festlegt, Eclipse zu verwenden, dann braucht man nicht mit Swing anfangen. Man kann dann auch davon ausgehen, dass jeder der GUI kann, dann auch Eclipse kann.

DevOps kommt daher, dass man möchte, dass ein Entwickler von der Anforderungsanalyse bis zum Betrieb hin alles macht. Teilt man es auf verschiedene Personen auf, dann kommt da unter Umständen Stille-Post raus. Damit hat jeder der Schritte einen Kontext, während man bei einzelnen Spezialisten und einer aufgeteilten Arbeit jeden Arbeitsschritt isoliert und so den Kontext verliert oder gar explizit ausschaltet. Wenn der GUI-Mann jede Sekunde called, dann triggert er damit einen Thread im Backend und eine Querry in der DB. Merkste erstmal nicht ausser dass der Server bei Last kotzt. Wenn in der GUI zum Beispiel ein Listener wartet der einen Event erwartet, dann ist das viel mehr Arbeit für den GUI-Mann. Im Backend passiert allerdings nichts so lange nichts zu berichten gibt. Dazu braucht es aber Full-Stack oder eine gute Kommunikationsstruktur/kultur.

Zusammengefasst: Wenn man den Stack gut beschreiben kann und in der Breite reduzieren kann, dann ist Fullstack durchaus möglich, sinnvoll und in der Tiefe/Qualität auch ausreichend gut zu beherrschen. Für die Spezialfälle, wenn sie sich nicht vermeiden lassen wird man wohl immer noch auf einen Spezialisten zurückgreifen wollen.

Wie sieht denn ein Stack bei dir aus Landei? Oder gibt es da verschiedene Stacks?


In dem Artikel wird auch noch Powerpoint beschrieben. Ja soll den tatsächlich ein Team aus Verhaltenspsychologe, Designer, Sekretär(in) und Domainspezialist gemeinsam vor einem Rechner sitzen und Folien zusammenhacken? Wollen die das nacheinander machen und dann hin und herschieben? Und was macht ein Kleinstunternehmer, der da alleine vor sich herwerkelt?


#3

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.


#4

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…


#5

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?

Angeklungen sind einige Aspekte dieser Frage auch schon in Beruf: Softwareentwickler. Gibt es das? , z.B.

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 :roll_eyes: ). 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 @ButAlive 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:

TShape


#6

Ganz genau das heisst das :slight_smile:

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

http://www.commitstrip.com/en/2016/11/07/which-full-stack-developer-are-you/

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.


#7

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.


#8

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.


#9

Zu deinem T-Stack Diagramm möchte ich noch was hinzufügen.

Irgendwann kamen ja Microservice-Architekturen in Mode. Da ging man irgendwann dazu über, den Devs zu sagen, nutzt was immer ihr möchtet, Sprache, Framework alles ist möglich. Einschränkung war das man einen Kollegen gefunden hat, der das ganze auch kann um ein Backup zu haben und dass es nicht allzu exotisch wird. Hintergrund war, dass man wirklich eine Shared-Nothing-Architektur bekommt. Und da es ja Microservices sind, sind diese so klein, dass man diese auch immer wieder in einer anderen Sprache neuschreiben kann, ohne dass der Laden dabei pleite geht.

Resultat waren dann so Geschichten wie, Chad Fowler bei Wunderlist, der dann so einen Stack hat (22:18)

Und das kommt dem T-Shape, dass die Recruiter suchen schon sehr nahe.

Das Gegenbeispiel ist Amazon. Die haben ebenfalls eine Microservice-Architektur aber eine homogene Plattform auf der alles läuft. AWS und das steht auch allen anderen offen die möchten. Wikipedia hat da einen kleinen Überblick https://de.wikipedia.org/wiki/Amazon_Web_Services

Jedenfalls kann man dann bei Amazon selbst davon ausgehen, dass jeder Microservice auf dem selben Stack läuft. Der Unterschied wird dann erst in der Fachlichkeit sichtbar. Am Schluss bleibt ein Stack, der sogar recht schlank ist. (Auf AWS kann man mit vielen Sprachen arbeiten, aber wenn man das ganze auf zum Beispiel Java reduziert, dann bleiben da nicht mehr allzuviele Variationsmöglichkeiten)

Google App Engine / Google Cloud sieht/sah ähnlich aus. https://de.wikipedia.org/wiki/Google_App_Engine
Es gibt eine Infrastruktur die eine Api nach aussen bereitstellt. Wenn man diese nutzt, dann nutzt man die eben und alles ist gut. Für die Persistenz gibt es Big Table Punkt. Da wird nicht lange diskutiert, welche SQL-DB oder doch NoSql-DB genutzt wird oder gar in welcher Konfiguration. Dass da im Hintergrund natürlich mehr abläuft um überhaupt die Persistenz bereitzustellen ist auch klar, aber welcher Java-Entwickler programmiert schon seine eigene Datenbank, wenn er nicht etwas spezielles braucht, dass es so nicht von der Stange gibt. Die einzige Variante bleibt die Sprache, der “Rest”-(API) ist vorgegeben.


#10

Gestern drüber gestolpert:

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…


#12

Obligatorisches Dilbert-Comic:


#13

Schöner Artikel: https://medium.com/swlh/the-full-stack-developer-is-a-myth-4e3fb9c25867