Beruf: Softwareentwickler. Gibt es das?

[anon94273153]

Ich glaube dein Feindbild des Organisators solltest du schnellstens ablegen. Die gibt es vll. aber begegenen mir z.B. nie. Da kommt zwar der IT-Abteilungsleiter spontan ins Meeting, der keinen IT Abschluss hat, ist aber überhaupt nicht abgehoben sondern wirklich interessiert an der Lösungsfindung. Man muss halt einen Weg finden um Dinge zu vemritteln, PowerPoint ist nicht perfekt aber es gibt schlimmeres.

Du darfst “Beliebigkeit” nicht mit Flexibilität verwechseln. Es gibt einfach nicht DEN perfekten Job und Änderungen sind auch immer spannend. Aber zu sagen, DAS mache ich nicht, weil in der Stellenausschreibung Bullshitbingo gespielt wird…ja selber schuld. Die macht ja nicht deine zukünftige Abteilung sondern Marketing oder HR.
Ich vermute weiterhin, dass du bisher nicht richtig suchst, aus welchen Gründen auch immer.

[Marco13]

@anon2594669

Ich glaube, gerade Code-Prinzipien sind heutzutage sehr wichtig. […]

Nicht alles muss (und sollte aus der profitablen Sicht) immer bis ins Kleinste optimiert werden. Über wartbaren Code muss man sich nicht unterhalten, der sollte immer vorhanden sein (oder angestrebt werden). […]

Was auch immer nun mit „Code-Prinzipien“ gemeint sein soll: Ich glaube das nicht. Stattdessen scheint eher diese „Wenn’s läuft is’ gut“-Mentalität recht verbreitet zu sein, unterfüttert von der Gewißheit, dass die Frameworks, aus denen man heute irgendeine Node.js-Anwendung zusammengeklöppelt hat, morgen schon obsolet sind…

^{… und sowieso nicht klar ist, ob man gerade in JavaScript, ES2015, ACMEScript 08/15, ES2016 oder irgendeinem Dialekt programmiert. *mit den händen wedelt und abwechselnd mit den fingern schnippt* : Wir sind soooo agil…}

„Optimierung“ klingt leicht nach dem, weswegen einem dann „premature Optimization“ und/oder auch sowas wie „mangelnder Pragmatismus“ vorgeworfen wird - oder auch einfach „Perfektionismus“. Ich stelle dann gerne die Frage, was das Gegenteil von „Perfektionismus“ ist. Die Antwort könnte sein: „Stümperei“. Diesen Vorwurf wiederum scheint kaum jemand mal offen auszusprechen. (Ich schon).

@anon2594669

Meist gibt es Bibliotheken, die das viel besser umgesetzt haben. In Unternehmen geht es in der Regel halt nicht akademisch zu. Wer das möchte, ist vielleicht an der Universität besser aufgehoben.

Ich will da keine Verbindung unterstellen, aber das erinnert mich an JavaScript-Paket aus NPM entfernt: Node, Babel und Co. scheiterten beim Build | heise online . Grottige Sprache. Grottige Tools. Grottige Infrastruktur. Grottige Entwickler.

^{(Wenn mir wenigstens da mal jemand widersprechen würde. Stattdessen kommt bestenfalls mal ein patziges „Dann mach’ halt was anderes“, oder sowas wie „Das machen doch alle so“ (ohne den Konflikt zu erkennen, der darin liegt) - aber dann weiß ich zum Glück, dass es sich nicht lohnt, weiterzureden).}

@anon2594669

Ich begreife den Begriff des Softwareentwicklers anders. Ich muss auch mit den Kunden ins Gespräch kommen. Ich sollte auch bewerten können, ob eine Eigenentwicklung überhaupt sinnvoll ist oder Kaufsoftware besser ist. Aber der Hauptteil ist immer noch das Entwickeln von nutzbarer Software.

