Gewohnheiten von Softwareentwickelnden
2025.12.19 | Dr. Sven Köppel | DenktMit Blog
Ich habe die letzten Wochen vermehrt mit Anfängern in der IT-Branche zu tun gehabt, die im Rahmen von Studium oder Ausbildung versuchen, im Tätigkeitsfeld von Softwareentwickler:innen Fuß zu fassen (darunter fasse ich insbesondere die Rolle von Programmierer:innen). Insbesondere bin ich froh, 2026 meinen ersten Auszubildenden in diesem Bereich zu unterstützen.
Das Ziel dieses Blogartikels ist es, die typischen Angewohnheiten (Habits) von Personen in diesem Berufsfeld zu beleuchten, also vor allem die erfolgreichen Verhaltensmuster. Das hat einmal zum Zweck, dass Interessenten eine bessere Vorstellung davon bekommen, ob ihnen diese Art der Arbeit prinzipiell Spaß macht und beabsichtigt darüberhinaus, den "Berufseinstieg" zu vereinfachen.
Als Disclaimer kommt zu Beginn aber ein Thema, das viele IT-Berufsanfänger und -Interessierte derzeit herumtreibt, und zwar die Künstliche Intelligenz.
AI und Junior-Devs
AI to replace junior staff ist eine Erzählung (Folklore) der aktuellen AI-Bubble. Meiner Meinung nach handelt es sich dabei um ein bewusst überspitzt eingesetztes rethorisches Stilmittel, mit dem Tech-CEOs Aufmerksamkeit und Schlagzeilen erzeugen wollen. Gleichzeitig eignet sich diese Erzählung gut als Ablenkung von zurückhaltenden Neueinstellungen oder Personalabbau in Zeiten von Unternehmens- oder Wirtschaftskrisen.
Programmieranfänger:innen können LLMs gezielt verwenden um besser zu lernen. Dazu sollte man Prompts schreiben, die der KI exakt das klar machen. Hier sind zwei Beispiele, wie der Prompt "ich habe folgende Ǘbungsaufgabe gestellt bekommen, löse sie für mich in Python" verbessert werden kann:
- Entweder zusätzlich: "Schreibe die Lösung, aber erkläre Syntax und Semantik jeder Zeile, jeden Funktionsaufruf, jedes Sprachkonstrukt. Erkläre warum du deine Lösung so geschrieben hast und welche Alternativen zur Verfügung ständen, welche Vor- und Nachteile sie hätten, welche Varianten es gibt"
- Statt "löse diese Übungsaufgabe" schreibe doch: "das ist meine Übung, aber ich weiß nicht wo ich anfangen soll. Nimm die Rolle meines Lehrers ein und gebe mir Stück für Stück Tipps und Hilfestellungen, wie ich diese Aufgabe alleine bewältigen kann".
Prompt Engineering ist eine Tätigkeit, die fast etwas von Programmieren hat: Mithilfe von guten Prompts kann man statt KI-Einheitsbrühe auch Werkzeuge erstellen, die einem nicht um den Lernerfolg berauben sondern einen darauf hinführen.
Nun aber meine Takes bzgl. positiven Verhaltensweisen, sie sind unsortiert, die Reihenfolge spielt keine Rolle.
(A) Lernen
Die alte Mär von der schnelllebigen Informatik gilt in manchen Anwendungsbereichen (Branchen) mehr als in anderen. Soll heißen: Es gibt den Bereich etablierter Banken und Versicherungen, wo man es sich mit Legacy-Werkzeugen jahrzehntelang bequem machen kann, wohngegen das Tooling in der Webentwicklung seit jeher rasanten Änderungen unterlegen ist. "Lernen" bedeutet hier nicht "büffeln" wie vor einer großen Prüfung, sondern ist eher die Bemühung für und die Empfänglichkeit von Hintergrundbeschallung, etwa in dem man regelmäßig Fachmagazine, -Websiten/Blogs oder Büchern. Esi ist auch das intrinsische Interesse und möglicherweise die Neugierde daran, auf dem Stand der Dinge zu bleiben.
Dies passiert meiner Wahrnehmung nach zu großen Teilen auch in der Freizeit: Vom Arbeitgeber bezahlte berufliche Weiterbildungen und Fortbildungen ergänzen hier lediglich. Die Möglichkeiten, wie man sich auf dem Laufenden hält sind vielfältig. Aber wer sich so etwas prinzipiell nicht vorstellen kann, ist in dem Beruf falsch aufgehoben.
Die Lerngegenstände sind vielfältig: Von bislang unbekannten Modellierungen/Abstraktionen über Konzepte aus der theoretischen Informatik, die nun in der Praxis ankommen bis hin zu neuen Softwareversionen, Sicherheitslücken, dem Stand der Technik oder Methoden, die in einer anderen Branche Verwendung finden.
Eine anstrengende, aber fruchtbare Möglichkeit zu Lernen ist das Studium von Open Source-Codes. Das ist eine der schwierigsten Übungen, die aber zu vielen Aha-Momenten führen kann. Am Anfang steht in der Regel das Verstehen der Verzeichnisstrukturen und Build-Systeme, der Organisation des Codes, seiner Abhängigkeiten (Libraries) und der Architektur der Komponenten. Zweifelsohne eignen sich manche Codes hier besser als andere. Es ist nicht falsch, das Studium eines schlecht dokumentierten Codes abzubrechen um eine bessere Wissensquelle zu finden.
Letztlich steht hinter dem "lebenslangen Lernen" auch der Anspruch der stetigen Verbesserung. Viele Entwickler:innen sind ständig auf der Suche nach besseren Lösungen. Auch wenn man nicht die Branche wechseln möchte, kann es trotzdem hilfreich sein, andere Programmiersprachen, Software-Ökosysteme, Patterns und Frameworks kennenzulernen.
(B) Side Projects
Softwareentwickelnde sind Bastler:innen, und bei solchen Menschen verschwimmen Beruf und Hobby. Entsprechend haben sie häufig private "Nebenprojekte" (side projects) die als Motivationsbooster dienen. Oft braucht man einen Anwendungsfall, um eine neue Technologie auszuprobieren, und da eignet sich der private Bereich manchmal eher als der berufliche. Ein verbreitetes Beispiel ist ein heimischer Raspberry Pi-Cluster "zum Selbstzweck", einfach nur um daran zu lernen. Auch die intensive Benutzung des Linux-Desktops zumindest "probeweise" zählt dazu. Im Übrigen verwenden fast alle guten Softwareentwickelnden die ich kenne Linux oder zumindest Mac als primäres Betriebssystem auf ihren Desktops/Laptops.
Manche Personen betreiben ihre jahrelangen Nebenprojekte auf einem derart hohen qualitativen Niveau, welches jeder Beschreibung trotzt. Ihren Stolz darauf bringen sie gelegentlich durch die Veröffentlichung der Tätigkeit oder eines Arbeitsergebnisses auf privaten Websiten oder auf Github zum Ausdruck. Ein solches Aushängeschild, das Taten sprechen lässt, kann mehr Wert sein als eine Qualifikation auf dem Lebenslauf. Ich denke, dass viele Softwareentwickler:innen genießen, Dinge zu erschaffen und zu erzeugen und das auch gerne zeigen. Digitales ist manchmal intrinsisch zeitlos, sodass manche Entwickler:innen einen Ewigkeitsanspruch für ihre Software und Daten entwickeln, der sich in der Realität in der Regel nicht bewahrheitet.
Bei manchen Personen nehmen Nebenprojekte auch einen signifikanten Teil der Freizeit ein und tragen wesentlich zur Selbstidentifikation bei. (Nicht nur) bei Softwareentwickelnden gibt es das Klischee oder Ideal des Flows, also einer Art "mentalem Schaffensrausch". Im Klischee entstehen die besten Codes in der Nacht, bei Trance-Musik, in Dunkelheit vor drei Bildschirmen. Die Realität sieht wahrscheinlich bei den wenigsten so aus.
Programmierer:innen können regelmäßig selbst beeinflussen, ob sie sich in ihren Fähigkeiten und den nötigen Anforderungen unterfordert, überfordert oder flow-förderlich genau richtig fordert, wie die nachfolgende Illusration verbildlicht. Damit ist Programmieren eine Tätigkeit, die den "Flow" gut hervorrufen kann.
Man kann wunderbar eine Karriere in der IT-Welt machen, ohne jemals in "den Flow" zu kommen, als 9-to-5-Job, ohne IT-affine Hobbies. Wahrscheinlich könnendie Personen, die die Aspekte von Praxiserfahrung und Weiterbildung nebenbei auch im Privaten machen, allerdings erfüllter und inhaltlich besser ihrem Berufsleben nachgehen.
(C) Kommunikation
Eine faszinierende Eigenschaft der IT-Welt sind die vielfältigen Perspektiven, die sich einnehmen lassen. Nicht wenige reduzieren Informatik auf Kommunikation und deuten Quellcode als eine Art und Weise, unter Menschen über Computer und Algorithmen zu sprechen, ähnlich der Sprache der Mathematik. Eine drastische Art ist auch, Informatik-Tätigkeiten als wertlos zu bezeichnen, wenn sie nicht einer Anwender:in bzw. fachfremden Person einfach erklärt werden können. In anderen Worten: Was nützt das beste Programm, wenn es keiner bedienen kann?
Ich kenne einige gute "Senior Devs", die miserable Mitmenschen abgeben. Sie sind dissozial und werden nur in einem Team IT-Schaffender erfolgreich, wo sie ihre Inselbegabung ausleben können ohne Schaden an Mitmenschen oder Firmenwerten anzurichten. Die wirklich richtig guten Entwickler die ich kenne eint aber allesamt eine überragende Kommunikationsfähigkeit, etwa in Form einer reichhaltigen Wortbegabung, einem feinen Gespür für Mitmenschen und einem hohen Einfühlungsvermögen (passende Begriffe sind vielleicht "emotionale Intelligenz" und "Empathie"). Ich bin der Überzeugung, dass eine Kernkompetenz erfolgreicher fortgeschrittener Personen in dem IT-Umfeld ist, für komplexe Systeme menschliche und formale Sprache zu finden.
Eine Berufskrankheit von Ingeneur:innen, Techniker:innen, Mathematiker:innen oder auch Naturwissenschaftler:innen ist es, den Dingen nicht nur ganz genau auf den Grund zu gehen sondern sie auch sehr präzise und exakt aufzuschreiben und zu kommunizieren. Was innerhalb der Branche und im Kollegialgespräch eine essentielle Fähigkeit ist, kann sehr abschreckend sein wenn man mit Nicht-ITlern spricht. Ich finde einen gesunden Pragmatismus wichtig, "know your audience". Eine Unexaktheit ist angebracht, wenn sie zur vereinfachten Kommunikation eines Sachverhaltes sachdienlich ist.
Folgende Grafik ist entstammt eigentlich einem Dokumentationsmodell (auch schön hier erläutert), ich finde sie aber auch praktikabel für die persönliche Einordnung hinsichtlich Vorlieben von Dokumentation und Zugang zu IT-Systemen:
Das Diagramm hat zwei Achsen:
- Horizontal "lernen vs. anwenden": Steht im Vordergrund eher das Lernen oder das Arbeiten?
- Vertikal "tätig vs. kognitiv": Steht im Vordergrund eher die praktische Tätigkeit oder der begreifend-theoretische Aspekt?
Entsprechend findet sich
- oben links der "Praktische Lerner", eine Person die am besten mit Tutorials arbeitet.
- unten links findet sich hingegen der "Verständnis-orientierte Lerner", eine Person die Erklärungen lesen möchte wie in einem Sachbuch, mit Hintergrundwissen.
- Oben rechts ist der zielorientierte/problemorientierte Lerner, welcher mit Howto-Guides glücklich ist. Während sich ein Tutorial an Anfänger richtet, ist eine Howto-Anleitung eher mit einem Kochrezept vergleichbar: Klarer Fokus auf Schritte und Ergebnisse, keine Erklärung von Konzepten.
- Unten rechts ist schließlich der "informationsorientierte Lerner*, welche mit Referenzen glücklich ist. Eine Referenz ist eine akurate technische Beschreibung der Maschine wie in einer Enzyklopädie.
Ich zähle mich übrigens ganz klar zu den unteren beiden Kategorien, ich bin mit einer theoretischen Information oft schon ganz glücklich. Dadurch habe ich aber beim Schreiben von Dokumentationen immer einen Hang dazu (Bias), etwas zu theoretisch die Grundlagen und Hintergründe zu erklären, statt die "hands on"-Erfahrung, die vielen praktischer veranlagten Personen wichtig ist.
(D) Autodidaktik
Ich habe noch nie einen Programmierkurs gesehen, bei dem die Teilnehmenden vorher nicht und nachher schon programmieren konnten. Meiner Meinung nach ist diese Tätigkeit nur im Selbststudium "autodidaktisch" wirklich erlernbar. Mir fallen zum Programmieren viele Metaphern ein, etwa das Fahrradfahren, das Handwerk, Sport, Musik und Kunst.
Am eingängigsten ist vielleicht das Fahrradfahren: Es zu Lernen ist schwer, weil die Kinder sich das dynamische Gleichgewicht nicht vorstellen können und nur durch viele Wiederholung "den Dreh rauskriegen". Einmal gelernt lautet das Sprichwort: "Fahrradfahren verlernt man nicht mehr". Auch beim Erlernen einer kreativen Tätigkeit wie der Beherrschung eines Musikinstrumentes, einer angewandten oder darstellenden künstlerischen Tätigkeit, der Beherrschung einer Sportart oder der bloßen körperlichen Ertüchtigung als solchen wird eine Lernkurve absolviert die nicht zwangsläufig einen hohen kognitiven Anspruch voraussetzt, sondern als Fertigkeit in "Fleisch und Blut" übergeht. Ich bin kein Freund vom Konzept der "Begabung" und denke dass insbesondere im Bereich der Softwareentwicklung jeder Mensch die Fähigkeit dazu hat, digitale Erzeugnisse zu schaffen. Häufig kommt der Weg zum Programmieren so durch das Hintertürchen, etwa das Scripten von Routineaufgaben in Medienbearbeitungsprogrammen (etwa Videoschnitt, 3D-Skulpturen, usw).
Bezeichnend für Programmiertätigkeiten ist der prinzipiell geringe Materialeinsatz: Ein Laptop genügt. So ist die Softwareentwicklung ein "Geistessport", in dem natürlich viele Menschen einen Vorsprung haben die ihn schon lange betreiben oder ihn unter vorteilshaften Bedingungen ausführen können. Ich finde die Egalität von Software(entwicklung) faszinierend, weil sie Menschen auf der ganzen Welt eint. Es gibt das Klischee, dass es über jedes IT-Thema ein Youtube-Video von einem Inder gibt. Ist es nicht fabelhaft, dass es in unserer Zeit möglich ist, quer über alle Kontinente, Kulturen, Hautfarben, Altersklassen, Ausbildungswege usw. Wissen zu vermitteln und gemeinsam zu lernen?
Ich bin der Überzeugung, dass sich Softwareentwicklung am besten im eigenen Tempo autodidaktisch lernen lässt: Idealerweise bremst einen nichts außer die eigene Disziplin und das eigene Durchhaltevermögen. Hier ist wichtig, sich selbst die richtigen Anreize zu setzen, etwa thematisch durch geeignete (Neben-)projekte, siehe Abschnitt (B).
(E) Methodik
Als IT-Entwickler:in zu arbeiten bedeutet, einen eigenen Umgang mit den Herausforderungen des IT-Alltags zu entwickeln. Es ist ein Trugschluss, dass man diese Herausforderungen (komplett) an eine KI auslagern kann. Wer aus Faulheit wichtige Fähigkeiten auslagert, entwickelt sich nicht weiter. Ein technisches Beispiel sind etwa Fehlermeldungen (zB. Stack traces, Logzeilen, etc), man muss lernen sie zu verstehen und darauffolgend ein Set von Lösungsstrategien zu entwickeln. Je nach Ökosystem kann das der Umgang mit einem Debugger sein. Wer das Debugging an die KI auslagert, degradiert sich selber zum "Operator" des Systems.
Zu Methoden gehören nicht nur die Selbstorganisation, sondern auch die Arbeit in Gruppen von Menschen (Teams) sowie etwa die Projektorganisation. Als Solo-Selbstständige:r Freelancer:in ist man Universalist und muss die peripheren Bereiche, die im Kern gar nichts mehr mit Softwareentwicklung zu tun haben, auch abdecken. In Teams hingegen kann man Kompetenzen aufteilen, wenn die Atmosphäre dazu gegeben ist. Ich kenne zB. gute Senior Developers, die leider miserable technische Writers abgeben. Wenn sie nun die Code-Dokumentation KI-generieren lassen, dann fehlt ihnen die Fähigkeit die Qualität der KI-Ausgabe zu bewerten. Statt die eigenen Schwächen im Team zu offenbaren, werden KI-Lösungen zum Kaschieren verwendet. Das schadet am Ende allen.
Zum Weiterlesen
Das Thema ist sehr erschöpfend. Im folgenden sind ein paar leicht verdauliche Weblinks angegeben um sich weiter mit der praktischen Tätigkeit als Softwareentwickler:in zu befassen:
- Eric Raymond, 2007: How To Become A Hacker
- MIT Press Reader, 2019: Eight Habits of Expert Sofware Designers: An Illustrated Guide
- 2019: HackerNews on 7 Absolute Truths I Unlearned as Junior Developer sowie 2018: Ask HN: What is your best advice for a junior software developer?
Meet The Expert
Dr. Sven Köppel ist unser Experte für Quantencomputer. Er ist Trainer und internationaler Speaker mit Schwerpunkt Deep Tech. Der promovierte Astrophysiker ist einer der vielen erfahrener IT-Spezialisten der DenktMit eG, die Sie bei Ihrem IT-Vorhaben unterstützen.
