本站提供正體中文版。切換到正體中文本站提供简体中文版。切换到简体中文This site is available in English.View in Englishこのサイトには日本語版があります。日本語で表示이 사이트는 한국어로도 제공됩니다.한국어로 보기Este sitio web también está disponible en español.Ver en españolQuesto sito è disponibile anche in italiano.Visualizza in italianoCe site est également disponible en français.Afficher en françaisEste site também está disponível em português.Ver em portuguêsDeze website is ook beschikbaar in het Nederlands.In het Nederlands bekijkenЭтот сайт также доступен на русском языке.Смотреть на русскомयह वेबसाइट हिन्दी में भी उपलब्ध है।हिन्दी में देखेंهذا الموقع متاح أيضًا باللغة العربية.عرض بالعربيةSitus ini juga tersedia dalam bahasa Indonesia.Lihat dalam bahasa IndonesiaBu site Türkçe olarak da mevcut.Türkçe görüntüleTa strona jest dostępna także po polsku.Wyświetl po polskuTrang web này cũng có phiên bản tiếng Việt.Xem bằng tiếng Việtاین وب‌سایت به فارسی هم در دسترس است.مشاهده به فارسی

Von „Läuft doch, reicht“ zu „Trau dich, es zu ändern“: das Einmonats-Coding-Tagebuch eines Neulings

KI2026.04

Vorweg eine Klarstellung: Ich bin kein Softwareentwickler, und die Programmierdinge, von denen ich hier rede, sind eigentlich alle das sogenannte Vibe Coding – die Sorte, bei der man einfach dem Gefühl folgt.

Ein Laptop auf dem Schreibtisch zeigt Code, daneben kleben Haftnotizen, ein kleines Whiteboard mit dem skizzierten Änderungsablauf, ein Pomodoro-Timer, ein handschriftliches Coding-Tagebuch und eine Katzen-Tasse

Um meine Arbeit ein wenig runder laufen zu lassen, entwickle ich in letzter Zeit fortlaufend eigene kleine Werkzeuge. In den letzten beiden Tagen habe ich drei Dinge getan: angefangen, mit Git zu sichern, ein paar Bugs in der Programmlogik behoben und ein neues KI-Modell angebunden.

Das Schwerste ist nicht die Syntax, sondern „das Gewünschte in Code zu verwandeln“

Nach einem Monat ist meine größte Erkenntnis: Das Schwerste am Programmieren ist eigentlich nicht die Syntax, sondern „das, was man eigentlich will“ in „konkreten Code“ zu übersetzen.

Zum Beispiel: „einen Bug beheben“ ist schnell gesagt, doch bevor du wirklich Hand anlegst, musst du dir einen ganzen Haufen Fragen stellen:

  • Soll ich zuerst speichern?
  • Soll ich einen neuen Branch aufmachen?
  • Wann teste ich? Und wie teste ich?
  • Wann gilt es nach dem Ändern als „fertig“?
  • Soll ich gleich noch eine Versionsnummer setzen?

Das alles sind eigentlich keine Programmierfragen, sondern Fragen der „Arbeitsgewohnheiten“. In der Branche mag dieser Ablauf ganz alltäglich sein, doch für einen Programmieranfänger ist er schlicht ein Albtraum.

Ein paar Kleinigkeiten, die ich gelernt habe

In diesem einen Monat habe ich ein paar Kleinigkeiten gelernt, die ich mit Anfängern wie mir teile:

  1. Spann erst den Schutzschild auf, dann leg mit dem Herumbasteln los. Mit Git zur Versionskontrolle bist du, selbst wenn du alles zerschießt, in dreißig Sekunden wieder in der Vergangenheit – so beruhigend wie ein Speicherpunkt im Spiel.
  2. Mach immer nur eine Sache auf einmal. Bloß nicht „nebenbei noch eine Zeile mitändern“ – das ist genau die Sorte Sache, bei der dein künftiges Ich mit dem Kopf gegen die Wand will.
  3. Langsam ist normal. Einen ganzen Nachmittag für ein einziges kleines Feature? Ja, das ist der Alltag. Diese Schnell-gut-werden-Tutorials belügen dich meistens.
  4. Schreib Notizen für dein künftiges Ich. Sonst denkst du beim nächsten Mal, wenn du zurückkommst, jemand anderes hätte das Programm geschrieben. (Na gut – dieses Programm hat wirklich eine KI geschrieben.)

Von „Läuft doch, reicht“ zu „Trau dich, es zu ändern“: Was dazwischenliegt, sind wohl genau diese unscheinbar wirkenden Arbeitsgewohnheiten, die man dennoch eine nach der anderen nachtragen muss.