Kunden? Jaja, die soll es geben Aber mal im Ernst: Woraus besteht diese Software dann? (Antwort: Aus einer dockerfile und einer großen package.json???) Oder auch konkreter: Was macht der Code, den man schreibt? (Antwort: Eine handvoll library-Funktionen in der richtigen Reihenfolge aufrufen?).

(Hoffentlich kommt jetzt nicht der Vorwurf, ich wolle irgendwelche Räder neu erfinden, sonst muss ich auch irgendwelche Metaphern bemühen, und ich denke, Metaphern sind das Krebsgeschwür einer sachlichen Diskussion).

(Vielleicht hängt viel davon mit einer idealistisch-naiven Vorstellung zusammen, bei der das Ergebnis der eigenen Arbeit eben nicht ein Programm ist, was läuft, sondern der Code selbst…)

@anon94273153

Ich glaube dein Feindbild des Organisators solltest du schnellstens ablegen. […]

Es geht da nicht um ein „Feindbild“. Im Gegenteil: Irgendjemand muss einem ja den Orga/Managementkram aus dem Rücken halten. Die Details der Aufgabenverteilungen können dann unterschiedlich sein und sich einpendeln.

@anon94273153

Du darfst “Beliebigkeit” nicht mit Flexibilität verwechseln. Es gibt einfach nicht DEN perfekten Job und Änderungen sind auch immer spannend. Aber zu sagen, DAS mache ich nicht, weil in der Stellenausschreibung Bullshitbingo gespielt wird…ja selber schuld. Die macht ja nicht deine zukünftige Abteilung sondern Marketing oder HR.

Flexibilität in bezug auf was? Die Ziele (Ergebnisse und ihre Qualität)? Die Basis (Sprache und Frameworks)? Die Methodik („lebenslanges Lernen“ vs. „lebenslanges learning by doing“)?

Wie wenig Anspruch man an sich selbst haben muss, um sich damit zufrieden zu geben, dass die eigene Arbeit nur darin besteht, die Arbeit anderer neu zu kombinieren, weiß ich nicht. Wie wenig Anspruch man an sich selbst haben muss, damit man glaubt, dass das, was man anhand der Websuchergebnisse von „How to [do this stuff that the new customer wants]“ zusammenklöppelt, schon „gut genug“ sein wird, weiß ich nicht. Wie wenig Anspruch man an sich selbst haben muss, damit man nicht hinterfragt, ob man das, was man da gemacht hat, nicht komplett anders gemacht hätte, wenn man mehr als eine Woche Zeit gehabt und besser verstanden hätte, weiß ich nicht. Was ich aber weiß ist, dass jemand, der sich mit einem neuen Thema beschäftigt (egal ob fachlich, konzeptuell oder technisch) da am Anfang praktisch stümpern muss.

@anon2594669

Ich finde Dein Bild sehr negativ.

@anon94273153

Ich vermute weiterhin, dass du bisher nicht richtig suchst, aus welchen Gründen auch immer.

Vielleicht könnte das Problem mit Kokain und einem Antidepressivum behoben werden, aber das will ich nicht und außerdem versuche ich ja schon die ganze Zeit, diesen Thread wieder zur allgemeinere Frage hin zu lenken, was „Informatiker heute so machen“ oder was „Softwareentwicklung heute so bedeutet“.

_{(… und subjektiv höchstens noch warum das beides so irritierend wenig mit dem zu tun zu haben scheint, was ich unter „Softwareentwicklung“ verstehe. Eigentlich fand ich Objektorientierung ganz gut. Aber vielleicht bin ich auch einfach nur altmodisch…).}

[anon2594669]

@Marco13

“Optimierung” klingt leicht nach dem, weswegen einem dann “premature Optimization” und/oder auch sowas wie “mangelnder Pragmatismus” vorgeworfen wird - oder auch einfach “Perfektionismus”. Ich stelle dann gerne die Frage, was das Gegenteil von “Perfektionismus” ist. Die Antwort könnte sein: “Stümperei”. Diesen Vorwurf wiederum scheint kaum jemand mal offen auszusprechen.

