Was macht eine gute Führungskraft, einen guten Manager oder ein gutes Teammitglied aus? Manchmal ist jemand, der Manager ist, zugleich für jemand anderen ein Teammitglied …

 

Danke für die Normalisierung mit Electron …

 

Es erscheinen jeden Tag so viele Projekte, dass ich es wahrscheinlich sofort ausprobieren würde, wenn es wenigstens einen Screenshot gäbe.

 

Irgendwie sind die Leute überall auf der Welt doch gleich. :)

 

Unter Linux funktioniert es nicht 😭

 

Klar~ Schon allein ein so formulierter Beitrag hat ausgereicht, um die Absicht deutlich zu machen.

 

IDE und PR sind schon alle tot, aber der Code ist wiederauferstanden?

 

Ja, derzeit prallen tatsächlich zwei Sichtweisen aufeinander. Meist wird über die Ersetzungsthese gesprochen, und gelegentlich taucht der Optimismus auf, wie auch in diesem Artikel.

Niemand kann wissen, wie die Zukunft der Arbeit tatsächlich aussehen wird. Aber wenn die vorherrschende These die Ersetzung ist, dann halte ich es für sinnvoll, sich auch die Gegenposition anzusehen.

Es gibt viele Argumentationslinien innerhalb des Optimismus, aber ich habe hier eine der älteren Theorien herangezogen: das Jevons-Paradoxon. Derzeit sinken auf dem Markt durch die Entwicklung von Einzelentwicklern zu Ein-Personen-Unternehmen die Preise tatsächlich schnell, angefangen bei einfachen Web-Vorstellungsseiten. Dadurch kommen auch kleine Gewerbetreibende und mittelständische Unternehmen, die bisher nicht einmal daran gedacht hatten, eine Website zu erstellen, zunehmend dazu, jeweils eine recht ansehnliche Website zu besitzen. Mit anderen Worten: Ich bin zu dem Schluss gekommen, dass der Trend grundsätzlich stimmt, dass nämlich der Markt selbst wächst. Besonders SaaS-Angebote kommen derzeit beinahe täglich auf den Markt, und auch der Preiswettbewerb verschärft sich merklich. Wenn die Preise sinken, werden mehr Unternehmen und Einzelpersonen solche Lösungen einführen, und der Markt selbst wird ganz klar wachsen.

Danach dürfte die Richtung wohl eine von zwei sein: Entweder erhöht eine einzelne Person immer weiter die Zahl der Services, die sie betreut, oder es kommt ein weiterer Entwickler hinzu, der diese Nachfrage auffängt. Da die Menge, die Menschen verarbeiten und verwalten können, zwangsläufig begrenzt ist, habe ich vermutet, dass sich am Ende vielleicht wieder ein Trend entwickeln könnte, Junior-Entwickler einzustellen, um diese Nachfrage zu bewältigen. (Schließlich waren es Junior-Entwickler, die in der Zwischenzeit vom Markt ausgegrenzt worden sind.)

Natürlich werden die Fähigkeiten, die dann von Junior-Entwicklern verlangt werden, sich sehr stark von den heutigen unterscheiden. Und ich weiß auch nicht, ob das beim Gehalt noch so sein wird wie früher. Ehrlich gesagt habe ich auch keine gute Vorstellung davon, wann dieser Zeitpunkt kommen könnte. Schluchz.

Und vielen Dank, dass Sie den Artikel gelesen und die Analyse so sorgfältig vorgenommen haben~ Es ist schön, dabei etwas gelernt zu haben.

 

