Programmierer und Fachinformatiker für Anwendungsentwicklung?
Was sind die Gemeinsamkeiten und Unterschiede zwischen Programmierern und Fachinformatikern für Anwendungsentwicklung?
5 Antworten
Programmieren => Die Tätigkeit, das Schreiben von Code
Fachinformatiker Anwendungsentwicklung => Ausbildungsbezeichnung
Softwareentwickler => Der eigentliche Beruf, das Programmieren ist nur ein kleiner Teil.
So zumindest sehe ich das, irgendwie genormt ist da nichts.
Die Ausbildungsbezeichnung ist quasi irrelevant, erinnert mich ein bisschen an Anwaltsdeutsch. Die Ausbildung beinhaltet aber nicht nur Programmierung, sondern ist viel weiter gefächert (Systemintegration, Elektronik, BWL, etc.), betrachtet aber alles nur sehr oberflächlich - was vermutlich dem extremen Umfang geschuldet ist.
Zum Job des Softwareentwicklers gehört neben dem Job als Programmierer noch sehr viel mehr dazu, was dir aber niemand wirklich beibringen kann, das muss man in der Praxis lernen.
Eine Ausbildung heißt halt "Fachinformatiker für Anwendungsentwicklung". Ein Fachinformatiker ist ein Programmierer.
Die programmieren, sprich schreiben Codes.
Daher kommt das Wort Programmierer. Ist aber halt kein formaler Begriff soweit ich weiß.
Der Ausbildungsplan für Fachinformatiker für Anwendungsentwicklung sagt ganz was anderes. Er erweckt nicht den Eindruck, als sei Programmieren die Haupttätigkeit solcher Fachinformatiker: Nur 52 Wochen der gesamten 3-jährigen Ausbildung haben Anwendungsentwicklung zum Gegenstand.
Beweis: Abschnit B des Rahmen-Ausbildungsplanes https://www.weingarten.ihk.de/blueprint/servlet/resource/blob/4831644/6fd8ce3090eb160f46ae607c43bf1afa/berufeaz-szg-fachinformatiker-bes-26062020-data.pdf
Das ist dasselbe. "Programmieren" ist ein Name der Tätigkeit, wenn man halt programmiert.
FIAE ist dann halt die Berufs- bzw. Ausbildungsbezeichnung.
Beide kann man als "Programmierer" bezeichnen.
Fachinformatiker für Anwendungsentwicklung sind die am wenigsten gut ausgebildeten Software-Entwickler.
Konsequenz daraus: An wirklich komplizierten Projekten wird man sie kaum beteiligen. Entsprechend schwer werden sie es haben, schnell dazuzulernen.
Dennoch können besonders fähige Fachinformatiker für Anwendungsentwicklung dieses Hindernis überwinden. Ich kannte einige wirklich gute (muss aber sagen: sie waren eher Ausnahme denn Regel und vom Gehalt nicht ausreichend gewürdigt).
Nur Programmierer sein zu wollen, reicht auf keinen Fall.
Umgekehrt hat die Ausbildung aber auch den Vorteil, dass sie Berufserfahrung vermittelt, das fehlt vielen studierten Menschen.
Studierte Kollegen sind mir nie durch mangelnde Berufserfahrung aufgefallen (über ganze 30 Jahre hinweg), sehr wohl aber dadurch, dass sie im Gegensatz zu Programmierern i.A. auch in der Lage waren, brauchbare Anwendungsanalysen und brauchbare Dokumente vom Typ Lösungsentwurf zu schreiben.
Studierte Kollegen sind mir nie durch mangelnde Berufserfahrung aufgefallen (über ganze 30 Jahre hinweg)
Natürlich ist das nur am Anfang relevant, nach dem Studium sammeln sie ja ihre eigenen Erfahrungen und dann zählt wieder nur, ob die Person das kann, was eine Firma braucht.
brauchbare Anwendungsanalysen und brauchbare Dokumente vom Typ Lösungsentwurf zu schreiben.
Und was hat das Beides nun mit der Softwareentwicklung zu tun? Das ist ein völlig anderes Aufgabengebiet.
Ein Softwareentwickler muss Ahnung von dem Entwurf von Softwarearchitekturen oder Quellcodedesign haben und er muss natürlich auch Ahnung von der Programmierung und den Technologien haben.
Wenn ich mich am SCRUM-Ansatz orientiere, würde ich diese Aufgaben eher beim PO sehen und nicht beim Entwickler. Der PO schreibt das dann zusammen und formuliert daraus konkrete Anforderungen, spricht die mit den Entwicklern durch und die setzen es um.
Das ist gerade bei Anwendungsanalysen auch viel sinnvoller, da ein Entwickler die technische "Brille" trägt, für viel wichtiger halte ich da aber die fachliche Sichtweise, idealerweise mit fachlicher Erfahrung eines Anwenders. Bei einem Lösungsentwurf vermischt sich das natürlich etwas.
Du verwechselst die Rolle des Software-Entwicklers mit der klassischen Rolle der Programmierer, die einfach nur Codierer waren. Sie sind im Aussterben begriffen.
Man sollte nicht von einem Studenten auf die Fähigkeit aller schließen.
Dann noch zu SCRUM:
Michael O. Church — heute Manager von Entwicklungsteams bei Google — hat es geschafft, treffend zu charakterisieren, was speziell SCRUM — von seltenen Notfallsituationen mal abgesehen — v e r d a m m e n s w e r t macht. Er schreibt (im Juni 2015):
- So what are Scrum and “Agile”? I could get into the different kinds of meetings (“retrospective” and “backlog grooming” and “planning”) or the theory, but the fundamental unifying trait is violent transparency, often one-sided. Programmers are, in many cases, expected to provide humiliating visibility into their time and work, meaning that they must play a side game of appearing productive in addition to their actual job duties.
- Instead of working on actual, long-term projects that a person could get excited about, they’re relegated to working on atomized, feature-level “user stories” and often disallowed to work on improvements that can’t be related to short-term, immediate business needs (often delivered from on-high). Agile eliminates the concept of ownership and treats programmers as interchangeable, commoditized components.
- In addition to being infantilizing and repellent, Scrum induces needless anxiety about microfluctuations in one’s own productivity. The violent transparency means that, in theory, each person’s hour-by-hour fluctuations are globally visible– and for no good reason, because there’s absolutely no evidence that any of this snake oil actually makes things get done quicker or better in the long run. For people with anxiety or mood disorders, who generally perform well when measured on average long-term productivity, but who tend to be most sensitive to invasions of privacy, this is outright discriminatory.
Seine ausführliche, das Problem genau identifizierende Analyse schließt mit der Feststellung:
- It’s time for most of "Agile" and especially Scrum to die. These aren’t just bad ideas. They’re more dangerous than that, because there’s a generation of software engineers who are absorbing them without knowing any better. There are far too many young programmers being doomed to mediocrity by the idea that business-driven engineering and "user stories" are how things have always been done. This ought to be prevented; the future integrity of our industry may rely on it. "Agile" is a bucket of nonsense that has nothing to do with programming and certainly nothing to do with computer science, and it ought to be tossed back into the muck from which it came.
Mir ist klar, dass der Softwareentwickler noch mehr zu tun hat, als nur zu programmieren. Dazu gehört dann z.B. noch der Entwurf von Software-Architekturen oder Quellcode-Designs, die Organisation im Team, Aufwandsabschätzungen, etc.
Anforderungsanalysen gehören eben nicht dazu, ganz besonders, da der Entwickler, von der Arbeit der Anwender maximal eine entfernte Sicht hat.
Ein Lösungsentwurf würde ich als Teamarbeit sehen, an dem der Entwickler die technischen Möglichkeiten im Blick behält.
Das sind zwei völlig verschiedene Themengebiete, die - zugegeben - häufig (z.B. aus Kostengründen) zusammen fallen, aber eigentlich getrennt gehören.
Also dir ist noch nie ein Studierter negativ aufgefallen aber bei meiner gegenteiligen Erfahrung ist das ein Einzelfall den man nicht allgemein so sehen kann. Ist klar.
Scrum geht völlig am Thema vorbei, Agile Prinzipien haben aber schon Daseinsberechtigung. Wie sie umgesetzt werden ist wieder eine andere Sache, da mag es oft Probleme geben. Das stimmt.
Was der Michael O. Church hier kritisiert, ist die Agilität an sich bzw. die Folgen daraus, die SCRUM zu lösen versucht. Agiles Arbeiten ist natürlich scheiße, aber heutzutage (leider) häufig notwendig, ganz besonders im Auftragsgeschäft.
Google hat da natürlich eine sehr komfortable Situation, sie können es sich leisten, einfach mal andere Arbeitsweisen auszuprobieren, oder zig Stunden Arbeit in den Sand zu setzen. Außerdem ist Google in vielen Punkten sein eigener Kunde, trotz sehr vielfältiger Projekte - eine sehr komfortable Situation, die ich auch gerne hätte.
SCRUM kann man aber auch nicht einfach nur auf die Zeiten reduzieren.
Zum Einen schreibt SCRUM nicht vor, dass man Zeiten angibt, sondern nur, dass man irgendeine Einheit definiert - soll (ich habe keine eigenen Erfahrungen damit) erstaunlich gut funktionieren.
Zum Anderen beschäftigt sich SCRUM auch mit der Organisation zwischen den Abteilungen und definiert Prozesse, die darauf abzielen, alle Prozesse zu optimieren - und daran beteiligen sich dann alle, auch die Entwickler. Das meint z.B. die Anforderungsanalyse, da sehr häufig schlecht formulierte Anforderungen zu Problemen führen.
Dabei ist dann aber nicht SCRUM das Problem, sondern die Agilität an sich.
Leider ist man häufig dazu gezwungen, agil zu arbeitet, SCRUM ist ein möglicher Weg, damit umzugehen.
Ja: Agilität ist heute unverzichtbar. Sie muss Geisteshaltung sein, statt irgend eine spezifische Methodik.
Kernpunkt ist die Einsicht, dass es nicht (wie früher) erlaubt sein darf, sich auf ein unterschriebenes Entwurfspapier zu berufen, nachdem klar wurde - oder auch nur der Verdacht besteht - dass die dort postulierte Lösung nicht mehr gewünscht sein kann.
Konsequenz daraus: Keine einzige Phase des Wasserfallmodells darf heute schon vor Projektende als endgültig beendet erklärt werden.
Konsequenz daraus: Keine einzige Phase des Wasserfallmodells darf heute schon vor Projektende als endgültig beendet erklärt werden.
Und genau das tut SCRUM.
Alles Weitere sind "nur" Reaktionen um daraus folgende Probleme anzugehen.
Agilität ist nie problematisch - ganz im Gegenteil: Agil zu handeln beseitigt uns Stolpersteine.
Probleme bekommen nur Projektmanager, die noch nicht gelernt haben, durch Neudefinition der vom Kunden benötigten Lösung verursachten Zusatzaufwand über geeignetes Change-Management bezahlt zu bekommen.
Dir ist schon klar, dass sich ändernde Anforderungen gewaltige Auswirkungen auf die Entwicklungsarbeit haben können? Im Extremfall muss sogar die Architektur umgeschrieben werden, sowas frisst Zeit und das will man vorher wissen.
Das ist nicht nur "etwas" Zusatzaufwand. Die Anforderungen müssen erfasst werden, sie müssen geplant und abgeschätzt werden, damit man einen Go-Live-Termin anpeilen und einen Preis drauf schreiben kann.
Und genau da hast Du schon die ganzen Probleme, die Michael O. Church kritisiert - ganz ohne irgendwelche vorgeschriebenen Prozesse.
Das Problem an SCRUM ist, dass es viele als einen Art Zeiterfassungs- oder Kontroll-Prozess verstehen, das setzt die Entwickler natürlich unnötig unter Druck. Genau das ist es aber nicht, richtig umgesetztes SCRUM reduziert diesen Druck sogar.
„Programmierer“ ist eine Tätigkeit und kein Berufsabschluss.
Ich auch: Ich habe eine Softwarefirma und wir haben sowohl Programmierer mit Berufsabschluss als auch welche ohne. Und wir bilden auch aus und haben duale Studenten für Wirtschaftsinformatik.
Programmierer bist Du, indem Du einfach programmierst. Dazu brauchst Du noch nicht einmal einen Schulabschluss.
Zeig mir die Berufsausbildung (egal welcher Art), die einen Programmierer gut darauf vorbereitet, was er die nächsten Jahre braucht.
Spoiler: Keine, das geht gar nicht.
Entscheidend ist, was die Person sich selber beibringen kann und das wissen meiner Erfahrung nach auch die Arbeitgeber - zumindest solange sie ihren bereits eingestellten Experten vertrauen.
Also ja, verglichen mit einem Studium ist die Ausbildung vielleicht die Schlechteste, doch im Berufsalltag nach ein paar Monaten oder Jahren ist das völlig irrelevant. Dann zählt nur noch, wie gut jemand im jeweiligen Arbeitsumfeld ist und ob die Person das auch zeigen kann.
Umgekehrt hat die Ausbildung aber auch den Vorteil, dass sie Berufserfahrung vermittelt, das fehlt vielen studierten Menschen.
Auch die Aussage zu den komplizierten Projekten entspricht nicht meiner Erfahrung. Meiner Erfahrung nach ist auch hier der persönliche Eindruck entscheidend.
Dem stimme ich aber zu, das Programmieren ist nur der einfache Teil der Arbeit.