Es gibt zwischen schwarz und weiß auch Grautöne. Ich empfehle aim42. Damit lässt sich strukturiert herausfinden, ob ein Refactoring, eine Verbesserung oder ähnliches gemacht werden müssen oder nicht.
Ist wie mit CleanCode. Wenn sich einer mit mir unterhält, dass diese eine Methode nun zwei Rücksprungstellen hat, aber sonst alles ok ist, diskutieren wir auf einem so hohen Niveau. Dann kann ich mit diesem Problem auch einfach leben.

@Marco13

… und sowieso nicht klar ist, ob man gerade in JavaScript, ES2015, ACMEScript 08/15, ES2016 oder irgendeinem Dialekt programmiert. mit den händen wedelt und abwechselnd mit den fingern schnippt : Wir sind soooo agil…

Ich verstehe den Zusammenhang mit agil nicht. Wenn sich jemand in diesem Gebiet nicht auskennt und nicht weiß, was er tut, muss diese Person dazu lernen oder es sein lassen. Aber die verschiedenen Javascript-Dialekte haben mit dem Begriff Agilität nicht viel zu tun.

@Marco13

Ich will da keine Verbindung unterstellen, aber das erinnert mich an https://www.heise.de/developer/meldung/JavaScript-Paket-aus-NPM-entfernt-Node-Babel-und-Co-scheiterten-beim-Build-3148796.html . Grottige Sprache. Grottige Tools. Grottige Infrastruktur. Grottige Entwickler.

Naja, man sollte sich immer genau überlegen, ob und wann man eine Bibliothek einsetzt. Das sollte klar sein. In Deinem Beispiel ist wohl eher das Problem, dass man Bibliotheken wieder aus einem Repository entfernen kann. Ich weiß nicht, ob NPM das noch unterstützt, es gab danach aber eine große Debatte darüber. Und bisher ist mir auch nur dieser eine Fall bekannt. Daran sollte man sich also nicht aufhängen.

@Marco13

Kunden? Jaja, die soll es geben Aber mal im Ernst: Woraus besteht diese Software dann? (Antwort: Aus einer dockerfile und einer großen package.json???) Oder auch konkreter: Was macht der Code, den man schreibt? (Antwort: Eine handvoll library-Funktionen in der richtigen Reihenfolge aufrufen?).

Ach komm schon. Ich möchte einen Mehrwert für den Kunden liefern. Dafür schreibe ich immens viel Code. Ich muss aber keine Sortieralgorithmen selbst schreiben. Ich muss auch keine Templatingengine oder Prozessengine selbst schreiben. Wozu? Ich muss auch kein Framework wie Spring selbst schreiben. Oder JUnit, oder oder oder.
Ich kann auch mit Deinem Bezug zu Docker und NPM nichts anfangen. Beides verrichtet guten Dienst, wenn man es benötigt. Und die Zeit mit Javascript ohne Packaging-System war einfach grausam.

Wenn Du knallharten Code schreiben möchtest, such Dir eine Firma, die ein Produkt für eine Hardware herstellt. In der Medizin gibt es dazu sehr viel. Bei Philips Research wird man z.B. schnell fündig.

[Marco13]

@anon2594669

Es gibt zwischen schwarz und weiß auch Grautöne. Ich empfehle aim42. Damit lässt sich strukturiert herausfinden, ob ein Refactoring, eine Verbesserung oder ähnliches gemacht werden müssen oder nicht.

