Nicht wirklich eine „News“ oder „Schlagzeile“, könnte aber hier her passen:
Leider ist die „Power“ von der er da redet wohl das, was mich irgendwie nervt: Man entwickelt halt nix mehr selbst 
Hm, wie ist “Troll” denn eigentlich definiert? Du sagtest mal (oder erwähntest/schriebst es mal hier nebenbei), das absolute “downvoten” auf SO gefällt dir auch nicht, wenn eine Frage nicht zu 100 % richtig gestellt wurde (regelkonform ist), oder eine Antwort nicht zu 100 % Ontopic enthält. - Und die andere ist die, der “Orientierbarkeit” an den Snippets. Man muss aber, bevor man die transferieren und adaptieren kann, erst das “Verständnis oder Wissen” habn, was man da überhaupt übernimmt. - Mal ein Beispiel, Latitude und Longitude… man möchte die Entfernung zwischen zwei Lat,Lon (auf einer “Kugel”) wissen; dann schaut man eben bei SO nach, denn dort sind die Antworten gewertet, und außerdem hab ich zumindest die Entfernung dafür nicht parat auswendig.
Ich werde bei Gelegenheit mal drüber nachdenken, wie ich die Antwort auf diese Frage formulieren könnte, ohne zu riskieren, dir damit persönlich zu nahe zu treten.
Auf Stackoverflow gib es recht strikte Regeln, und ich denke, dass die Regeln erstens sinnvoll sind, und zweitens die Mechanismen, die sie etabliert haben, bewirken, dass die Regeln gut eingehalten werden. Einige Members sind recht „puristisch“ und „hart“, was es Neulingen schwer machen kann. Aber dadurch, dass die Rechte für diejenigen erweitert werden, die „bewiesen haben“, dass sie sich (freiwillig) an die Regeln halten, beschränkt sich z.B. der Aufwand für die Moderatoren auf die Fälle, wo wirklich ein Disput entstehen könnte.
Kannst es aber auch so sehen, Fog Creek Software hat relativ wenig Mitarbeiter. 2011 40.
Neben Stackoverflow, haben sie zuvor einen Bugtracker betrieben und Trello entwickelt. Trello haben sie nebenbei dann für über 400 Mio. Dollar an Atlassian verkauft.
Das ist im Vergleich mit anderen Unternehmen und deren Mitarbeiterzahlen bemerkenswert.
Das da nicht alles selbst entwickelt wurde ist irgendwo klar und wenn man die Ergebnisse heranzieht, dann würde ich mich auch entscheiden die “Power” zu nutzen. Zumindest wenn es ums Geld verdienen geht. Privat und Hobby kann es natürlich anders aussehen.
Apropos, der Absatz über Experts Exchange, erinnert doch sehr an ein Forum zu einer nach Kaffee benannten Programmiersprache.
Trello hat auch eine sehr spezielle/effiziente Struktur:
Alles (!) ist auf Remote Work ausgelegt.
zB. heisst dass wenn auch nur eine Person im Team remote arbeitet, treffen sich alle im Videochat, aber nicht eine Person alleine und der Rest in einem Meetingraum, sondern alle auf der gleichen Ebene, d.h. alle sitzen alleine und kommunizieren nur per Videochat.
https://blog.trello.com/remote-work-team-success-guide
Man muss jetzt auch dazu sagen dass Trello noch keinen Profit abwirft, Atlassian and sich auch noch nicht, zumindest seit dem Boersengang, ich hoffe dass da bald anders wird 
Auch das ist nicht ungewoehnlich, zB. Twitter hat in 15 Jahren noch keinen Profit gemacht, ist zwar nicht ganz vergleichbar da „Socialmedia“.
Naja, alles selber nochmal zu loesen ist eben wenig rentabel, wozu heute noch seine eigene Cloud aufziehen, wie es frueher ueblich war, wenn es AWS gibt?
Es ging bei meinem Kommentar weniger um eine eigene Cloud+Infrastruktur. Im Gegenteil: Gerade das ist etwas, wo man services nutzen kann, wenn es sie gibt.
Ich denke jedenfalls, dass viele bzw. die meisten Informatiker, wenn sie die Wahl hätten, sich lieber nicht um die Frage kümmern wollen, ob in „ihrem“ Server irgendeine Linux-Version irgendeinen Patch für irgendeine Networking-Lib braucht, und wie danach irgendein init-bash-script angepasst werden muss. Oder einfacer: Ich denke, dass die wenigsten Informatiker gerne „Linux-Server-Administratoren“ sein wollen. (Einige ja, aber … das sind dann eben die Nerds 
)
Das Problem, auf das ich anspielen wollte, ist eher, dass die Infrastruktur so gesehen noch nicht einfach genug (nutzbar) ist. Wenn ein Entwickler sich nur noch damit beschäftigt, auf irgendwelchen AWS-Servern irgendwelche Docker-Container zu deployen, die Software enthält, die aus irgendwelchen NPM-Artefakten zusammengelöppelt ist, dann ist das schlecht. Erstens, weil letztere einfach ein verdammt wackliges technologisches Kartenhaus ist, und zweitens, weil ich glaube, dass es viele gibt, die schon gerne auch mal programmieren würden.
Aber ich postuliere das alles nicht. Es kann auch einfach sein, dass ich da zu sehr von mir auf andere schließe.
Was du beschreibst klingt schon nach DevOps (You build it, you run it), hat viele Vorteile IME, ist aber nicht immer jedermanns Bier, ist aber sehr populaer heutzutage speziell durch MicroServices in der Cloud.
Das ist alles programmieren, weil die Config eben als Code vorliegt, manche schreiben dann sogar tests, andere verlassen sich nur noch auf Monitoring.
Kartenhaus? Passiert da auch schon mal, aber dadurch dass man durch die Continuous Delivery sehr schnell feedback zu den Konsequenzen der eigenen Entscheidungen gibt, kann man sich sehr schnell anpassen, MicroServices sind per definition klein, viele davon werden schnell komplex, mehrmals am Tag in Prod zu deployen ist da normal.
IT und Softwareentwicklung ist ein weites Feld, da gibt es etwas fuer jeden, wenn einem eine Sache nicht zusagt, gibt es genug alternativen.
Was Docker wirklich geaendert hat war nicht Container einzufuehren, denn die gab es schon vorher, Docker hat es durch geschicktes Marketing/Hype geschafft dass sich SW Entwickler auch mal fuer den Betrieb der Anwendung interessieren anstatt das einfach ueber den Zaun ins naechste Silo zu werfen, wo dann ein „Admin“ sehen kann wie er den Rotz am laufen haelt den die SW Entwickler in ihrem Elfenbeinturm geschustert haben.
Bei DevOps geht es IMHO vor allem auch ueber eine „geschlossene Feedbackloop“, zB. so sexy man Scala auch finden mag, wenn man versucht die Stacktraces zu interpretieren sieht man auch mal die andere Seite der Medaille, wenn man meint alles & immer loggen zu muessen aber die Logs einfach nicht liest und sich schon gar nicht dafuer interessiert was dann in Prod wirklich relevant waere zu sehen, usw. usf.
Also eine Dockerfile, Jenkinsfile, Docker-Compose-File oder auch eine package.json sind für mich kein code. (Nicht alles, wofür es Syntax-Highlighting gibt, ist „code“ 
)
Das „Kartenhaus“ war eine Anspielung auf meine Lieblings-Draufhau-Stelle, nämlich „leftpad“. Aber die Skepsis geht da schon etwas weiter: So, wie ich das sehe, ist es recht einfach, irgendeine Lib in die NPM zu bringen. Anforderungen gibt es praktich keine. Und so wie ich das sehe, wird da - und da verwende ich bewußt diese profane Formulierung - teilweise der letzte Rotz in die Welt gekackt. Und Leute verlassen sich dann darauf, und wissen nicht, welche Zeitbomben als schwächstes Glied in einer langen dependency-Kette ticken.
(Man könnte argumentieren: „Das ist bei der Maven Central genauso“. Aber auch wenn es man da einen Vergleich ziehen könnte, sollte jeder, der ein bißchen bescheid weiß, wissen, dass dieser Vergleich nur auf eine Antwort hinauslaufen würde: „Nein!“).
Insgesamt klingt das, was du sagst, als hättest du über einige Dinge einen Überblick und eine Kontrolle, die … nun, subjektiv, ja, aber … die man als Softwareentwickler gar nicht haben müssen sollte.
Wie schon oft an anderen Stellen gesagt: Jobs, bei denen man wirklich Software entwickelt, scheint es kaum zu geben. Da bleibt nur, so viel wie unbedingt nötig von dem Scheiß zu machen, für den man Geld kriegt, und das Programmieren dann in die Freizeit zu verlagern.
Das klingt nun recht abwertend, und bezieht sich ja auch nur auf Serverseitiges. Natürlich kann ein gewisses Verständnis über den Tellerrand hinaus nie schaden. Und man könnte darüber streiten, wie viel davon für die jeweils andere Seite notwendig sein sollte. Aber dem „Admin“ kann egal sein, ob der Programmierer irgendwo eine abstrakte Klasse oder ein interface verwendet, und dem Programmierer kann egal sein, welcher Port nun auf irgendeinem Kack-Proxy freigeschaltet ist oder nicht. Aufgabenteilung muss sein (vgl. Fullstack: Alles ein bisschen, nichts richtig? )
Wie ist das denn mit dem Bash script?
Ansible, Chef, Puppet, etc. pp.
Ist alles Code.
NodeJS hat noch einen langen weg vor sich IMHO, ausser natuerlich es wird zuerst von etwas anderem halbfertigem abgeloest…
Naja, es kommt immer darauf an was man persoenlich als SW Entwicklung sieht.
Wie bereits gesagt, das kann sehr unterschiedlich ausfallen, je nachdem mit wem man so redet.
In der Luft- und Raumfahrt schien es mir, als ob mehrstuendige Meetings jeden Tag und tausende Seiten Dokumente lesen & schreiben dazu gehoerten.
Im Akademischen Bereich koennte das zB. eher Grundlagenforschung sein, vielleicht sogar so ganz ohne Termindruck oder gar Erwartungshaltung wo das ganze denn hin geht.
„In der Cloud“ gehoert nix davon dazu, aber dafuer die „Your write it, you run it“ Einstellung.
Mag sein dass es dir so vorkommt, aber das ist nicht abwertend gemeint, sondern realistisch von meiner Seite aus.
Der Punkt dabei: Das ist nicht der Tellerrand, das ist der Job!
Die „Definition of done“ ist in diesem Bereich nicht „Ich hab auf Master gemergerd, damit schliesse ich das Ticket und der Rest geht mich nix mehr an“, sondern „Der Kunde kann mein neues Feature nutzen“, d.h. also dass dein Code es bis zum Kunden schafft, am besten am selben Tag noch
Diese „Velocity“ schafft man nicht mit Silos & ganzen Abteilungen von „Fachdeppen“ ("Ich bin bei den SW Fachdeppen, im anderen Gebaeude sitzen die Adminfachdeppen, dahinten ist der Dokumenten- und Prozessfachdeppenverein, dann der QA Fachdeppenverein usw), mit Meetings, buerokratischen Prozessen und tonnenweise Dokumenten die man lesen und schreiben muss.
Der letzte Absatz war abwertend geschrieben
An der Bash verschwimmen die Grenzen. Ich bin nicht sicher, wie viel subjektive Beobachtungen ich hier jetzt breittreten darf oder sollte, aber ein Beispiel: Ich habe schon gesehen, wie ein Shell-Script einen Docker-Container hochfährt, in dem Docker-Container ein Shell-Script startet, das mit Python per Regular Expression in einer JavaScript-Datei eine String-Ersetzung durchführt, und die resultierende JavaScript-Datei mit GZip in ein Archiv packt, das für die Ausführung benötigt wird. Das ist nur eine Facette, vielleicht ein kleiner Auswuchs, aber mein Gesamteindruck ist, dass die Infrastrukturen, auf denen - etwas theatralisch formuliert - unsere Gesellschaft aufbaut, teilweise zumindest etwas wackelig und unausgegoren sind (und die Rechtfertigung: „das ist eine „““„pragmatische Lösung“„“" " bewirkt bei mir oft nur noch verständnisloses Kopfschütteln)
Das Augenzwinkern hier mag im ersten Moment angebracht erscheinen. Und ich glaube (und das ist nicht mal direkt ein subjektiver Eindruck, sondern vielleicht nur eine subjektive Vermutung), dass manche Leute ~„sich irgendwie nerdig-cool fühlen“, wenn sie irgendwelche halbgaren Libraries zusammenklöppeln und dann nur noch damit beschäftigt sind, die, die sich als „schlecht“ herausstellen (oder einfach „out“ sind), aus der Infrastruktur rauszuschälen und durch eine neuere zu ersetzen, die gerade „in“ ist.
(Für NodeJS und sowas wie Express gilt das in dieser Form wohl nicht. Das hat sich ja wohl schon festgerüttelt. Es geht eher um alles, was darauf aufbaut oder daran anklinkt, und was „nach oben hin“ immer wackliger zu werden scheint)
Trotzdem denke ich, dass mit abnehmender Spezialisierung praktisch zwangsläufig die Qualität an allen Stellen leidet. Die Schnittstellen sind „nicht mehr so gut“. Der Code ist „nicht mehr so gut“. Der build-Prozess und das Deployment sind „nicht mehr so gut“. Weil einfach bei all diesen Punkten gute Lösungen extrem aufwändig sind und viel Erfahrung verlangen. (Das mag OK sein, für Fälle, wo „die 64%-Lösung“ ausreicht, aber ich glaube, dass sich das an vielen Stellen recht schnell rächen wird).
Dem entgegen wirken kann/könnte man nur, wenn man gezielt daruf hinarbeiten würde, die einzelnen Teile leichter handhabbar und „robuster“ zu machen. Aber dem stehen hohe Volatilität, Fragmentierung und kurzfristiges Denken und Handeln im Weg.
Ich glaube, dass es für reine „Programmierer“ immer weniger Verwendung gibt. Es gehört zum Job zu wissen, auf welcher Infrastruktur meine Anwendung läuft. Es gehört zum Job zu wissen, wie die Last skalieren muss und welche Infrastruktur dafür sinnvoll ist. Genauso gehört es zum Job, ob eine Oracle für die Anwendung richtig ist, oder doch eher eine Elasticsearch o.ä.
Das muss natürlich nicht nur eine Person wissen. Das muss das Team aber wissen. Das bedeutet, dass es im Team auch immer mehr Leute gibt, die sich betrieblich auskennen.
Speichernutzung, CPU-Last, Datenbank, robuste Kommunikation, Resilienz. Das sind alles Themen, die sowohl den Betrieb als auch die Entwicklung interessieren sollten. Und diese beiden Parteien sollten miteinander arbeiten und sprechen können. Das bedeutet nicht, dass die Hauptaufgabe eines Entwicklers die Konfiguration eines Apaches oder nginx ist, aber man sollte in der Lage sein, die Probleme dahinter zu verstehen.
Ich kann mit reinen „Programmierern“ immer weniger anfangen. Engagierte Leute schauen dann (meiner Erfahrung nach) weiter über den Tellerrand und machen sich über Betrieb und Deployment Gedanken.
Was meinst Du denn mit Qualität? Wo genau soll diese leiden? Das muss ja nicht immer eine Person alleine stemmen. Und natürlich kann und darf man sich auch Spezialisieren. Man kann sicher nicht in allem perfekt sein. Aber helfen können, sollte man sich.
Ich kenne noch die Zeiten, wo das Thema DB, Performanz und ähnliches immer an den Betrieb abgegeben werden konnte. Das ist (imho) mittlerweile häufig nicht mehr der Fall. Und von einer schwindenden Qualität kann ich nicht mehr sprechen. Im Gegenteil. Die Anwendungen werden robuster - gerade weil man bei diesen Themen mit eingebunden und verantwortlich ist.
Nun, die Frage nach der Qualität könnte man auf unterschiedlichSTen Ebenen beantworten, mit unterschiedlichSTen Detailstufen.
Ganz platt: Wenn man als Programmierer 6 Stunden programmiert und 2 Stunden deployt, ist das, was man in den 6 Stunden macht, fast(!) schon zwangsläufig „besser“, als wenn man nur 2 Stunden programmiert, 2 Stunden Dockert, 2 Stunden Proxies konfiguriert und 2 Stunden deployt. Aber da kommt es dann vielleicht auch drauf an, welchen Anspruch man an sich und seine Arbeit hat 
Aber mal im Ernst: Wenn Leute, die an der Uni ein bißchen was mit JavaScript gemacht haben und sich jeden Tag stolz die download-Zahlen ihrer grandiosen NPM-Lib mit dem namen „rightpad“ ansehen nun „plötzlich“ „nebenbei“ mal einen nginx oder DB-server konfigurieren müssen, braucht es einen nicht zu wundern, wenn (und sei es nur aufgrund mangelnder Erfahrung) dann irgendwas suboptimal läuft, oder im ungünstigsten Fall eine Sicherheitslücke im System klafft, und die ganzen Admins, wenn sie dann die Schlagzeiele über den neuesten Datenklau und das daraufhin pleite gegangene Unternehmen auf Heise lesen, entsetzt aufschreien: „Booah, wie kann man nur so blöd sein und bei MongoDB für Client- und Member-x.509-Zertifikat die gleichen O/OU/DC verwenden?“ oder „Wahnsinn, die haben in der nginx.conf .php per fastcgi_pass ans backend geschickt, die sind ja komplett bescheuert!“.
Aber so läuft das heute wohl. Alles gut.
TODO: Bezug zwischen Threadtitel und Spiderman herstellen
Das ist schon wirklich platt. 
Es muss ja nicht jeden Tag „gedockert“ werden. Die Automatisierung einer Deploymentpipeline kostet sicherlich Zeit und Geld, wird aber mittlerweile wirklich gut durch Tools unterstützt. Und Proxies müssen auch nicht die ganze Zeit konfiguriert werden. Und wie gesagt: das Wissen muss auch nicht bei jedem Einzelnen liegen, sondern im Team.
Aber wenn z.B. mein Dienst nicht erreichbar ist, sollte ich schon die Möglichkeiten haben, das Problem zu verstehen und analysieren zu können. Früher war es normal, dass der Entwickler sagte „Ich habe mein WAR und gut“. Heute ist das nicht mehr so. Wenn ich 100 Microservices aufsetze und alles gegen eine DB geht muss ich schon wissen, dass es Probleme mit dem Connections geben kann.
Die Grenze zwischen Betrieb und Entwicklung ist nicht mehr so streng wie vor 10 Jahren.
(natürlich alles meine persönliche Meinung)
Vielleicht liegt es daran, dass ich hier irgendwas überbewerte. Natürlich kann es nicht schaden, wenn das Wissen breiter gestreut ist (vgl. Truck Number – Wikipedia ). Aber es geht nicht nur um Wissen, sondern auch um Verantwortung. Aber wer will die schon 
Das stimmt und ist nicht grundsätzlich falsch. Aber zu erwarten, dass jemand von der Uni kommt, und dann eine REST-basierte Anwendung mit NodeJS/Express in Docker-Containern in die AWS-Cloud bringt und den NGING-Proxy richtig konfiguriert, damit man per React-Interface auf den Service zugreifen kann, ist schlicht lächerlich-naiv und aus meiner Sicht ist es dann nur eine Frage der Zeit, bis es irgendwo kracht.
(Vermutlich würden viele ~~„„das irgendwie hinkriegen““, (stackoverflow sei dank ), aber das Ergebnis wäre sicher auf allen erdenklichen Ebenen und in jeder erdenklichen Hinsicht „nicht gut“. Entgegen anders lautender Gerüchte und ganz bewußt entgegen der vermeintlichen (!) Evidenz, dass es anders ist, denke ich immer noch, dass man zumindest ein bißchen Ahnung von dem haben sollte, was man tut, und sich bei seinen „„Erfolgen““ nicht auf ein geradezu verspielt-gespielt-geekiges „Yeeaaah, ich hab’s zum Laufen gekriegt“ berufen sollte…)
Naja, klingt nicht viel schlimmer, als ein Entwickler und ein Admin (die schlechter ausgebildet sind als der eine Entwickler, damit sie zusammen nicht mehr Gehalt kosten), welche das ganz altmodisch umsetzen und dabei kein Mal miteinander reden
Ich bezweifle, dass das irgendwer gänzlich anders sieht.
Es geht bei DevOps ja auch gar nicht darum, irgendwen mit Ahnung loszuwerden, sondern einfach die strikte Trennung aufzuheben. In obigem Beispiel kann der Admin trotzdem noch beim Konfigurieren des Docker-Image, des AWS-AMI und des NGINX involviert sein.
Das „kein Mal miteinander reden“ ist am unteren Ende des slippery slope, aber damit natürlich genau passend, zu dem, was ich geschrieben hatte 
Vielleicht geht es dabei viel um die ungeklärte Frage, auf welcher Ebene man sich spezialisiert, oder welche Ebene für die eigene Arbeit und die (wenn auch recht abstrakte) „Qualität“ der Ergebnisse relevant ist. Noch abstrakter könnte man „Qualifikationen“ als Gausskurven in verschiedenen Dimensionen sehen, und sagen, dass es nur um die Frage geht, welche der Kurven sich in welchem Individuum wie überlagern.
Als Suggestivbeispiel: Ich könnte zwar keine docker-compose.yml from scratch schreiben, aber eine Swing-Anwendung, die einen Temperaturverlauf als LineChart zeichnet (und auch wenn ich da schon recht aus der Übung bin glaube ich, dass ich mit einem Texteditor Code schreiben könnte, in dem dann nicht irgendwo ein Semikolon fehlt oder so…). Ich weiß zwar nichts von NGINX, aber habe eine recht genaue Vorstellung davon, wie viele aaload-Instruktionen im bytecode einer Methode vorkommen, die ich schreibe. Und wenn ich ein interface definiere, überlege ich, ob das nun ein Monoid, eine Gruppe oder ein Ring ist. Relevant? Nein. Leider. Aber so ist das eben.
Allgemein wird wohl kaum jemand widersprechen, wenn ich sage, dass jede Anforderung, d.h. Aufgabe, deren Erledigung einerseits schlicht Zeit benötigt, andererseits aber auch eine Qualifikation erfordert, die man sich erstmal draufschaffen muss, bewirkt, dass für die Kernaufgabe von Softwareentwicklern (und für die, denen das nicht klar ist: Das war mal „Software entwickeln“) weniger Zeit übrig bleibt, und das sehr negative Konsequenzen haben kann.
Generell stimme ich dir da zu.
Wenn ich mich so umsehe mit Facebook, Amazon, eBay, den ganzen Onlineshops, Portalen um einen Urlaub zu buchen oder jemanden zu suchen der mir den Umzug macht usw. usf. komme ich zum Schluss, das es so anscheinend gut genug ist.
Wenn wir mal ehrlich sind, stirbt niemand selbst wenn es schwere bugs gibt bei dieser Art SW, wird ja weder im Kernkraftwerk eingesetzt noch heilt man Krebs, wobei letzteres immer im Bereich des Moeglichen liegt.
In diesem Umfeld laesst man neue Features etc. erst auf einen kleinen Teil der Anwender/Maschinen los und sieht sich dann an was so passiert.
Wenn man Spezialisten fuer bestimmte Bereiche hat, bekommt man ausgefeiltere Loesungen, oft braucht man fuer die Wartung und Erweiterung dieser Systeme dann aber eben auch Spezialisten, enn nicht gar ein ganzes Team
Wenn man zB. jetzt ein Team hat dass nicht nur auf Builds und Releases spezialisiert sind sondern auch Features machen, werden diese oft einfachere Systeme bauen die sich einfacher warten und erweitern lassen, zumindest ist das die Hoffnung.
Trotzdem gibt es spezialisierte Teams („Gilds“) in groesseren Firmen fuer B&R, in einem 10 Kopf Startup mit 4,5 Entwicklern ( inkl. einem Praktikanten und einem teilzeit Coder), sieht es da schon anders aus.
Will das hier eigentlich gar nicht zu einer Diskussion von fuer und wider DevOps etc. machen, denn DevOps passt nicht ueberall, Desktop SW ist nicht tot, nur im Moment etwas weniger hipp, wird in der einen oder anderen Form wiederkommen.
Ja, und wenn Facebook Daten weitergibt, ist das ja ohnehin kein versehentliches Datenleck, sondern Absicht 
Mal im Ernst, es gibt natürlich schlimmeres, aber teilweise klaffen wohl schon einige Sicherheitslücken an den verschiedensten Stellen. Und (auch wenn sich das jetzt auf eine andere Ebene begibt) wünsche ich dir, dass du nie eine Anwendung warten musst, die jemand im MERN-Stack zusammgebastelt hat, der da zwar wie ein Mistkäfer am Ende ein schöne, rundes Docker-Päckchen draus gemacht hat, was im Kern aber eben doch das bleibt, was es ist - nämlich Mist.
Mittlerweile soll es ja String-Padding geben. Kein padleft mehr nötig. Nennt sich aber padStart und padEnd. ECMAScript 2017.
Aber nachdem ich diese Stellenanzeige hier gelesen habe, (Node.js Backend-Webentwickler (m/w) als Aushilfe) und man da nur nach einer Aushilfe sucht, ja dann kann das ganze doch garnicht so schwierig sein. Wird wohl auch nicht schwieriger sein, als ein Flugzeug zu fliegen oder einen Zug zu führen. Die suchen auch ständig Aushilfen. 