Um die Perspektive des Jevons-Paradoxons einzubeziehen, muss man zunächst festlegen, was hier überhaupt die Ressource ist.
Da es sich um einen Beitrag zur Analyse der Nachfrage nach Entwicklern handelt, sollte die Ressource in diesem Text der Entwickler sein.

  • Die Branchen, die das Jevons-Paradoxon klassisch beschreibt (Dampfmaschine <-> Kohle), und die Softwarebranche unterscheiden sich in vielerlei Hinsicht.
    • Digitale Güter sind nicht-rivalisierende Güter, und es handelt sich um eine Branche mit nahezu null Grenzkosten. Also eine Branche, die von Fixkosten geprägt ist.
    • In einer solchen Branche verlaufen Produktivitätssteigerungen typischerweise in Richtung Personalabbau oder Einstellungsstopp sowie stärkere Hebelung des bestehenden Personals.
  • Damit das Jevons-Paradoxon greift, muss die Nachfrage sehr preissensibel sein, und Kostensenkungen müssen direkt zu einer Nachfragexplosion führen.
    • Softwareentwicklung wird nicht von einem Entwickler allein betrieben. Der Engpass sind nicht die „Coding-Kosten“, sondern Kosten für Planung, Risiko, Betrieb, Organisation und Regulierung.
    • Bisher wurden die meisten Softwareprojekte nicht deshalb nicht umgesetzt, weil Software zu teuer war, sondern weil „sie nicht nötig war / sich der ROI nicht rechnete / sie nicht betrieben werden konnte“.
  • Es gibt eine Täuschung durch Produktivitätskennzahlen.
    • Die im Beitrag verwendeten Kennzahlen (mehr generierter Code, mehr PRs, mehr Deployments) sind allesamt Kennzahlen für „Aktivitätsvolumen“.
    • Mehr Code bedeutet nicht automatisch mehr Wert. Mehr PRs führen zu höheren Review- und Validierungskosten, und AI-Code erhöht Qualitäts- und Sicherheitsrisiken.
    • Das heißt, durch AI-Code steigen technische Schulden, Debugging-Kosten und die operative Komplexität.
    • Daher muss eine Produktivitätssteigerung nicht in demselben dramatischen Maß zunehmen wie Aktivitätskennzahlen.
  • Die „Junior-Klippe“ anzuerkennen und gleichzeitig optimistisch zu bleiben, ist widersprüchlich.
    • Entwickler unterscheiden sich von Kohle dadurch, dass sie sich von Junior zu Senior entwickeln.
    • Wenn es weniger Juniors gibt, gibt es künftig auch weniger Seniors. Langfristig schrumpft daher der gesamte Entwicklerpool.
  • Marktwachstum und Beschäftigungswachstum sind nicht dasselbe.
    • Gerade AI ist eine kapitalintensive Branche und keine „Branche, die mehr Menschen einsetzt“, sondern eine „Branche, die mit weniger Personal größere Größenordnungen schafft“.
  • Entwickler sind Menschen, und menschliche Löhne haben andere Eigenschaften als der Preis von Kohle.
    • Auf dem Arbeitsmarkt sinken Löhne nicht vollkommen flexibel, weshalb Kostensenkungen nicht ausreichend in niedrigere Preise weitergegeben werden.
    • Löhne haben tatsächlich eine Abwärtsrigidität. Das liegt etwa an Mindestlohn, Arbeitsrecht, Vertragsstrukturen, interner Fairness in Organisationen sowie Risiken für Moral und Fluktuation.
    • Das heißt: Wenn die Produktivität steigt, senken Unternehmen nicht die Löhne, sondern reduzieren Einstellungen.
 

„Das Problem ist, dass es einen unbestimmten Vibe mit einer präzisen Abstraktion verwechselt“ – dem stimme ich zu. Abstraktion ist schließlich nur für diejenigen möglich, die die Low-Level-Ebene Bottom-up verstanden haben.

 

Wenn etwas, das früher funktioniert hat, nicht mehr geht, ist das natürlich unbequem. Aber allein dafür, dass all die Spaghetti-Konstruktionen aus X11 beseitigt wurden, mit denen man sich mühsam behelfen musste, gibt es schon genug Grund für Anerkennung.
Wenn man sich allerdings anschaut, warum manches immer noch nicht funktioniert, ist am Ende fehlende Standardisierung das Problem, und es stimmt auch, dass dieser Prozess länger dauert als gedacht.
Wahrscheinlich wird man selbst 2030 noch sagen, dass es bis zur Fertigstellung weit ist, aber eine Rückkehr zu X11 wird unmöglich sein.
Selbst wenn der Wechsel des Ökosystems chaotisch ist, wird sich ein Ersatz am Ende dieselben Vorwürfe anhören müssen, und eine Rückkehr dürfte eher Widerstand aus einem inzwischen daran gewöhnten Ökosystem hervorrufen.

 

Früher habe ich irgendwo den Vorschlag gesehen, auf Koreanisch statt „Hundefutter essen“ lieber „Hausmannskost essen“ zu sagen, und „Hausmannskost essen“ klang auch ziemlich gut.

 

Ich denke, man sollte prüfen, ob sich das durch andere Verifizierungsmethoden ersetzen lässt. Je näher man am Frontend ist, desto eher lässt sich wohl schon allein mit E2E über das Verhalten im Browser verifizieren, dass es korrekt funktioniert. Aber je näher der Code am Backend oder an der Infrastruktur ist, desto unverzichtbarer scheint ein Code-Review zu sein. Andernfalls wäre es schwierig, Side Effects zu verifizieren, die man nicht direkt sieht, etwa dass Transaktionen geöffnet und geschlossen werden oder API-Calls ausgelöst werden.

 

Ich frage mich, wann endlich ein WYSIWYG für WinUI 3 kommt.

 

1 Million Zeilen Code mit 13 Milliarden Tokens generiert ... wirklich beeindruckend.
Vielen Dank! Ich werde es gut ausprobieren und später auch einen Erfahrungsbericht in meinem Blog teilen, haha.

 

Schon am Aktienkurs in diesem KI-Klicki-Zeitalter sieht man, dass die Ära von Adobe zu Ende zu gehen scheint.

 

Ich habe bisher nur DBeaver benutzt, aber das sollte ich wohl mal ausprobieren, haha.