Nach einem kurzen Blick sieht das aus, wie etwas, wovon ich nicht viel halte (aber das war nur ein kurzer Blick, deswegen genau diese Formulierung, mit entsprechenden Vorbehalten!!!). Man könnte in dieses Diagramm auch „Wash - Dry - Fold“ reinschreiben um ähnlich „detailliert“ den Prozess des Wäschewaschens zu beschreiben. Zumindest verstehe ich nicht, welchen unmittelbaren Nutzen es bringt, wenn man versucht, einem komplexen Prozess (d.h. Entwicklung und Verbesserung von Software) in so ein Diagramm zu packen, das für sich erstmal keinen Nutzen hat, außer, eine Systematik zu suggerieren, die für sich genommen so trivial ist, dass von vornherein klar ist, dass das „Beef“ (also die Dinge, die „Kompetenz“ erfordern und eben in diesem Sinne schwierig sind) in den (dann, vermeintlichen (!)) Details liegt. Zumindest sieht Clean Code in diesem Sinne fokussierter und mehr nach „Hands-On“ aus. Aber vielleicht schau’ ich bei Gelegenheit nochmal, ob z.B. auf http://aim42.org/improve irgendwann noch mehr geschrieben wird (EDIT: Jaja, Method Reference …)

@anon2594669

Ich verstehe den Zusammenhang mit agil nicht.

Da besteht keiner. Ich hatte schon damit gerechnet, dass das hinterfragt wird. Das war eher eine Art ironische Meta-Kritik an mehreren Ebenen von „Planlosigkeit“. Vermutlich hätte ich es nicht so schreiben sollen. Nicht so wichtig.

@anon2594669

Ich muss aber keine Sortieralgorithmen selbst schreiben. Ich muss auch keine Templatingengine oder Prozessengine selbst schreiben. Wozu? Ich muss auch kein Framework wie Spring selbst schreiben. Oder JUnit, oder oder oder.

Ich kann auch mit Deinem Bezug zu Docker und NPM nichts anfangen. Beides verrichtet guten Dienst, wenn man es benötigt. Und die Zeit mit Javascript ohne Packaging-System war einfach grausam.

Es ist klar (und trotzdem betone ich es nochmal) dass eine Ausprägung von „Kompetenz“ eben auch gerade das ist: Zu wissen (bzw. zu erkennen) an welchen Stellen man vorgefertigte Lösungen verwendet, und was man besser selbst macht. Die Ausprägungen der Abweichungen davon sind vielfältig. Das reicht von möchtegern-Nerds, die im Studium was über class, if, und while gelernt haben, und versuchen, den Rest ihrer „„Programmierlaufbahn““ mit diesen drei Dingen zu bestreiten, und führt (über viele Zwischenstufen, über die man jeweils sehr lange streiten könnte) bis hin zu großen Firmen wie Google oder Microsoft, die existierende Lösungen nicht verwenden, weil sie durch ihre Marktmacht eine prorietäre Lösung in die Welt pressen können, nicht zuletzt mit dem Ziel, ihre Marktmacht zu stärken (!).

Was ich aber gelinde gesagt haarsträubend finde, ist, wenn man in die AWS-Cloud einen Docker-Container hochlädt, in dem ein Node.js läuft, das mit NodeExpress einen Router aufmacht, dessen ES2016-Code mit Babel und einer handvoll hoch-spezifischer Plugins in einem Build-Schritt auf obfuskiert-unlesbares ES2015 runtercompiliert wird, in dem eine React-Component mit JSX erstellt wird, die auf eine handvoll CSS-Dateien und .less-Templates zurückgreift und mit Server-Side-Rendering eine Seite vor-baut, und das Ergebnis dieser Rube-Goldberg-Maschine ist dann objektiv betrachtet eine Webseite, die aus 5MB .js-Dateien besteht und das Wort „Hallo“ anzeigt.

Auf praktisch jeder Ebene so einer Infrastruktur scheinen Tools und Libraries verwendet zu werden, die undokumentiert sind und auf (in JavaScript nun mal sehr „einfach“ und oft auch „versehentlich“ (!) umzusetzenden) Hacks aufbauen, und von irgendeinem Script-Kiddie auf GitHub und in NPM gepresst wurden, auf die sich aber trotzdem alle (und sei es nur als im Wind wackelnde Blätter des dependency-Baums) blind verlassen, und über deren Glitches und dunklen Ecken des Verhaltensraumes man sich ständig ärgert.

(Ja, die Zeiten, wo man .HTML-Dateien mit FTP irgendwo hingepackt hat, sind vorbei. Aber die Infrastruktur, die „heutzutage“ hinter „modernen“ Webseiten zu stehen scheint(!), erscheint mir völlig unangebracht und von der Komplexität her schlicht nicht mehr handhabbar - falls ich nicht zufällig die negativsten aller denkbaren Beispiele mitkriege…).

Vermutlich gilt diese Komplexität als „normal“, und man kann bestenfalls noch entscheiden, in welcher „Geschmacksrichtung“ man die Komplexität haben will. Also ob nun JavaScript/NodeJs/Express oder Spring - alles nichts, wo man mal kurz ein Tutorial liest und dann gleich etwas gutes machen kann. Aber erstens würde ich mir wünschen, dass die Herausforderungen, mit denen ich mich beschäftige, nicht die sind, den StackOverflow-Beitrag zu finden, in dem steht, was in der .babelrc stehen muss, damit eine bestimmte Fehlermeldung weggeht, und zweitens gehört für mich (bei diesen Themen, und auch bei allem, was ich sonst mache) eine Frage quasi zum permanenten „Hintergrundrauschen der Gedanken“, nämlich: „Geht das nicht auch einfacher?“.

^{(Meistens ist die Antwort „Ja“. Frustrierend wird es nur, wenn daraus ein „Ja, aber ich weiß nicht, wie“ wird - oder noch schlimmer: „Ja, aber niemand hat ein Interesse daran, es einfacher oder besser zu machen, weil das ja Zeit kosten würde“…)}

[ionutbaiu]

Letztens habe ich einen Vortrag von der GOTO 2017 gesehen, der eine Sichtweise aufzeigt, die ich so noch nicht in dieser Deutlichkeit wahrgenommen habe.

Man sollte sich jetzt nicht gleich durch den Titel abwimmeln lassen (Serverless) und auch die ersten 20 Minuten sind recht Oberflächlich. Danach bringt er aber ein Interessantes Diagramm

Dafür erstellt er sich eine Art BOM in Baumform (Graph), die er braucht um einen Kunden zufrieden zu stellen.

Eine Website, die wiederum auf ein CRM zugreift. Beides läuft auf einer Plattform, welches wiederum auf einem Betriebssystem läuft. Das läuft dann auf einem Rechner, der in einem Rechenzentrum mit Internetanbindung steht und Strom braucht. Alles ganz grob und etwas vereinfacht.

Auf der x-Achse in diesem Diagramm geht er von links nach Rechts über die Punkte
Genesis
Custom-Built
Product (+rental)
Commodity(+utility)

und zeichnet dort die entsprechenden Bestandteile ein. Nun ist eben die Zielrichtung alles zur Commodity hinzubewegen.

Beim Strom, hat er die Möglichkeit sich einen eigenen Generator zu bauen (Custom-Built). Sobald sich aber die Möglichkeit gibt einen Generator zu kaufen wird er dies tun. Oder er mietet sich einen Generator, den er betreibt um den Kaufpreis zu sparen. Aber letztendlich wird er einen Stromanschluss haben und sich ans Netz anschliessen. Klar, heute würde niemand auf die Idee kommen sich einen eigenen Generator zu bauen und Strom aus der Leitung ist schon lange Standard.

Aber das gleiche Prinzip lässt sich auf die anderen Punkte genauso anwenden. Vor ein paar Jahrzehnten hat man sich die Rechner noch selbst zusammengelötet. Irgendwann selbst zusammengesteckt oder fertig gekauft. Jeder Admin hat sich früher noch die Frage gestellt welche Anwendung er auf welcher Maschine laufen lässt, wieviel Kerne, Ram, HDD ect. verbaut wird und und und. Dann hat man sich die Server im RZ gemietet. Erst physisch, dann virtuell hin zu cloud bis man wohl bei Serverless ankommt und nur noch einzelne Funktionen beschreibt.

Worauf ich hinaus will ist, dass dieser Prozess Industrialisierung heisst. Und dieser trifft die Softwareentwicklung extrem. Wenn alle den gleichen Code nach den selben Best-Practices produzieren. Scrum den ganzen Prozess in kleine Tasks aufgeteilt hat. Dann ist am Schluss der Programmierer austauschbar. Von der Kreativität, dem Wissen, bleibt da nichts mehr übrig, das gefragt wird.

Klar gibt es, auch hier im Forum, viele, bei denen der Job noch spannend ist und es wird auch einige geben, bei denen der Job spannend bleibt, weil Handarbeit und richtiges Programmieren. Aber viele dieser Jobs werden auch wegfallen, weil die Firmen schlicht nicht Konkurrenzfähig bleiben, wenn sie nicht entsprechend Industrialisieren oder gegen die grossen antreten müssen.

Wenn man sich zum Beispiel DMAX im Fernsehen anschaut, da bringen sie so Sendungen, bei denen Leute Autos bauen. Handarbeit, Schweißen, Flexen, Dängeln. Oder bei Bugatti wie zwei Leute in Handarbeit einen Motor zusammenbauen. Dann ist das eine sofern man dazu veranlagt ist interessante Tätigkeit, die es auch nur ins Fernsehen schafft, weil die meisten Leute das nicht mehr in der Realität haben.
Beim Daimler hast du ein grosses Fliessband. Da machst du in deiner Schicht nichts anderes als Rücksitzbänke zu montieren. In zwei Tagen bist du da Fit-Für-Den-Job.
Schaut man sich aber das Werk vom Daimler an, dann ist es ein riesiges komplexes Ungetüm im Vergleich zur GasMonkey-Garage. Vergleichbar mit dem Node/Express/Docker/AWS-Stack.

Und das ist leider die Richtung in die sich die Softwareentwicklung entwickeln wird. Unvermeidlich, weil industrialisierte Prozesse einfach sooooo billig und berechenbar sind.

Und beim oben erwähnten Bäcker, dem die gleiche Brotmischung langweilig vorkommt, kann ich nur schreiben, dass dieser eigentlich dicht machen kann. Um ein Interessantes Sortiment zu haben, muss er Tiefkühlkost zukaufen. Das gleiche was man auch an der Backtheke im Supermarkt findet. Dort lediglich billiger. Langfristig macht das dann auch niemand mit, Backshops spriessen aus dem Boden. Das Handwerk liegt am Boden. Es atmet nicht mehr. Es ist tot.

Softwareentwicklung ist die Fliessbandarbeit von morgen. Ich kann da Marco nur Full-Ack geben.

[anon2594669]

@Marco13

Auf praktisch jeder Ebene so einer Infrastruktur scheinen Tools und Libraries verwendet zu werden, die undokumentiert sind und auf (in JavaScript nun mal sehr “einfach” und oft auch “versehentlich” (!) umzusetzenden) Hacks aufbauen, und von irgendeinem Script-Kiddie auf GitHub und in NPM gepresst wurden, auf die sich aber trotzdem alle (und sei es nur als im Wind wackelnde Blätter des dependency-Baums) blind verlassen, und über deren Glitches und dunklen Ecken des Verhaltensraumes man sich ständig ärgert.

Und da hast Du Erfahrungen? Oder ist das einfach ein Bauchgefühl. Ich lese zwar viel, dass es immer wieder coole Blogs voll mit solchen Dingen gibt, aber ich kenne wenig Projekte, die das dann auch so handhaben. Meist wird schon darüber nachgedacht, was man wie umsetzt.

Ich lese hier viel Schwarz-Weiß heraus. Wie viel Erfahrungen konntest Du denn in unterschiedlichen Projekten wirklich sammeln?

[Marco13]

Den Vortrag fand ich nicht schlecht. Ja, ein bißchen abstraktes CEO-Gelaber, und darüber, ob die Unterstellung, dass er nur seine Webseite pitchen und darauf hinarbeiten will dass andere (leicht beeinflussbare und impulsiv handelnde) CEOs ihre direkten Untergebenen dazu verdonnern, im Rahmen einer dieser in Stellenausschreibungen immer wieder angepriesenen Fort- und Weiterbildungsmaßnahmen einen seiner Maps-Trainingskurse zu belegen, nun „böswillig“ oder „offensichtlich, nahe liegend und nachvollziehbar“ ist, könnte man lange streiten. Aber die technisch-konzeptuelle Rechtfertigung seiner Darstellung in diesen Maps geht weeeit über das hinaus, was man sonst als Rechtfertigung für irgendeine visuelle Darstellung in PowerPoint-Folien sieht (auch wenn die Latte nicht sehr hoch liegt - diese Rechtfertigung pendelt meistens zwischen „Sieht hübsch aus“ und „Füllt eine weitere Folie“ ), passt zu Dingen, die man selbst beobachten kann, und bietet zumindest das Potential, dort bis zu einem gewissen Grad „Handlungsanweisungen“ (oder Erkenntnisse, vielleicht sogar „wahrscheinliche zukünftige Entwicklungen“ im Sinne des „Movements“, wie er es nennt) abzuleiten. Hab’s zumindest mal jemandem forgewardet. Das kommt nicht sooo oft vor.

Übertragen auf das Beispiel, das du dann noch ausformulierst: Das stimmt sicher, bis zu einem gewissen Grad. Immer mehr bewegt sich „auf die rechte Seite“ dieser Maps. Die Fragen, die sich ergeben, sind: Was bewegt sich dort hin, wie sieht es aus, wenn es dort angekommen ist, und gegebenenfalls: Was bedeutet das für den einzelnen?

Er vergleicht die Zuständigkeiten (von links nach rechts) ja mit „Erforschern“ für den experimentellen/customisierten Teil, „Siedlern“ für den Teil, der gerade dabei ist, sich zu festigen, und „Städteplanern“ für den Teil, der schon weitgehend gefestigt ist und dann wachsen (oder ggf. solider oder sonstwie „besser“ gemacht werden) soll. An welcher Stelle hat nun ein Informatiker welche Aufgabe? 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).

Das Problem, das ich sehe (und was mich nervt) ist, dass diese Trennung, Ordnung und Struktur in der Realität nicht vorzuliegen scheint. Elementarste Anforderungen scheinen da nicht erfüllt zu sein. Das bezieht sich auf alle Ebenen - z.B. auf Verläßlichkeit von Dingen, auf die man aufbaut (oder aufbauen sollte), oder auf die Möglichkeiten, in den sich ändernden Teilen schnell auf eben diese Änderungen zu reagieren.

Es ist schwierig (und vermutlich auch nicht zielführend) jetzt konkrete Beispiele zu nennen, teilweise aus „„politischen““/„„persönlichen““ Gründen, teilweise, weil ich sowas wie das leftPad nicht überstrapazieren will, und wenn ich jetzt auf irgendwelche Github-Issues in „etablierten“ Libs verlinken würde, bei denen man sich fragt „Wie zur Hölle kann so ein Scheiß denn entstehen??!?!“ könnte das auch nur mit „Joa, das is’ halt ein Bug“ kommentiert werden.

Aber übertragen auf dein bildliches Beispiel: Wenn der Bau eines Autos im Daimler-Werk dem Erstellen einer Webseite im Node/Express/Docker/AWS-Stack entspräche, würde derjenige, der die Rückbank einbaut, sie mit dem Leder einer Kuh beziehen, die er selbst geschlachtet hat, und vielleicht noch einen solarbetriebenen Stabmixer einbauen, und das Auto hätte am Ende 8 Räder, keine Rückspiegel, würde 12 Tonnen wiegen, und wenn jemand den Fensterheber betätigt, fängt der Benzintank zu brennen an (leftPad weg->Babel kaputt).

Vieles wirkt auf haarsträubendSTe Weise wackelig und unausgereift, und das Verhältnis zwischen Aufwand und Nutzen absurd. Aber gerade wenn etwas in diesen Maps nach rechts wandern soll, braucht man Ingenieure (City Planners), um Verläßlichkeit zu schaffen, und auch „Ergonomie“ (d.h. bei Softwarekomponenten: Benutzbarkeit durch andere Entwickler). Das scheint komplett außen vor gelassen zu werden.

Aber vielleicht ist das ein falscher Eindruck, denn…

@anon2594669

Und da hast Du Erfahrungen? Oder ist das einfach ein Bauchgefühl.

… ich habe wenige (d.h. sehr einseitige) Erfahrungen, und natürlich postuliere ich schon deswegen recht wenig - schon gar nicht sowas undifferenziertes wie „Das ist immer und überall so“ - sondern schildere (auf wenigen Erfahrungen und einigen Beobachtungen basierende) Eindrücke - wie „Ich sehe, dass das so gemacht wird, und Websuchen zeigen, dass das zumindest nicht unüblich ist“.

---

Das alles hat (wieder) recht wenig mit der ursprünglichen Frage zu tun, ob Informatiker heute noch Software entwickeln. Aber wenn sich die Antwort „Nein, tun sie nicht“ herauskristallisiert, dann sind sowohl die allgemeinere Frage „Was machen sie denn stattdessen?“ und „Wer entwickelt denn dann noch Software?“ durchaus On-Topic

[anon2594669]

@Marco13

Aber übertragen auf dein bildliches Beispiel: Wenn der Bau eines Autos im Daimler-Werk dem Erstellen einer Webseite im Node/Express/Docker/AWS-Stack entspräche, würde derjenige, der die Rückbank einbaut, sie mit dem Leder einer Kuh beziehen, die er selbst geschlachtet hat, und vielleicht noch einen solarbetriebenen Stabmixer einbauen, und das Auto hätte am Ende 8 Räder, keine Rückspiegel, würde 12 Tonnen wiegen, und wenn jemand den Fensterheber betätigt, fängt der Benzintank zu brennen an (leftPad weg->Babel kaputt).

Nur dass Änderungen an einem Auto wesentlich kostenintensiver sind, als an Software. Der Vergleich passt einfach nicht. Ich habe auch schon einiges entwickelt, was „einfach so läuft“, aber vielleicht nicht meinem Qualitätsanspruch genügt. Und über manche Bugs kann man auch einfach hinweg sehen.

@Marco13

… ich habe wenige (d.h. sehr einseitige) Erfahrungen, und natürlich postuliere ich schon deswegen recht wenig - schon gar nicht sowas undifferenziertes wie “Das ist immer und überall so” - sondern schildere (auf wenigen Erfahrungen und einigen Beobachtungen basierende) Eindrücke - wie “Ich sehe, dass das so gemacht wird, und Websuchen zeigen, dass das zumindest nicht unüblich ist”.

Ich würde mich da nicht auf eine kleine Stichprobe verlassen. Schon gar nicht auf irgendwelche Websuchen. Meist sind diese Dinge von Menschen geschrieben, die entweder keine Ahnung haben oder einfach nur alle Skills wollen.

Zu Deiner Frage: Ein Softwareentwickler entwickelt hauptsächlich Software. Das ist sein Job. Das muss allerdings nicht 8 Stunden Algorithmen-Tippen bedeutet. Dies ist wohl eher seltener der Fall. Software ist kein Selbstzweck sondern soll Probleme lösen bzw. Automatisierung verbessern. Perfektion ist in diesem Fall (anders als bei einem 120T Euro Benz) nicht immer erforderlich.