Die Welt war in Ordnung

“Wer schaut am meisten Fernsehen? – Hildegard von Bingen”

Ich bin kein Cineast. Also keiner von denen, die bei “Lichtsetzung” nicken, als hätten sie sich gerade Eintrittskarten für die Filmfestspiele in Cannes bestellt.

Anfang der 2000er hab ich mir hin und wieder mal eine DVD gekauft, so wie andere Leute doppelseitiges Klebeband: braucht man nicht dauernd, aber wenn man es hat, ist gut. In der Jugend und im Studium ging’s auch mal ins Kino. Ab und zu. Wenn Geld da war, Zeit war und keiner vorher sagte: “Lass doch lieber auf der Wohnheimwiese grillen.”

Im ersten Job nach dem Studium war dann wenig mit Filmegucken. Man kam nach Hause, der Kopf war durch. Ich gestehe: Manchmal lief kino.to. Nicht schön, aber ehrlich. Einen Fernseher hatte ich da gar nicht mehr. Den hatte ich zu Studienbeginn in den Schrank gestellt, dann vergessen und am Ende verschenkt. Konsequent ostwestfälisch: erst ein paar Jahre nicht benutzen, dann weg damit. Geguckt wurde also ausschließlich am PC. Großes Kino, nur mit Bürostuhl.

Seit wir Kinder hatten, hatten wir Amazon Prime. Nicht wegen Lifestyle, sondern wegen Windeln. Und wenn Prime schon da war, guckte man eben auch Filme. Erst Amazon, dann lud uns der Schwager zu Netflix ein. Plötzlich Full-HD, riesige Auswahl, alles sofort. Meine kleine DVD-Sammlung habe ich dann verschenkt. Wir hatten nicht mal mehr ein Abspielgerät dafür. Außerdem war das nur PAL-Auflösung. Das klang schon wie ein Fax an den Steuerberater schicken. Drückste dich sehr lange drumherum.

Wir guckten jahrelang auf dem Tablet. Zwei Erwachsene, Hollywoodfilm für 180 Millionen Dollar Budget auf einem Bildschirm groß wie ein Frühstücksbrettchen. Ging trotzdem.

Erst 2020, mit Corona, kam der große 4K-Fernseher ins Wohnzimmer. Da war die Welt noch in Ordnung: Windeln kamen per Prime, Filme per Stream, und niemand musste eine DVD aus der falschen Hülle fummeln.

Jau. Fortschritt kann manchmal ganz praktisch sein.

Bananensalat?

“Give a monkey a banana and he’s happy. Give a monkey two bananas, then take one away, and you’ve got a really pissed-off monkey.”

So ungefähr war das mit Streaming. Erst hatte man Netflix und Prime, und man dachte: Guck an, Zukunft. Keine DVDs, keine Regale, kein Gefummel. Alles da. Filme, Serien, Full-HD, Sofa. Der Affe hatte zwei Bananen und war zufrieden.

Dann kamen sie aus den Löchern gekrochen: HBO, Disney+, Paramount, Apple TV+, Sky, Joyn und der ganze Rest vom Medien-Schützenfest. Jeder brachte sein eigenes kleines Zelt mit, stellte sich auf die Wiese und sagte: “Bei uns gibt’s aber die gute Serie.”

Und plötzlich war Netflix nicht mehr diese große Videothek ohne Kaugummiflecken im Teppich, sondern eher so ein Restpostenmarkt wie Thomas Philipps. Prime auch. Also nutzte man Webseiten wie werstreamt.es. Früher fragte man: “Wollen wir was gucken?” Jetzt fragte man: “Wo läuft das?” Das ist kein Fortschritt.

Dann kam Severance. Überall beworben, alle redeten davon, sah gut aus, wollte ich sehen. Natürlich exklusiv auf Apple TV+. Deswegen habe ich mir zwei Monate Apple TV+ gegönnt. Da fing es schon an zu bröckeln.

Der Affe hatte nicht mehr zwei Bananen. Er hatte Bananensalat.

Bananen-Smoothie?

“Big Bang Theory” hatte mir gut gefallen, deswegen fing ich auf Prime Video “Young Sheldon” an. Nette Serie, harmlos, tut keinem weh. So Fernsehen für abends, wenn der Kopf schon im Schlafanzug ist. Man klickt Folge um Folge durch und denkt: Läuft. Bis Prime irgendwann sagt: Läuft nicht mehr. Ab hier bitte zahlen.

Da sitzt man dann auf dem Sofa wie ein Mann, dem beim Grillen die Kohle ausgeht, während das Fleisch schon draufliegt. Die ersten Staffeln waren noch im Grundangebot, alles fein, alles Prime, alles inklusive. Und plötzlich steht da: kaufen oder leihen. Pest oder Cholera.

Entweder man hört mittendrin auf, obwohl man schon emotional investiert ist. Oder man ballert pro Staffel einen schmalen Zehner raus, nur damit man weitergucken darf, was man eben noch für “mit drin” hielt. Ekelhaft. Das ist kein Streaming mehr. Das ist Anfüttern.

Erst kriegt der Affe die Banane in die Hand gedrückt, dann zieht Amazon sie wieder weg und sagt: “Kannste haben. Kostet aber extra.”

Da wird selbst der friedlichste Couchprimat kurz unangenehm.

Bananenmilch?

Der Ostwestfale überstürzt nichts, aber irgendwann ist auch für einen Ostwestfalen der Rubikon überschritten. Dann wird er zum Golem aus Lemgo. Der Reihe nach: Ich kam in diese Phase, in der man denkt: Komm, alte Kinoklassiker schauen. Bildungslücke schließen. Mal ohne Werbung und im Originalton.

Früher hat man ja oft von Filmen die besten Stellen verpasst, weil man während der Werbepause nicht schnell genug wieder zurückgezappt hatte, das Band in der VHS-Kasette am Ende war oder man panisch umgeschaltet hatte, weil man nicht wollte, dass die Eltern mitbekommen, dass man mit 12 schon FSK 16-Filme genießt.

Also Terminator 1 von 1984.

Klassiker. Schwarzenegger. Lederjacke. Synthesizer. Zukunftsangst mit Kiefer.

Ich dachte: Der muss ja irgendwo sein. War er auch. Kostenlos bei MagentaTV.

Natürlich “kostenlos” in dem Sinne, wie ein Bier auf dem Schützenfest kostenlos ist, wenn man vorher den ganzen Verein gekauft hat. Man brauchte nämlich ein Abo. Auf allen anderen Plattformen sollte man nochmal zehn Euro hinlegen. Zehn Euro. Für einen Film, der vor dem Mauerfall entstanden ist.

Dann wollte ich eben Terminator 2 gucken. Noch größerer Klassiker. Einer dieser Filme, die früher gefühlt jeden zweiten Sonntagabend irgendwo liefen, meistens mittendrin mit der Werbung von Beck’s Bier, gesungen von Hans Hartz.

Aber nix. Auf vielen Plattformen gar nicht verfügbar. Nicht mal gegen Geld. Da steht man dann digital mit offenem Portemonnaie da und keiner will es haben.

Das ist Streaming 2024: Der Affe hatte jetzt Bananenmilch. Kann Spuren von Banane enthalten. Früher war nicht alles besser. Aber wenigstens gehörte einem die Banane.

Coping-Strategie

Vor ein paar Wochen habe ich dann das gemacht, was man früher ganz normal nannte und heute schon fast wie Widerstand wirkt: Ich habe mir Filme gekauft.

Auf Blu-ray.

Gebraucht bei medimops. Terminator 1 und Terminator 2. Nicht gestreamt, nicht geliehen, nicht “nur noch 48 Stunden verfügbar”, sondern gekauft. In Hülle. Mit Scheibe. Wie ein alter Mann mit Prinzipien und leichtem Rücken.

Die Entscheidung fiel auch deshalb leicht, weil ich überraschenderweise schon einen Blu-ray-Player besaß, ohne es richtig zu wissen. Ich hatte nämlich mal eine alte PlayStation 3 aus dem Elektroschrott gezogen. So ein Gerät, das andere wegwerfen, weil es nicht mehr nach Zukunft aussieht, sondern nach Jugendzimmer 2009. Lief aber einwandfrei.

Also Terminator 1 rein. Director’s Cut. Zum ersten Mal auf Englisch.

Und ich saß da wie früher, nur mit besserem Bild und graueren Haaren.

Ich hatte wirklich nicht damit gerechnet, dass Blu-ray, also “nur” Full HD, so gut aussehen kann. Nach Jahren Streaming-Matsch, Kompressionsgeflimmer und dunklen Szenen, in denen man raten muss, ob das jetzt ein Schauspieler oder ein nasser Teppich ist, war das plötzlich: Ein Film. Ein richtiger Film. Mit Körnung, Tiefe, Schwarz, das auch schwarz war, und nicht dieses “Netflix-Dunkelgrau mit WLAN-Problemen”. Ich war hin und weg. Da lag sie wieder, die Banane. Nicht als Bananenmilch. Nicht als Abo-Smoothie. Eine richtige Banane. Zum Anfassen.

Danach wollte ich mit den Kindern Star Wars anfangen. Eigentlich wäre das der Moment gewesen, Disney+ für ein, zwei Monate zu abonnieren. Schön brav zahlen, gucken, kündigen, doch vergessen zu kündigen, weiterzahlen. So macht man das heute ja, wenn man als erwachsener Mensch zu wenig Ärger mit der Fitnessclub-Mitgliedschaft hat.

Aber nee. Wir haben wieder Blu-ray genommen.

Episode I. Ja, ich weiß. Viele Fans bekommen davon Ausschlag. Und Jar Jar Binks ist natürlich ungefähr so angenehm wie ein Animateur im All-inclusive-Resort, der morgens um zehn schon Polonaise machen will. Aber die Bildqualität, die Produktionsqualität, das ganze Ding sah dermaßen gut aus, dass sogar meine Tochter beeindruckt war.

Und die ist nicht leicht zu beeindrucken. Die guckt sonst Dinge an, als wäre sie hauptberuflich beim TÜV Nord
beschäftigt. Dann sagte sie: “Wie bitte kann so ein alter Film so dermaßen geil aussehen?”

Da wusste ich: Streaming hat die Kinder weichgekocht. Die kannten Full-HD nur als Versprechen aus der Werbung. Aber eine Blu-ray, ordentlich abgespielt, ohne Datenrate auf Diät und ohne Algorithmus mit Schluckauf, das war für die plötzlich wie Magie.

Tja. Manchmal findet man die Zukunft im Elektroschrott.

Und manchmal liegt der bessere Streamingdienst einfach gebraucht im Briefkasten.

… and now for something completely different

Und dann, komplett anderes Fass: Musik-Streaming.

Da war die Welt erstaunlich lange in Ordnung. Spotify hatte tatsächlich geschafft, was beim Film-Streaming alle nur versprochen hatten: ein Laden für alles. One-Stop-Shop, wie man sagt, wenn man in Meetings zu lange neben Leuten gesessen hat, die Sneaker im Büro tragen.

Du wolltest ein Album hören? War da.

Du wolltest irgendeinen obskuren Song von früher, den du zuletzt auf einer selbstgebrannten CD mit Edding-Beschriftung im Handschuhfach hattest? War auch da.

Playlisten, Empfehlungen, alles fein. Der Affe hatte seine Banane. Vielleicht sogar einen kleinen Obstkorb.

Dann kam bei uns die Alexa-Zeit.

Jedes Kind hatte so ein Ding im Zimmer stehen. Früher hatten Kinder Musikkassetten kaufen müssen. Oder sie bekamen sie zu wohldefinierten Zeitpunkten wie Geburtstagen oder Weihnachten geschenkt. Viele Trends wurden dadurch zeitlich schon übersprungen. Heute haben sie kleine Abhörkugeln, denen sie morgens um sieben “Alexa, spiele Komet von Apache 207” zurufen können.

Und weil das alles mit Amazon irgendwie besser passte, sind wir von Spotify zu Amazon Music gewechselt. Ich musste einmalig meine Playlisten migrieren, aber gut: Das Angebot bei Prime Music war gleichwertig. Wirklich. Musik war da, Kinder waren zufrieden, Alexa gehorchte meistens, und ich konnte wieder so tun, als hätte ich mein Leben technisch im Griff.

Aber.

Und dieses Aber stand schon in der Tür wie ein Handwerker aus Bünde, der sagt: “Dat wird größer als gedacht.”

Der Smash-Moment

Ich gebe es zu: Ich bin ein alter Sack.

Nicht so einer, der im Supermarkt an der Kasse mit Kleingeld bezahlt, während hinter ihm acht Leute innerlich § 223 StGB – Einfache Körperverletzung neu interpretieren. Eher so einer, der bei Musik plötzlich Wörter benutzt wie “Dynamik”, “Mastering” und “Intersample Over”. Begriffe, bei denen normale Menschen höflich nicken und sich innerlich fragen, ob man noch fahrtüchtig ist. Und ja: Ich liebe Smash von The Offspring aus dem Jahr 1994.

Dieses Album habe ich gehört, bis die CD wahrscheinlich selbst dachte: “Junge, geh doch mal raus, es ist Sommer.” Ich habe das Ding vorwärts gehört, rückwärts, im Zimmer, im Auto, im Bus. Ich habe es auf Kassette kopiert, damit ich es auch unterwegs hören konnte. So war das damals. Man hatte nicht alles sofort in der Cloud, man hatte Bandsalat und einen Bleistift.

Dann hörte ich irgendwann Smash (2008 Remaster).

Und ich sag mal so: Da hat keiner liebevoll Staub vom alten Lieblingsalbum gepustet. Da ist jemand mit dem Laubbläser durchs Jugendzimmer marschiert. Alles lauter, alles platter, alles vorne. Als hätte einer gesagt: “Kann das noch mehr nach Presslufthammer im Schuhkarton klingen?”

2008 war sowieso das Jahr, in dem der Loudness War endgültig eskalierte. Death Magnetic von Metallica war da so eine Art akustischer Auffahrunfall. Ich hatte das Album damals einem Kollegen abgekauft, weil der meinte, es sei unhörbar. Ich dachte noch: Stell dich doch nicht so an.

In meinem alten Ford Fiesta war das auch erstmal egal. Der Wagen hatte eine Akustik wie eine Blechdose mit Kies drin. Da klapperte ohnehin alles: Armaturenbrett, Türverkleidung, wahrscheinlich auch die eigene Lebensplanung. Da fiel ein kaputtgemastertes Metallica-Album nicht weiter auf.

Aber zu Hause, in einer ruhigen Minute, auf der Stereoanlage?

Junge.

Das war nicht Musik. Das war ein Angriff. Keine Luft, keine Tiefe, keine Ruhe. Nur Dauerfeuer. Als würde Lars Ulrich mit einem Vorschlaghammer versuchen, eine Einbauküche aus Herford zu zerlegen.

Später gab es dann diese anders gemasterte Guitar Hero-Version, die deutlich angenehmer zu hören war. Natürlich verbreitete die sich. Nicht, weil alle plötzlich Audiophile mit Messmikrofon waren. Sondern, weil Menschen Ohren haben. Und Ohren sind keine Wertstofftonne.

Aber Streaming versprach doch digitalen Fortschritt, lad doch einfach alles hoch und lass die Leute selbst entscheiden. Nein eine Fehlentscheidung von 2008 wurde in den digitalen Stein gemeißelt. Alternativlos.

Wollen sie das Deluxe- oder das Bonusalbum?

Eine weitere Unsitte beim Übergang von physischen Medien in die Wolke war das, was Cineasten gern Retcon nennen: nachträgliches Herumfummeln an etablierten Fakten.

Also: Früher war ein Album ein Album.

Da waren zwölf Lieder drauf. Oder dreizehn. Manchmal ein Hidden Track, der nach acht Minuten Stille kam, damit man sich nachts um halb eins im Kinderzimmer erschreckte und dachte, jetzt spricht der Drucker mit einem. Aber grundsätzlich war klar: Das ist die Platte. So wurde sie veröffentlicht. So stand sie im Regal. So blieb sie.

Beim Mastering wurde wenigstens “nur” an den audiophilen Eigenschaften rumgeklempnert. Schlimm genug, klar. Aber der Inhalt blieb derselbe. Wie wenn einer bei deinem alten Ford Fiesta die Sitze neu bezieht, aber das Lenkrad und das Handschuhfach sind immer noch am richtigen Platz.

Streaming hat dann gemerkt: Moment mal, wir können ja jederzeit dran.

Und plötzlich wurden Alben nachträglich verändert. Da tauchten Bonus-Tracks auf, Deluxe-Versionen, Anniversary Editions, Remixes, Livefassungen, Akustikversionen und irgendwelche “Sped-up”-Dinger, bei denen man dachte, der Sänger müsse dringend mal den Blutdruck checken lassen.

Aus einem Album wurde ein bewegliches Ziel. Was hatte der Affe jetzt noch: Kaugummi mit Bananengeschmack oder so?

Friedliche Koexistenz

Bevor es Streaming gab, hatte ich irgendwann angefangen, meine CDs auf den Computer zu überspielen.

Scheibe für Scheibe. Ganz genüsslich. So wie andere Leute Marmelade einkochen oder im Keller Schrauben sortieren. CD rein, warten, importieren, nächste CD. Das hatte fast was Meditatives. Man saß da wie ein kleiner Archivar seines eigenen Musikgeschmacks und dachte: Jetzt mache ich mich unabhängig.

Am Ende hatte ich dann einen Haufen Dateien auf der Festplatte. Und sonst erstmal wenig gewonnen. Klar, man konnte sich schnell mal eine Best-of-MP3-CD fürs Auto brennen. Aber richtig bequem war das alles nicht.

Die Musik lag jetzt nicht mehr im Regal, sondern in Ordnern. Man hatte also die Unordnung nur digitalisiert. Aus “Wo ist die CD?” wurde “Warum heißt der Ordner Unknown Artist?” Fortschritt, wie ihn nur Computerleute schönfinden.

Die Lösung hieß dann: Apple Music Match.

Oder wie das damals für mich klang: Du lädst deinen ganzen Kram hoch, Apple guckt einmal streng drüber und sagt dann: “Jau, kennen wir. Kannste jetzt überall hören.”

Das war schon beeindruckend. Plötzlich war meine alte Sammlung nicht mehr an den Rechner gekettet wie ein Drucker im Finanzamt. Sie war in der Wolke. Auf dem Handy. Im Auto. Auf Geräten, von denen ich vorher nicht wusste, dass sie überhaupt Musik abspielen können.

Da dachte ich kurz: Jetzt haben wir’s! Der Affe hatte nicht nur seine Banane wieder. Der Affe hatte seine eigene Obstabteilung!

The post Streaming Müdigkeit – Essay appeared first on Creatronix.

Als Chester Bennington 2017 gestorben ist, dachte wohl kaum jemand ernsthaft an ein Comeback. Zu prägend war seine Stimme für den Sound der Band. Als Sänger war er das Aushängeschild. Wenn man ihn hörte, wusste man sofort: Das ist Linkin Park.

Dann kam 2024 das große Comeback – mit der neuen Sängerin Emily Armstrong. Wie konnte das funktionieren? Und was hat das mit einer M-Shaped Personality zu tun?

Gehen wir es der Reihe nach an:

Die Stimme von Chester Bennington war ein klassisches „I“: eine klar erkennbare, außergewöhnlich starke Fähigkeit. Sicherlich basierte sie auf Talent und besonderen körperlichen Voraussetzungen, wurde aber über Jahre hinweg durch Übung und Erfahrung immer weiter verfeinert. Seine Stimme hat den Sound der Band massiv geprägt.

Aber warum funktioniert Linkin Park auch mit einer neuen Stimme noch? Weil die Stimme eben nicht das einzige Element ist, das den Sound der Band ausmacht.

Hinter den Kulissen ist Mike Shinoda aus meiner Sicht der eigentliche Strippenzieher – und ein gutes Beispiel für eine M-Shaped Personality.

Warum? Schaut man sich zum Beispiel den Wikipedia-Eintrag an, hat fast jedes Bandmitglied eine klar definierte Rolle. Mike Shinoda dagegen vereint gleich mehrere: Rap, Keyboard, Gitarre, Sampler, Piano, Gesang. Dazu kommt laut Discogs seine Arbeit als Producer und Co-Producer.

Er beherrscht extrem viele Dinge. Viele davon sehr gut – aber vielleicht keines davon auf absolutem Weltklasse-Niveau für sich allein betrachtet.

Ist er der beste Rapper der Welt? Nein.
Der beste Keyboarder? Auch nicht.
Der beste Songwriter? Wahrscheinlich nicht.
Der beste Produzent? Vermutlich ebenfalls nicht.

Aber er ist in all diesen Bereichen gut genug, und genau diese Kombination macht den Unterschied. Zusammengenommen bilden diese Fähigkeiten das kreative Rückgrat der Band. Wenn man einen Linkin-Park-Song hört, erkennt man oft schon sehr früh, dass es ein Song dieser Band ist – noch bevor der Hauptgesang überhaupt einsetzt.

Will ich damit die Beiträge der anderen Bandmitglieder kleinreden? Natürlich nicht. Für das Comeback war auch die ausdrucksstarke Stimme von Emily Armstrong entscheidend. Und selbstverständlich haben auch die anderen Mitglieder den Sound der Band geprägt und prägen ihn bis heute.

Aber irgendjemand musste sich auf die Suche nach einer neuen Sängerin machen. Irgendjemand musste daran glauben, dass die Geschichte der Band noch nicht zu Ende ist. Irgendjemand musste vermutlich noch ein ganzes Backlog an Songideen im Kopf oder in der Schublade haben.

Und wie bekomme ich jetzt die Kurve zurück zu Technologie und Robotics?

Ganz einfach: In einer Zeit, in der moderne AI-Tools immer stärker die Rolle von Spezialisten übernehmen, braucht es zur Koordination weiterhin diese M-Shaped Personalities – so jedenfalls die landläufige Meinung. Irgendjemand muss diese Spezialisten anleiten, sinnvoll einsetzen und überhaupt erst auf die Idee kommen, welches Ziel es sich zu verfolge lohnt.

Dieser Jemand muss nicht in allem der absolute Top-Experte sein. Es reicht, wenn er ein System aufbauen kann und an den entscheidenden Stellen seine eigenen Fähigkeiten einbringt, um daraus ein starkes Zusammenspiel aus Menschen und Agenten zu formen

Lassen wir dazu einmal Jürgen Appelo zu Wort kommen:

But as AI takes on more complex, specialized tasks, the ability to synthesize information from different fields becomes crucial. The goal is to become M-shaped, combining mastery across multiple fields with strong business and leadership skills.

Auf Deutsch:

Aber wenn AI komplexere, spezialisierte Aufgaben übernimmt, wird die Fähigkeit, Informationen aus verschiedenen Bereichen zu synthetisieren, entscheidend. Das Ziel ist es, M-förmig zu werden: also Kompetenzen in mehreren Disziplinen mit starken Business- und Leadership-Skills zu verbinden.

Dröseln wir diese Modelle noch etwas weiter auf:

I-Shaped Personality

Das ist das, was man früher oft etwas abfällig als „Fachidiot“ bezeichnet hat. Wohlwollender gesagt: jemand mit extrem tiefer Expertise in einem Gebiet, aufgebaut über viele Jahre oder Jahrzehnte. Diese Tiefe geht allerdings manchmal
zulasten von Breite, Kontextverständnis oder sozialen Fähigkeiten. Archetyp Magnus Carlsen

T-Shaped Personality

Hier kombiniert jemand eine sehr starke Kernkompetenz mit einem breiten Überblick über angrenzende Disziplinen. Also: ein tiefes Spezialgebiet plus ausreichend Breite, um mit anderen Feldern gut zusammenzuarbeiten. Archetyp Casey Neistat

Pi-Shaped Personality

Ein Pi π hat zwei „Beine“ – also tiefes Wissen in zwei unterschiedlichen Bereichen. Das erhöht den eigenen Wert oft erheblich, weil die Kombination zweier echter Kompetenzen deutlich seltener ist als reine Einzeldisziplinen. Archetyp Richard Feynman (Pädagogik und Physik)

M-Shaped Personality

Ein M hat mehrere Säulen. Es steht für tiefes Wissen in mindestens drei relevanten Bereichen – kombiniert mit der Fähigkeit, diese sinnvoll zusammenzubringen und in Wirkung zu übersetzen.

Und genau deshalb ist dieses Modell heute so interessant: Nicht, weil Spezialisten unwichtig werden – im Gegenteil. Sondern weil in einer Welt voller hochspezialisierter Menschen und immer leistungsfähigerer AI-Tools diejenigen besonders wertvoll werden, die mehrere Disziplinen verbinden, Teams orchestrieren und aus vielen Einzelteilen ein funktionierendes Ganzes bauen können.

Vielleicht ist genau das der eigentliche Kern der Geschichte von Linkin Park: Nicht nur eine außergewöhnliche Stimme, sondern ein System aus mehreren kreativen Kräften – zusammengehalten von jemandem, der genug von vielen Disziplinen versteht, um daraus etwas Eigenes, Wiedererkennbares und Neues entstehen zu lassen.

The post M-shaped Personality appeared first on Creatronix.

Jeder kennt und nutzt Git. Es gibt bis auf Ausnahmen (ich schaue dich an, Perforce) keine ernstzunehmenden Alternativen mehr.

Ich lasse Azubis ab der ersten Woche schon mit Git arbeiten, allerdings zunächst im Kontext einer IDE,
damit sie ihren Code entspannt versionieren können.

Im zweiten Lehrjahr gibt es dann den Blick hinter die Kulissen, also auf die Kommandozeile.

Inhalt

• Basics: Installation, Konfiguration, Repository erstellen, Status & Log, Commits, .gitignore, Remote, Fetch & Pull
• Intermediate: Branching, Merging, Merge-Konflikte, Stash, Diff, Tags
• Advanced: Rebase, Squashen von Commits, Cherry-Pick, Reflog, Bisect

Voraussetzungen

• Ein Terminal / eine Shell (bash, zsh, PowerShell, …)
• Grundlegende Erfahrung mit der Kommandozeile (cd, mkdir, ls/dir)
• Optional: ein GitHub- oder GitLab-Account für Remote-Repositories

Basics

Installation

Damit etwas unter Versionskontrolle gestellt werden kann, muss Git zuerst installiert sein.

Windows:

Download von https://git-scm.com/download/win und Installer ausführen

Linux (Debian/Ubuntu):

sudo apt install git

macOS:

brew install git

Wir können nun testen, ob die Installation erfolgreich war:

git --version

Konfiguration

Bevor wir loslegen, teilen wir Git unseren Namen und unsere E-Mail-Adresse mit.
Diese Infos werden in jedem Commit gespeichert.

git config --global user.name "Dein Name"
git config --global user.email "deine@email.de"

Optional – Standardbranch auf main setzen:

git config --global init.defaultBranch main

Repository erstellen (init)

mkdir my_workspace
cd my_workspace
git init

Damit haben wir ein leeres Git-Repository. Jetzt legen wir die ersten Dateien an:

touch .gitignore
touch README.md
touch app.py

Status & Log

Zwei Befehle, die man ständig braucht sind:

git status # Zeigt den aktuellen Zustand des Repositories
git log # Zeigt die Commit-Historie
git log --oneline # Kompakte Einzeiler-Ansicht

Staging & Commit

Dateien müssen zunächst in die Staging Area und können dann committet werden:

git add . # Alle Änderungen stagen
git add README.md # Einzelne Datei stagen
git commit -m "initial commit" # Commit mit Nachricht

Tipp: Gute Commit-Messages beschreiben was und warum, nicht wie.

.gitignore

Die Datei .gitignore definiert, welche Dateien Git ignorieren soll (Build-Artefakte, IDE-Konfiguration, Secrets, …):

# Beispiel .gitignore
pycache/
*.pyc
.idea/
.env
build/

Remote hinzufügen und pushen

Ein Remote-Repository (z. B. auf GitHub) wird so verknüpft:

git remote add origin https://github.com/user/repo.git
git push -u origin main

-u setzt das Upstream-Tracking, sodass git push danach ohne weitere Argumente funktioniert.

Änderungen vom Remote holen

git fetch # Holt Änderungen, merged aber NICHT
git pull # Holt Änderungen UND merged in den aktuellen Branch

Faustregel: fetch ist sicher und unverbindlich, pull verändert den lokalen Branch.

Intermediate

Remote-Repo clonen

Statt ein Repository von Grund auf neu zu erstellen, kannst du ein bestehendes Remote-Repository mit git clone auf den eigenen Rechner kopieren.
Dabei passiert automatisch einiges:

1. Ein neuer Ordner mit dem Repository-Namen wird erstellt
2. Die gesamte Historie (alle Commits, Branches, Tags) wird heruntergeladen
3. Ein Remote namens origin wird angelegt, der auf die Quell-URL zeigt
4. Der Standard-Branch (z. B. main) wird ausgecheckt

Grundsyntax:

git clone https://github.com/user/repo.git

Einen bestimmten Branch clonen:

git clone -b develop https://github.com/user/repo.git

Damit wird direkt der Branch develop ausgecheckt, nützlich, wenn du nicht auf main arbeiten möchtest.

Tipp: Nach dem Clonen kannst du dir den eingerichteten Remote anzeigen lassen:

cd repo
git remote -v

#origin https://github.com/user/repo.git (fetch)
#origin https://github.com/user/repo.git (push)

Branching

Branches sind einer der größten Vorteile von Git. Sie erlauben paralleles Arbeiten an Features, Bugfixes usw.

git branch # Alle lokalen Branches anzeigen
git branch feature/login # Neuen Branch erstellen
git checkout feature/login # In den Branch wechseln
git checkout -b feature/login # Erstellen + Wechseln in einem Schritt

Merging

Wenn ein Feature fertig ist, wird der Branch zurück in main gemerged:

git checkout main
git merge feature/login

Merge-Konflikte

Wenn zwei Branches dieselbe Stelle in einer Datei geändert haben, entsteht ein Merge-Konflikt.
Git markiert die betroffenen Stellen:

<<<<<<< HEAD
Deine Änderung
=======
Änderung aus dem anderen Branch
>>>>>>> feature/login

Lösung: Datei manuell bereinigen, dann:

git add <datei>
git commit

Stash

Unfertige Änderungen kann man zwischenspeichern, ohne zu committen:

git stash # Änderungen wegstashen
git stash list # Alle Stashes anzeigen
git stash pop # Letzten Stash wiederherstellen und entfernen
git stash apply # Letzten Stash wiederherstellen, aber behalten

Diff

Änderungen anzeigen lassen:

git diff # Unstaged-Änderungen
git diff --staged # Staged-Änderungen (vor dem Commit)
git diff main..feature # Unterschied zwischen zwei Branches

Tags

Releases oder Meilensteine markieren:

git tag v1.0.0
git tag -a v1.0.0 -m "Erstes Release"
git push origin v1.0.0

Advanced

Rebase

Rebase schreibt die Commit-Historie um und setzt Commits auf eine neue Basis.
Nützlich, um einen sauberen, linearen Verlauf zu erzeugen:

git checkout feature/login
git rebase main

Achtung: Rebase verändert die Historie. Deshalb nicht auf bereits gepushten, geteilten Branches verwenden.

Squashen von Commits

Mehrere Commits zu einem zusammenfassen (z. B. vor einem Merge Request):

git rebase -i HEAD~3 # Die letzten 3 Commits interaktiv bearbeiten

Im Editor dann pick für die gewünschten Commits durch squash (oder s) ersetzen.

Cherry-Pick

Einen einzelnen Commit aus einem anderen Branch übernehmen:

git cherry-pick <commit-hash>

Reflog

Das Sicherheitsnetz: Zeigt alle Aktionen, auch nach einem versehentlichen Reset:

git reflog
git checkout <hash> # Verlorenen Stand wiederherstellen

Fazit

Git ist ein mächtiges Werkzeug. Die Basics reichen für den Alltag, aber wer Rebase, Squash und Bisect beherrscht,
kann auch in komplexen Projekten souverän arbeiten.

Weiterführende Ressourcen:

• Git Branching interaktiv lernen
• Pro Git Book (kostenlos)
• Git Cheat Sheet
• git help <befehl>: Die eingebaute Hilfe ist besser, als man denkt

The post Das große Git-Tutorial appeared first on Creatronix.

Motivation

Das Erlernen einer Programmiersprache kann herausfordernd sein. Es gibt zwar unzählige Artikel und Tutorials, doch echtes Verständnis entsteht vor allem durch regelmäßige Wiederholung und praktische Anwendung.

Wer Konzepte immer wieder in kleinen Übungen, Katas und realen Problemen einsetzt, entwickelt mit der Zeit eine Art Muscle Memory fürs Programmieren. Genau diese Routine hilft dabei, Syntax, Denkweisen und Lösungsstrategien nachhaltig zu verinnerlichen.

Die Herausforderungen

Die Programmieraufgaben sind sprachunabhängig, sodass du jede moderne Sprache verwenden kannst, die das Schreiben von Konsolenanwendungen unterstützt.

🟢 Level 1 – Grundlagen (Syntax & einfache Logik)

1. Schreibe das berühmte / berüchtigte „Hello World“
2. Schreibe ein Skript, das alle Zahlen von 1 bis 365 in die Konsole ausgibt
3. Schreibe ein Skript, das 10 Zufallszahlen zwischen 1 und 10 ausgibt
4. Schreibe ein Skript, das alle Buchstaben des Alphabets (großgeschrieben) mit ihrer jeweiligen Position ausgibt, z. B. 1: A, 2: B
5. Schreibe deinen ersten Unit-Test für eine Funktion is_even(num), die true zurückgibt, wenn die Zahl gerade ist

🟡 Level 2 – Einfache Funktionen & Kontrolle

1. Schreibe eine Funktion to_upper, die einen String von lower_case nach upper_case umwandelt
2. Die Funktion compare(num1, num2) soll
   1. -1 zurückgeben, wenn num1 kleiner als num2 ist
   2. ansonsten 1 zurückgeben
   3. wenn beide Werte gleich sind, 0 zurückgeben
3. Die Funktion simple_sum(num) soll alle Zahlen von 1 bis num aufsummieren
   1. Beispiel: Bei Eingabe 4 soll das Ergebnis 10 sein
   2. Für Testfälle liegt num zwischen 1 und 1000
4. Die Funktion time_convert(minutes) soll Minuten in Stunden und Minuten umwandeln (z. B. 63 → 1:03)
5. Die Funktion first_reverse(input) soll den String umdrehen

🟠 Level 3 – Strings & Arrays

1. Die Funktion alphabet_soup(input) soll den String alphabetisch sortieren
2. Die Funktion longest_word(sentence) soll das längste Wort zurückgeben
3. Die Funktion letter_changes(input) soll Buchstaben ersetzen und Vokale kapitalisieren

🔵 Level 4 – Mathematische Grundlagen

1. Die Funktion factorial(num) soll die Fakultät berechnen
2. Schreibe eine Funktion, die Fibonacci-Zahlen erzeugt (inkl. Memoization)
3. Schreibe eine Funktion, die die Collatz-Sequenz als Liste zurückgibt
4. Schreibe eine Funktion, die den Mittelwert (Mean) eines Integer-Arrays berechnet
5. Schreibe eine Funktion, die den Median eines Integer-Arrays berechnet

🟣 Level 5 – Klassische Algorithmen

1. Schreibe eine Funktion, die ein Integer-Array mit Bubble Sort sortiert
2. Schreibe eine Funktion, die eine Liste von Primzahlen mithilfe des Siebs des Eratosthenes zurückgibt
3. Schreibe eine Funktion, die den größten gemeinsamen Teiler mithilfe des euklidischen Algorithmus berechnet

🔴 Level 6 – Anspruchsvoll / Interview-Level

1. Schreibe eine Funktion, die römische Zahlen in Dezimalzahlen konvertiert
2. Schreibe eine Funktion, die Dezimalzahlen in römische Zahlen konvertiert
3. Die Funktion kaprekars_constant(num) berechnet die Anzahl der Schritte bis 6174 erreicht wird

🧪 Hinweis

Ab der Funktion simple_sum sollte nach dem TDD-Prinzip gearbeitet werden (Test → Implementierung → Refactoring).

The post Lerne neue Programmiersprachen schneller mit diesen Coding Challenges appeared first on Creatronix.

Disclaimer

Die folgende Unterteilung in Programmierung, Entwicklung und Engineering ist ein Versuch einer Einordnung von Prozessen, Methoden und Tools. Ich habe dieses Modell entwickelt, um unseren Auszubildenden und Praktikanten, die oft keine Vorkenntnisse hatten, Software-Engineering beizubringen.

Daher enthält es einige persönliche Ansichten und möglicherweise keine präzisen Definitionen. Es spiegelt meine fast 20-jährige Erfahrung in der Softwarebranche als Entwickler, Tester, QA-Mitarbeiter und Teamleiter wider.

Programmierung: der Kern

Ein bekannter Spruch lautet:

A programmer is an organism that turns coffee and pizza into code.

Programmieren bedeutet, Anforderungen des Kunden in ausführbare Anweisungen, die ein Computer versteht, zu übersetzen. Das kann eine einzelne Person — ein Programmierer — tun.

Programmiersprachen

Ein Programmierer braucht eine oder mehrere Programmiersprachen um Quellcode zu erstellen. Quellcode oder oft nur Code ist Text in einer Sprache wie C, C++, Java oder Python. Jede Sprache definiert klare Regeln für Syntax und Semantik.

Vom Quelltext zum Programm

1. Quelltext schreiben (Editor oder IDE)
2. Kompilieren (z. B. C/C++)
3. Linken und ausführbare Datei erzeugen

Beispiel in C:

#include <stdio.h>

int main(void) {
    printf("Hello world\n");
    return 0;
}

gcc -Wall -g -c hello.c
gcc -o hello hello.o -lm

Das reicht schon, damit wurde bereits ein Programm erstellt. Für echte Projekte oder Produkte reicht das reine
Programmieren aber noch nicht aus.

Softwareentwicklung: vom Code zum Produkt

Sobald mehrere Personen beteiligt sind oder Kundennutzen im Fokus steht, kommen Prozesse, Rollen und Werkzeuge hinzu.

Requirements Tracking – Anforderungen erfassen und klären

Damit ein Team von Programmierern das Richtige baut, müssen Anforderungen des Kunden klar beschrieben werden. Eine Anforderung, die in Textform niedergeschrieben wurde, nennt man auch Requirement. Für die Formulierung haben sich zwei Formate etabliert:

• User Story: Als Rolle möchte ich Funktion, damit Nutzen.
• Use Case: strukturierte Beschreibung einer Interaktion zwischen Nutzer und System

Anforderungen erhalten IDs, Status und Verweise auf Implementierung und Tests. So bleibt über den gesamten Lebenszyklus nachvollziehbar, was umgesetzt, geändert oder verworfen wurde.

Auch die guten alten Lastenhefte (Was der Kunde will) und Pflichtenhefte (Was wir verstanden haben und auch umsetzen werden) haben oft noch ihre Daseinsberechtigung.

Neue Rollen

Dedizierte Tester entlasten ein Team von Programmierern und erhöhen die Produktqualität, weil sie Programme systematisch aus Nutzer- und Risikoperspektive prüfen.

Typische Aufgaben für Tester sind:

• Testfälle aus den Anforderungen ableiten
• Teststrategie und Testdaten definieren
• Manuelle und automatisierte Tests durchführen
• Fehler sauber dokumentieren und priorisieren
• Regressionsrisiken vor Releases bewerten

Wichtig: Tester “testen nicht nur am Ende”, sondern arbeiten früh mit den Programmierern zusammen. So werden Qualitätsprobleme früher sichtbar und deutlich günstiger behoben.

Dokumentation

Gute Dokumentation entlastet Teams im Alltag und reduziert Wissensinseln.

• Produktdokumentation: Was kann das System aus Nutzersicht?
• Technische Dokumentation: Architektur, Schnittstellen, Betriebswissen
• Entscheidungsdokumentation: Warum wurde etwas so gebaut?

Wichtig ist nicht “möglichst viel Text”, sondern aktuelle, auffindbare und wartbare Dokumentation.

Versionsverwaltung nutzen

Werkzeuge wie Git speichern den kompletten zeitlichen Verlauf einer Codebasis. Sie ermöglichen damit:

• Zusammenarbeit im Team
• Nachvollziehbare Änderungen
• Rückkehr zu früheren Ständen

Hinweis: Git ersetzt kein vollständiges Backup-Konzept.

Builds automatisieren & Abhängigkeiten verwalten

Moderne Anwendungen nutzen viele oft externe Bibliotheken. Package Manager wie cargo, npm oder gradle helfen bei einheitlichen Builds und reproduzierbaren Versionen. Ziel: Alle können jederzeit denselben Build erzeugen.

Zusätzlich braucht es klare Build Tools und ein belastbares Build System:

• standardisierte Build-Kommandos lokal und in CI
• reproduzierbare Artefakte über Umgebungen hinweg
• schnelle, stabile Pipelines mit klarer Fehlerdiagnose

IDE

Während beim reinen Programmieren ein einfacher Texteditor ausreichen kann, verwenden Softwareentwickler in der Praxis meist leistungsfähige IDEs.

Eine IDE bündelt zentrale Entwicklungsaufgaben in einem Werkzeug:

• Code schreiben mit Syntaxprüfung und Autovervollständigung
• Navigation durch große Codebasen (z. B. “Gehe zu Definition”)
• Refactoring mit geringem Fehlerrisiko
• Debugging mit Breakpoints und Variableninspektion
• Direkte Integration von Tests, Linter und Build-Prozessen
• Anbindung an Versionsverwaltung wie Git

Der eigentliche Nutzen liegt in der Produktivität und Qualität: Teams arbeiten schneller, konsistenter und machen weniger vermeidbare Fehler.

Issue Tracking – Arbeit transparent machen

Issues, Bugs und Aufgaben werden in einem Tracking-System verwaltet (z. B. Jira, YouTrack, GitHub Issues). So bleiben Prioritäten, Zuständigkeiten und Fortschritt nachvollziehbar.

Projektorganisation mit Scrum oder Kanban

Damit Teamarbeit planbar und transparent bleibt, wird Arbeit in kleine, priorisierte Einheiten aufgeteilt und sichtbar gemacht.

Bei Scrum erfolgt die Planung meist in festen Iterationen (Sprints), z. B. alle ein bis zwei Wochen:

• Ziele für den Sprint festlegen
• Aufgaben gemeinsam schätzen und zuschneiden
• Fortschritt täglich abstimmen
• Ergebnisse am Sprint-Ende überprüfen und verbessern

Bei Kanban steht der kontinuierliche Fluss im Vordergrund:

• Aufgaben visualisieren (z. B. To-do, In Arbeit, Erledigt)
• Parallelarbeit mit WIP-Limits begrenzen
• Engpässe früh erkennen und aktiv beseitigen

Beide Ansätze helfen, Lieferfähigkeit und Qualität im Alltag stabil zu halten.

Qualität absichern

Qualität entsteht nicht zufällig, sondern durch disziplinierte Routinen:

• Tests (Unit, Integration, End-to-End)
• TDD (Test-Driven Development)
• Debugging
• Logging
• Linting und statische Codeanalyse
• Code Reviews

TDD sinnvoll einsetzen

Bei TDD schreibst du zuerst einen fehlschlagenden Test, implementierst dann den minimal nötigen Code und verbesserst anschließend die Struktur (Red-Green-Refactor).

TDD ist besonders hilfreich bei:

• Geschäftslogik mit klaren Regeln
• APIs und Modulen mit stabilen Schnittstellen
• Codebereichen, die häufig geändert werden

So entsteht oft besser testbarer, klarer strukturierter Code und Regressionen werden früher erkannt.

Struktur schaffen mit Design Patterns

Design Patterns werden benötigt, weil in Softwareprojekten viele Probleme immer wieder auftreten. Statt jedes Mal eine neue, ungeprüfte Lösung zu bauen, nutzt du bewährte Strukturen.

Sie helfen konkret bei:

• Verständlichkeit: Andere Entwickler erkennen schneller, wie dein Code aufgebaut ist.
• Wartbarkeit: Änderungen sind einfacher, weil Verantwortlichkeiten klarer getrennt sind.
• Erweiterbarkeit: Neue Features lassen sich oft mit weniger Umbau integrieren.
• Teamkommunikation: Begriffe wie Factory, Observer oder Strategy sind eine gemeinsame Sprache.
• Risikoreduktion: Patterns sind praxiserprobt und vermeiden typische Architekturfehler.

Kurz: Design Patterns machen Code nicht “magisch besser”, aber sie machen komplexe Systeme robuster und für Teams beherrschbarer.

Software-Engineering – erfolgreich Großprojekte umsetzen

Sobald mehrere Teams parallel an einem Produkt arbeiten, reicht reine Softwareentwicklung nicht mehr aus. Spätestens bei Teamgrößen von etwa 8 bis 12 Personen (oder mehreren unabhängigen Feature-Teams) steigen Koordinationsaufwand, Integrationsrisiken und Betriebsverantwortung deutlich.

Dann geht es nicht nur um “Features bauen”, sondern auch um:

• einheitliche technische Leitplanken
• verlässliche Release- und Betriebsprozesse
• klare Verantwortlichkeiten zwischen Entwicklung, Produkt und Betrieb
• skalierbare Qualitätssicherung über Teamgrenzen hinweg

Genau hier beginnt der eigentliche Mehrwert von Software Engineering.

Neue Rollen

Mit wachsender Produkt- und Teamgröße entstehen zusätzliche Rollen, die Entwicklung strukturieren und skalierbar machen.

Projektleiter koordinieren Zeit, Budget, Abhängigkeiten und Risiken.
Sie sorgen dafür, dass Entscheidungen transparent sind und Teams in die gleiche Richtung arbeiten.

Requirements Engineers präzisieren Anforderungen und übersetzen fachliche Ziele in umsetzbare Spezifikationen.
Dadurch sinken Missverständnisse zwischen Fachseite, Produktmanagement und Entwicklung.

DevOps-Teams bauen die Brücke zwischen Entwicklung und Betrieb.
Sie verantworten u. a. CI/CD-Pipelines, Deployment-Prozesse, Monitoring und stabile Betriebsabläufe.

Wichtig ist das Zusammenspiel: Diese Rollen ersetzen nicht die Entwicklung, sondern schaffen den Rahmen, in dem Entwicklung zuverlässig liefern kann.

Architektur definieren

Architektur beschreibt die grobe Struktur und die Kommunikationswege eines Systems, z. B.:

• Frontend – Backend – Datenbank
• Schichtenarchitektur
• Event-basierte Systeme (Pub/Sub)
• Dependency-Injection-Frameworks

Sie legt die Leitplanken fest, nicht jedes Implementierungsdetail.

Software betreiben und ausliefern

Zum Engineering gehört auch der Betrieb:

• CI/CD (Continuous Integration / Continuous Deployment) für automatisches Bauen, Testen und Ausrollen
• Staging-Umgebungen vor Produktion
• Branching-Strategie (z. B. Trunk-Based oder Gitflow)
• Containerisierung mit Docker/Kubernetes
• Monitoring und Qualitätsmetriken
• Release Notes pro Version oder Deployment
• Artifact Mirror/Artifact Repository für kontrollierte Abhängigkeiten und Build-Artefakte

Quality Dashboards nutzen

Quality Dashboards machen Qualität messbar statt gefühlt. Typische Kennzahlen sind:

• Testabdeckung und Fehlerraten
• Build- und Deployment-Stabilität
• Laufzeitmetriken wie Latenz, Fehlerquote und Verfügbarkeit
• technische Schulden (z. B. statische Analyse, Duplikate, Komplexität)

Nicht jede Metrik passt für jedes Team. Entscheidend ist, wenige Kennzahlen konsequent zu nutzen und Trends zu beobachten.

Blindspots im Alltag

Einige Themen fehlen in vielen Teams anfangs, sind aber zentral für professionelles Software Engineering:

• Security by Design: Threat Modeling, Dependency-Scans, Secret-Management, Sicherheitsupdates
• Reliability Engineering: SLOs, Alerting, Runbooks, Incident- und Postmortem-Prozesse
• Wartbarkeit: technischer Schuldenabbau, regelmäßige Refactorings, klare Ownership
• Wissensverteilung: Onboarding, Pairing, Reviews und Dokumentation statt “Single Points of Failure”

Fazit

Software Engineering ist mehr als Programmieren. Es verbindet Technik, Prozesse und Zusammenarbeit, damit Software langfristig zuverlässig, wartbar und nutzbar bleibt.

Wie ich eingangs erwähnte: Dies ist ein gedankliches Modell. Die Grenzen zwischen den Bereichen sind fließend: Man kann natürlich von Anfang an Versionskontrolle einsetzen und ein CI/CD-System für ein einfaches „Hello World“-Programm einrichten. Mein Hauptanliegen ist es, das Bewusstsein dafür zu schärfen, dass Softwareentwicklung eine Vielzahl von Werkzeugen und Praktiken umfasst, deren Lernkurve steil ist, wenn man versucht, alles auf einmal zu beherrschen. Durch die Unterteilung des Fachgebiets in drei Ebenen lassen sich die Konzepte möglicherweise leichter schrittweise erfassen und die Fähigkeiten von innen nach außen entwickeln.

Links

Die Junior und die Senior-Rolle

Wie baue ich eine entwicklungsbegleitende Software-Qualitätssicherung auf?

Wie TDD die Welt rettet und deine Nerven schont

Pytest Tutorial

So verwendest du Google Test in deinem C++-Projekt

Alles was du über Scrum wissen musst

Writing as a complementary skill for your SW engineering career

Literatur

The Software Engineer’s Guidebook

Mein erster Kontakt mit TDD (old but gold) 

The post Was ist Software Engineering? Eine verständliche Einführung appeared first on Creatronix.

Eine einzelne Ubuntu-Maschine zu warten, ist noch überschaubar. Man loggt sich per SSH ein, installiert ein paar Pakete, macht ein Update – und dann läuft die Kiste wieder.

In der Robotik bleibt es aber selten bei einer Maschine. Sobald mehrere Roboter im Einsatz sind, sitzt man plötzlich vor einem kleinen Zoo aus Linux-Systemen.

Dann beginnt die klassische Runde:
SSH auf Rechner eins, Updates einspielen.
SSH auf Rechner zwei, dieselben Updates einspielen.
SSH auf Rechner drei – na, Du ahnst es schon.

Spätestens nach dem fünften Roboter merkt man: Das ist weniger Systemadministration und mehr Fleißarbeit mit Copy-Paste.

Genau hier kommt Ansible ins Spiel. Mit sogenannten Playbooks beschreibt man einfach den gewünschten Zustand der Systeme – welche Pakete installiert sein sollen, welche Konfigurationen gelten, welche Updates eingespielt werden. Ansible kümmert sich dann darum, diese Zustände automatisch auf allen Zielrechnern umzusetzen.

Gerade in Robotik-Umgebungen mit vielen verteilten Rechnern sorgt dieser Ansatz dafür, dass Wartung nicht mehr Handarbeit ist – sondern planbar, reproduzierbar und vor allem deutlich entspannter.

Ansible

Ansible wurde 2012 von Michael DeHaan entwickelt und als Open-Source-Projekt veröffentlicht. 2015 wurde das Unternehmen Ansible, Inc. von Red Hat übernommen, das wiederum seit 2019 zu IBM gehört.

Es ist ein agentenloses Automatisierungstool – das heißt, auf den Zielrechnern muss keine zusätzliche Software installiert werden. Ansible verbindet sich einfach per SSH und führt die gewünschten Aufgaben aus.

Setup

Für dieses Tutorial brauchst Du einen Ubuntu-PC und einen Raspberry Pi mit einem installierten Ubuntu. Auf deinem Control-Rechner (also deinem PC) läuft Ansible und der SSH Client, auf dem Raspberry (also dem Remote-Rechner) muss der SSH-Server aktiviert sein.

Installation

Auf deinem Control-Rechner installierst du Ansible wie folgt:

sudo apt update
sudo apt install ansible
sudo apt install sshpass

Jetzt kannst Du testen, ob die Installation geklappt hat:

ansible --version

SSH aktivieren

Damit Ansible funktioniert, muss auf dem Raspberry aka Remote-Rechner SSH eingerichtet sein.
Probier mal im Terminal deines Control-Rechners aus, dich mit dem Raspberry zu verbinden:

ssh pi@192.168.178.50

Falls das nicht klappt, musst du SSH auf dem Raspberry aktivieren. Das geht ganz einfach über die raspi-config:

sudo raspi-config

Dann navigierst du zu “Interfacing Options” -> “SSH” und aktivierst den SSH-Server.

Projektordner

Auf deinem Control-Rechner legst du dir z.B. einen Projektordner an:

mkdir ~/ansible
cd ansible
touch hosts
touch ansible.cfg
touch update_pi.yml

Die Ordnerstruktur soll nachher so aussehen:

ansible/
├── hosts
├── update_pi.yml
└── ansible.cfg

hosts-Datei anlegen

In der hosts-Datei stehen die Rechner und ihre IP-Adressen bzw. ihre A-Records.

[raspberry]
pi1 ansible_host=192.168.178.66 ansible_user=<username>

ansible.cfg

Die ansible.cfg Datei ist die Konfigurationsdatei für Ansible.
Hier kannst du verschiedene Einstellungen vornehmen, z.B. den Pfad zu deiner hosts-Datei.
Ein einfaches Beispiel sieht so aus

[defaults]
inventory = hosts

Playbooks

Playbooks sind die Ansible-Äquivalente zu Skripten, sie beschreiben die gewünschten Zustände der Zielrechner.
Ein einfaches Playbook für die Updates des Raspberrys könnte so aussehen:

update_pi.yml

---
- name: Update Raspberry Pi
  hosts: raspberry
  become: yes

  tasks:
    - name: Update apt cache
      apt:
        update_cache: yes

    - name: Upgrade all packages
      apt:
        upgrade: dist

Im Detail

Ansible starten

Wenn du diese drei Dateien anegelegt hast, kann es auch schon losgehen

ping

Der ping-Befehl ist ein Testmodul von Ansible, das überprüft, ob der Host erreichbar und ausführbar ist.
Wenn du Passwort-Login benutzt musst du Ansible sagen, dass es nach einem SSH-Passwort fragen soll:
Das -k steht für –ask-pass

ansible -i hosts raspberry -m ping -k
SSH password:

Wenn alles funktioniert, solltest du folgenden Output sehen:

pi1 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}

Playbook starten

Jetzt zum eigentlichen Task:

ansible-playbook -i hosts update_pi.yml -k -K

Da wir sudu apt update / upgrade machen wollen, müssen wir auch das root-PW übergeben. Das machen wir mit dem Flag -K.
-K steht für –ask-become-pass, damit wird Ansible nach dem sudo-Passwort fragen.

Zertifikat-Login

Da wir aber nicht permanent die
Ansible unterstützt auch die Authentifizierung mit Zertifikaten, was sicherer ist als die Passwort-Authentifizierung.
Dazu musst du auf deinem Control-Rechner ein SSH-Schlüsselpaar generieren und den öffentlichen Schlüssel auf den
Zielrechner kopieren.

ssh-keygen -t rsa -b 4096 -C "@ansible-controller"
ssh-copy-id @192.168.178.66

Danach kannst du Ansible ohne Passwort verwenden, indem du einfach den Hostnamen angibst:

ansible-playbook -i hosts update_pi.yml -K

Weitere Beispiele

Ubuntu-Pakete installieren

Man kann natürlich auch andere Pakete installieren, z.B. git:

tasks: 
- name: Install git 
  apt: 
    name: git 
    state: present 
    update_cache: yes

Git Repository klonen

Auch das Klonen eines Git-Repositories ist mit Ansible kein Problem:

tasks: 
- name: Clone Git repo 
    git:
      repo: https://github.com/user/meinprojekt.git 
      dest: /home/pi/meinprojekt 
      version: main

Fazit

Ansible ist ein mächtiges Werkzeug, um die Wartung von Robotern zu automatisieren. Es ermöglicht dir, den Zustand deiner
Systeme zu beschreiben und automatisch umzusetzen, ohne dich manuell auf jedem Rechner einzuloggen. Gerade in Umgebungen
mit vielen verteilten Rechnern spart das enorm viel Zeit und Nerven.

The post So verwaltest du deine Roboter mit Ansible appeared first on Creatronix.

SCRUM wurde von Ken Schwaber und Jeff Sutherland entwickelt und ist ein agiles Framework für die Softwareentwicklung.
Es hilft Teams, komplexe Projekte zu managen und schnell auf Veränderungen zu reagieren.
SCRUM fördert die Zusammenarbeit, Transparenz und kontinuierliche Verbesserung.

Werte

Commitment, Focus, Openness, Respect, and Courage

Vorgehensmodell

Interativ & Inkrementell

Entwicklungszeitraum wird in Sprints unterteilt

Sprints

Dauer: 2-4 Wochen
Ziel: funktionierende Software nach jedem Sprint mit neuen Features die den Geschäftswert des Produkte maximieren

Messen der Velocity

• Velocity = Anzahl der Story Points, die in einem Sprint abgeschlossen wurden
• hilft bei der Planung zukünftiger Sprints

Rollen

Product Owner

Stellvertreter des Kunden und der Stakeholder
Der Product Owner ist verantwortlich für:

• Produktvision und Strategie
• Product Backlog erstellen und priorisieren
• Anforderungen verstehen, übersetzen und priorisieren
• Wert für das Produkt maximieren
• Stakeholder koordinieren

Er ist die zentrale Entscheidungsinstanz für das Produkt.

Scrum Master

• coacht Teammitglieder und Organisation
• verwaltet impediment backlog
• löst impediments auf
• moderiert Meetings mit dem Ziel, die Effizienz des Teams zu verbessern
• schützt das Team vor äußeren Störungen
• fördert die Einhaltung von Scrum-Prinzipien und -Praktiken

Scrum Team

• schätzt User Stories
• setzt Stories um
• arbeitet selbstorganisiert
• cross-funktional (Entwickler, Tester, Designer etc.)
• verantwortlich für die Lieferung von Inkrementen am Ende jedes Sprints

Artefakte

Inkrement

Neue Software, die am Ende eines Sprints fertiggestellt und potenziell auslieferbar ist.

Product-Backlog

• enthält User Stories mit Definition of Done (DoD) und Akzeptanzkriterien
• priorisiert nach Business Value
• dynamisch, wird während des Projekts angepasst

Sprint-Backlog

• alle Items für den Sprint, inkl. DoD und Akzeptanzkriterien
• Burndown / Burnup Chart für Fortschrittsverfolgung

Impediment-Backlog

Für Hindernisse, die das Team daran hindern, die Sprint-Ziele zu erreichen
Beispiele:

• CI Pipeline funktioniert nicht
• Zugang zu Testdaten fehlt
• API Dokumentation unvollständig
• Fehlende Hardware für Tests

Termine

Backlog Refinement (früher Backlog Grooming)

Zeitpunkt: 1-2 mal pro Sprint, oft in der Mitte des Sprints
Dauer: 1-2 Stunden
Ziel: User Stories mit DoD, Akzeptanzkriterien und Story Points versehen, damit sie für die Sprintplanung bereit sind

Planning Poker

Wie geschätzt wird, lässt Scrum offen, aber Planning Poker ist beliebt.
Jeder Teilnehmer erhält Karten mit Zahlen (z.B. Fibonacci-Folge: 1, 2, 3, 5, 8, 13)

Die Zahlen stehen für die Komplexität der Aufgabe von 1 – sehr simpel bis 13 sehr komplex.
Der Product Owner liest eine User Story vor, und die Teilnehmer schätzen gleichzeitig, indem sie eine Karte mit ihrer Schätzung hochhalten
Nach der Schätzung diskutieren die Teilnehmer, um ein gemeinsames Verständnis zu erreichen.

Sprint Planning

Zeitpunkt: Am Anfang eines Sprints
Dauer: 4-8 Stunden (je nach Sprintlänge)
Ziel: Sprint-Ziele festlegen, User Stories auswählen, die im Sprint bearbeitet werden sollen, und Aufgaben planen

Daily Standup

Zeitpunkt: Täglich, meist morgens
Dauer: 15 Minuten
Ziel: Mini-Retro: Awareness für erledigte und aktuelle Tätigkeiten, Impediments an Scrum Master kommunizieren

Sprint Retro

Zeitpunkt: Am Sprint-Ende
Dauer: 1-2 Stunden
Ziel: Reflexion über den vergangenen Sprint, Identifikation von Verbesserungsmöglichkeiten, Maßnahmen für den nächsten Sprint planen

Scrum but – Antipatterns

Wenn Scrum nicht richtig umgesetzt wird, können verschiedene Probleme auftreten, z.B.:

• Scrum Master ist nur ein Titel, aber keine echte Rolle im Team
• Product Owner ist nicht verfügbar oder hat keine Entscheidungsbefugnis
• Team arbeitet nicht selbstorganisiert, sondern wird von außen gesteuert
• Sprints werden nicht eingehalten, sondern ständig verlängert oder verkürzt
• Meetings werden nicht effektiv genutzt, sondern sind reine Zeitverschwendung
• Keine klare Definition of Done, was zu unklaren Anforderungen und Qualitätsproblemen führt
• Keine regelmäßige Retrospektive, was zu fehlender kontinuierlicher Verbesserung führt
• Keine klare Priorisierung im Product Backlog, was zu ineffizienter Arbeit und fehlendem Fokus führt

Quellen

https://scrumguides.org/scrum-guide.html

The post Alles, was Du über SCRUM wissen musst appeared first on Creatronix.

In Robotik-Projekten wird in den meisten Fällen mit einer Linux-Distribution wie Ubuntu gearbeitet, deswegen ist es von Vorteil, sich auch auf der Linux-Konsole aka shell auszukennen.

Die Standard-Shell ist meistens Bash (Bourne Again Shell). Viele ROS-Tools erwarten explizit Bash:

source /opt/ros/humble/setup.bash

Informationen über Kommandos

Mit dem Kommando man kann man sich Infos zu den Kommandos geben lassen:

man ls

Eine moderne Alternative ist tldr:

tldr ls

Du kannst es unter Ubuntu mit

sudo snap install tldr

installieren.

Datei-Handling

Benutzer & Rechte

Linux-Pakete & Versionsinformationen

Prozesse

Netzwerke

USB

The post Linux Shell Kommandos Cheatsheet appeared first on Creatronix.

Als Führungskraft erlebt man immer wieder Spannungen im Team, weil die Erwartungen an eine Rolle oder Position nicht klar definiert sind. Was genau wird von einem Junior erwartet? Woran misst sich eine Senior-Rolle wirklich?

Wenn diese Erwartungen nicht transparent sind, entstehen Missverständnisse – sowohl in der Zusammenarbeit als auch in der persönlichen Weiterentwicklung. Dieser Text soll helfen, die Unterschiede klarer zu machen und Orientierung zu geben.

Disclaimer

Die folgenden Gedanken stammen aus meiner persönlichen Erfahrung in der Softwareentwicklung.
Viele Punkte lassen sich sicher auf andere Disziplinen übertragen, der konkrete Kontext ist jedoch die Arbeit in
Softwareprojekten – mit Code, Ticketsystemen, Deployments und technischen Abhängigkeiten.

Junior

Ehrlich gesagt bin ich kein Fan der Bezeichnung „Junior“. In vielen Betrieben wird dieser Begriff jedoch genutzt, um eine Entry-Level-Rolle zu beschreiben. Dabei geht es weniger um Alter oder gesamte Berufserfahrung, sondern vielmehr um den Fit der Skills zur konkreten Stelle.

Denn egal, wie viel Vorerfahrung jemand aus einer anderen Software-Engineering-Position mitbringt: Jede neue Stelle bietet genügend Herausforderungen, um sich über Wochen oder sogar Monate einarbeiten zu müssen.

Beispiele:

• Du hast Erfahrung in Vue 3 – die Firma arbeitet noch mit Vue 2 oder React
• Du kennst dich mit CMake aus – das Unternehmen nutzt jedoch Perforce Jam oder natives make.

Je schneller ein Mitarbeiter oder eine Mitarbeiterin den Anforderungen der neuen Rolle gerecht wird und eigenverantwortlich im Tagesgeschäft arbeiten kann, desto eher kann das Attribut „Junior“ abgelegt werden.

Welche Tipps ergeben sich daraus für eine Junior-Rolle?

Kommunikation & Netzwerken

Vermeide es, in deiner Junior-Zeit zum Einzelkämpfer zu werden – Teamwork makes the dream work.

Hilfe suchen – 30-Minuten-Regel

Wenn du nach 30 Minuten konzentrierter Recherche keinen Ansatz oder keine Richtung siehst – frag nach Hilfe.

Hast du zwar einen Ansatz und vielleicht schon ersten Code geschrieben, siehst aber nach zwei bis vier Stunden noch kein Licht am Ende des Tunnels, dann solltest du ebenfalls Unterstützung einholen.

Adressatenkreis beachten

Wähle die richtigen Verteiler / Personenkreis. Wer benötigt diese Information wirklich?

Flughöhe beachten (Detailgrad der Information)

Wenn du den passenden Verteiler identifiziert hast, überlege dir, wie viele Details die Empfänger benötigen. Führungskräfte möchten meist das große Ganze, neudeutsch: Big Picture. Techniker freuen sich auch über Code-Snippets oder technische Details.

Medienbrüche vermeiden

Kommt eine Anfrage per E-Mail, antworte nicht im Chat. Wird ein Thema in einem Ticket eröffnet, führe die Diskussion dort weiter. Wenn ihr aneinander vorbeiredet, greift zum Hörer und klärt Unklarheiten synchron.

Wichtig: Fasse das Ergebnis eines Gesprächs anschließend schriftlich zusammen.

Tasks gliedern – Nächste sinnvolle Schritte erarbeiten und dokumentieren

Als Full-Stack-Developer in einem Webprojekt solltest du ein Feature sauber zerlegen können, zum Beispiel:

• Button im Frontend einbauen
• API-Endpoint im Backend hinzufügen
• Datenbankschema anpassen

Diese Schritte sollten auch im Ticket dokumentiert werden.

Feedback – Frühzeitiges Einbeziehen weiterer Kollegen

Wenn du Schwierigkeiten bei der Zerlegung von Aufgaben hast, frage erfahrene Kollegen, welche Schritte erforderlich
sind.

Auch den Einsatz externer Libraries oder Tools solltest du vorab abstimmen, bevor du tagelang implementierst. Manche
Projekte verbieten bestimmte Technologien, etwa Exceptions oder Introspection/Reflection/RTTI. Auch OSS-Lizenzen wie
GPLv3 oder AGPL können problematisch sein.

Basiswissen über Produkte und Projekte deiner Firma aneignen

Versuche, möglichst viel über die Produkte und Projekte deiner Firma zu lernen. Gibt es Ausstellungen, Demoräume oder Hausmessen? Nutze diese Gelegenheiten und beschäftige dich intensiv mit den Produkten. Benutze Produkte aus der Perspektive der Endanwender.

Code schreiben

Am Anfang ist es oft schwierig, sich in einer neuen Codebasis zurechtzufinden.

Vermeide es, stundenlang nur Code zu lesen. Starte stattdessen – falls vorhanden – einen Unit- oder Komponententest und debugge dich durch die Anwendung. Das ist meist effizienter.

Wenn du grob verstanden hast, was der Code macht, beginne mit kleinen Experimenten. In der Regel steht der Code unter Versionsverwaltung – du kannst also Änderungen vornehmen und sie jederzeit zurückrollen.

Gibt es noch keine Tests, ist das deine Chance, einen ersten Test für den Happy Path zu schreiben.

Du kannst außerdem:

• undokumentierte Funktionen mit Docstrings versehen
• die Wiki-Seite überarbeiten
• Rechtschreibfehler korrigieren oder defekte Links reparieren

All das hilft dir, dich mit dem Projekt vertraut zu machen – und zeigt Proaktivität. „Däumchen drehen“ wird selten
positiv wahrgenommen.

Spekulative Generalisierung vermeiden

„Premature optimization is the root of all evil.“

Nutze beispielsweise die Rule of Three: Implementiere erst zur Generalisierung, wenn du etwas dreimal nahezu identisch implementiert hast. Man sollte nicht zu früh abstrahieren, sondern erst dann, wenn sich ein Muster wirklich bestätigt hat.

Löse die Probleme von heute – nicht die von morgen.

Versionsverwaltung konsequent benutzen

Committe mehrmals am Tag und pushe deine Änderungen spätestens bevor du abends gehst.

Einsatz von AI

Nutze AI-Tools gezielt als Lern- und Sparringspartner.

Lass dir bestehenden Code erklären – insbesondere dann, wenn du dich in einer neuen Codebasis zurechtfinden musst. Du kannst dir außerdem Verbesserungsvorschläge für deinen eigenen Code geben lassen, etwa in Bezug auf Lesbarkeit, Struktur oder mögliche Edge Cases. Wichtig ist jedoch: Vermeide es, große Code-Blöcke generieren zu lassen, die du selbst noch nicht vollständig verstehst.

Senior

Folgende Themen sind aus meiner Sicht entscheidend, um eine Senior-Rolle auszufüllen:

Ownership & Planung

Ownership bedeutet, ein Thema aktiv zu übernehmen – so wie ein Hausbesitzer sich eigenverantwortlich um sein Haus
kümmert. Beispiel: Du bringst den Müll raus, ohne dass dich jemand daran erinnern muss.

Proaktives Handeln

Die Fähigkeit, Themen selbstständig zu identifizieren und anzugehen – ohne explizite Beauftragung.

Beispiel: Du entwickelst an einem Webportal mit nur einem Produktivsystem, während alle lokal entwickeln. Du erkennst, dass ein Staging-System sinnvoll wäre, um vor dem Live-Deployment ausführlicher zu testen und „Works on my machine“-Probleme zu
vermeiden. Also setzt Du ein Staging-System auf.

Den eigenen Standard nicht verhandelbar machen

Arbeitet ihr mit einem Ticketsystem, dann halte dich daran.

Wenn ein Kunde (intern oder extern) dich bittet, einen Bug zu fixen, arbeite nicht einfach „auf Zuruf“. Lass ein Ticket erstellen oder erstelle es selbst im Namen des Auftraggebers.

Kommuniziere gerne per E-Mail, Telefon oder Chat – aber halte wichtige Informationen, Entscheidungen und Anforderungen
im Ticket oder Wiki fest. Bereite diese Kommunikation so auf, dass Du und andere noch nach ein paar Tagen wisst, was gemeint war.

#werschreibtderbleibt

Work Breakdown

Noch stärker als in der Junior-Rolle ist hier die Fähigkeit gefragt, komplexe Arbeitspakete in umsetzbare Unteraufgaben
zu zerlegen. Ich nenne sie gerne Minimum Viable Actions – Aufgaben, die nicht weiter zerlegbar sind.

Warum ist das wichtig?

Gerade wenn man mehrere Projekte betreut, wird man häufig unterbrochen (Task Switching). Wenn die kleinste bearbeitbare
Einheit nicht klar definiert ist, entstehen Reibungsverluste.

Ich habe oft erlebt, dass Projekte stagnieren, weil eine Zuarbeit fehlt und alle warten – obwohl parallel andere Aufgaben erledigt werden könnten.

Deshalb:

• Identifiziere minimal umsetzbare Tasks
• Suche nach Dingen, die jetzt erledigt werden können
• Beantrage Rechte
• Bestelle Server
• Bereite Dokumentation vor.

Das verkürzt Ticketlaufzeiten erheblich.

Abgeben von realistischen Schätzungen und Deadlines

Eine häufige Aussage ist: „Das schaffe ich in ein bis zwei Tagen.“

Dabei werden externe Abhängigkeiten oft vergessen – etwa die IT-Abteilung oder Kollegen, die noch Zugriffsrechte
freigeben müssen.

Für den Auftraggeber zählt nicht nur die reine Entwicklungszeit, sondern wann das Ergebnis vorliegt.

Der „Teufel ist ein Eichhörnchen“: Der Kollege, der Rechte freigeben muss, ist krank oder im Urlaub. Oder der Chef will noch eine Powerpoint sehen, bevor er Budgets freigeben kann – und aus zwei Tagen werden zwei Wochen.

Solche Risiken sollten in der Planung berücksichtigt und transparent kommuniziert werden.

Kommunikation und Delegation

In der Senior-Rolle geht es weniger darum, alles selbst zu erledigen – sondern darum, dass Dinge erledigt werden.

Aufgaben aktiv abgeben oder „Won’t do“ kommunizieren

Andere in die Lage zu versetzen, Aufgaben zu übernehmen, ist essenziell.

Wenn etwas innerhalb der Deadline nicht realistisch umsetzbar ist, ist es fair, das offen zu kommunizieren: „Das werden wir in diesem Zeitraum nicht schaffen.“

Das gibt dem Auftraggeber die Möglichkeit, Alternativen zu prüfen.

Tasks delegierbar aufbereiten & Erwartungen definieren

Wenn du Aufgaben delegieren willst, müssen sie so vorbereitet sein, dass andere problemlos übernehmen können.
Was für dich selbstverständlich ist, ist für andere – besonders Junior-Developer – nicht immer klar. Deshalb:

• Abläufe explizit dokumentieren
• Systeminteraktionen beschreiben
• Erwartungshaltungen definieren
• Idealerweise im Ticket oder Wiki.

Finde eine Balance: Genug Information, damit 80 % der Aufgabe umsetzbar sind – ohne sie faktisch schon selbst erledigt zu haben ( 80/20-Prinzip).

Rechtzeitige Kommunikation & Statusupdates

Für externe Beteiligte muss klar sein:

• Wer macht was?
• Bis wann?
• Welche Blocker gibt es?

Frühzeitige Statusupdates sind kein Zeichen von Schwäche, sondern von Professionalität.

Oft glauben wir, blockiert zu sein, weil Informationen fehlen. Spiegelt man diese Blockade dem Kunden, führt das häufig zu Klarheit oder besseren Alternativen.

Erfahrene Entwickler lernen zudem: Kunden kommen oft mit einem Lösungsansatz – nicht mit dem eigentlichen Problem.

Wenn dieser Ansatz ungeeignet ist, ist es professionell zu sagen: „Wir lösen dein Problem – aber mit einem anderen Weg.“

Einsatz von AI

Verwende AI-Tools gerne intensiv – aber immer als Sparringpartner, nicht als Ersatz für dein Urteilsvermögen. Als Senior liegt dein Mehrwert nicht nur im Schreiben von Code, sondern in Bewertung, Einordnung und Qualitätssicherung.

Beispiele für sinnvollen Einsatz:

• Du schreibst den Unit-Test – die AI schlägt eine mögliche Implementierung vor, die du anschließend kritisch reviewst
• Du implementierst eine Lösung – die AI generiert zusätzliche Testcases oder ergänzt die Dokumentation
• Du lässt dir alternative Lösungsansätze oder Refactorings vorschlagen und vergleichst sie mit deinem eigenen Ansatz
• Du sparst Zeit, indem du dir neue Projekte, Module oder wiederkehrende Strukturen bootstrappen lässt.

Wichtig dabei:

• Behalte die Architekturhoheit
• Hinterfrage generierten Code kritisch
• Achte auf Randfälle, Sicherheit und Projektkonventionen
• Übernimm nur, was du fachlich vertreten kannst.

Ein praktischer Tipp: Committe Änderungen nach jedem sinnvollen Prompt. So bleiben Experimente nachvollziehbar, und du kannst jederzeit zu einem stabilen Stand zurückkehren.

Fazit

Ein Senior ist oft wie ein Zirkusartist, der mit vielen Bällen – oder auch brennenden Hamstern – jongliert. Idealerweise bleiben alle in der Luft und fallen nicht herunter.

Wenn du in einem Thema blockiert bist, solltest du an einem anderen minimalen Task weiterarbeiten können. So entsteht kontinuierlicher Fortschritt – auch bei Abhängigkeiten.

Drei Bücher, die mir geholfen haben:
The Software Engineer’s Guidebook
The 7 Habits of Highly Effective People – Stephen R. Covey
Extreme Ownership – Jocko Willink 

(Amazon Affiliate Links)

Weiterlesen

Five Books every Junior Developer should own

Writing as a complementary skill for your SW engineering career

The post Die Junior und die Senior-Rolle appeared first on Creatronix.

Tests sind ein zentraler Bestandteil moderner Entwicklung. Das Framework pytest macht das Schreiben, Organisieren und Ausführen von Tests einfach, flexibel und leistungsfähig.

Tests schreiben und ausführen

Installation

Zuerst installierst du pytest mit:

pip install pytest

pytest ist kompatibel mit unittest-Tests und erfordert keine Testklassen.

Namenskonventionen

Damit pytest Tests automatisch findet, müssen Dateien und Funktionen bestimmte Namen haben:

• Dateinamen haben test im Namen
• Funktionsnamen beginnen mit test_

Beispiel:

def test_example():
    x = 5
    assert x == 5

Mit pytest im Terminal führt pytest alle passenden Tests aus.

Testauswahl

Du kannst gezielt Tests ausführen:

pytest test_module.py::test_function
pytest -k "keyword"

Optionen wie -v (verbose), -x (bei Fehler abbrechen) oder -s (print-Ausgaben anzeigen) sind sehr praktisch.

Um Optionen nicht immer per Hand eingeben zu müssen, können diese auch in einer pytest.ini angegeben werden:

[pytest]
pythonpath = .
addopts = -x --durations=0 -vv

Fortgeschrittene pytest-Techniken

Fixtures

import pytest

@pytest.fixture(scope="function")
def simple_fixture():
    return 42

def test_function(simple_fixture):
    assert simple_fixture == 42

Fixture scopes

pytest-Fixtures haben einen Scope, der bestimmt, wie oft eine Fixture erzeugt und wiederverwendet wird.
Der Standard-Scope ist function, d. h. die Fixture wird für jeden Test neu ausgeführt.

Weitere Scopes sind:

• class – einmal pro Testklasse
• module – einmal pro Datei
• package – einmal pro Paket
• session – einmal pro gesamtem Testlauf

Größere Scopes verbessern die Performance, bergen aber das Risiko von geteiltem Zustand zwischen Tests.
Daher gilt: so klein wie möglich, so groß wie nötig.

Setup and teardown

Mit pytest können wir klassische setup / teardown Methoden mit fixtures nachbauen

import pytest

def test_setup_and_teardown():
    assert True

@pytest.fixture(autouse=True, scope="function")
def setup_and_teardown():
    print("SetUp")
    # setup code goes here
    yield
    print("TearDown")
    # teardown code goes here

Parametrisierung

Mit Parametrisierung lässt sich derselbe Test mit verschiedenen Daten ausführen. So umgehst du Duplikate:

import pytest

@pytest.mark.parametrize("data, expected", [
    ([1], 1),
    ([1, 2], 1.5),
    ([1, 2, 3], 2),
])
def test_calculate_mean(data, expected_mean):
    mean = calculate_mean(data)
    assert mean == expected_mean

def calculate_mean(data):
    return sum(data) / len(data)

Das definiert mehrere Testinstanzen automatisch.

Marker

Marker helfen, Gruppen von Tests zu steuern.
Marker eignen sich z. B. zur Gruppierung nach Plattform, Kategorie oder Dauer.

Es gibt drei eingebaute Marker:

• skip
• skipif
• xfail

import pytest
import sys

@pytest.mark.skip(reason="Feature not yet implemented")
def test_future():
    pass

@pytest.mark.skipif(sys.platform == "win32", reason="Linux only")
def test_linux_only():
    pass

@pytest.mark.xfail(reason="Bug #123")
def test_known_bug():
    pass

Eigene Marker

import pytest

@pytest.mark.slow
def test_slow():
    pass

In pytest.ini:

[pytest]
...
markers =
    slow: mark slow tests

Dann kannst du testen mit:

pytest -m slow

Oder alle nicht langsamen Tests laufen lassen:

pytest -m "not slow"

Nahezu gleiche Vergleiche

Für Fließkommazahlen ist ein exakter Vergleich oft ungeeignet. pytest bietet das approx-Feature:

assert 2.2 == pytest.approx(2.3, 0.1)

Erlaubt eine Toleranz statt exakter Übereinstimmung.

Exceptions testen

Mit pytest kannst du das Auftreten von Ausnahmen elegant testen:

def test_zero_division():
    with pytest.raises(ZeroDivisionError):
        1 / 0

Das prüft, ob ein Fehler erwartet korrekt geworfen wird.

Test-Reporting & Coverage

Testabdeckung mit pytest-cov

Mit dem Plugin pytest-cov lässt sich messen, wie viel deines Codes getestet wird:

pip install pytest-cov

pytest --cov=my_app 10_app_test

Ergebnis: Coverage-Statistiken zeigen an, wie viele Zeilen getestet wurden.

HTML-Reports

Du kannst mit demselben Plugin HTML-Berichte erzeugen:

pytest --cov=my_app --cov-report=html

Eine visuelle Übersicht über die Abdeckung hilft bei der Analyse.

Integration mit Werkzeugen

Coverage-Daten lassen sich in Tools wie SonarQube einbinden:

pytest --cov-report=xml:coverage.xml

Dadurch kannst du Metriken in CI/CD-Pipelines oder Dashboards verwenden.

Assertions mit Hamcrest (optional, aber mächtig)

Neben den eingebauten assert-Anweisungen von pytest kann man auch Hamcrest verwenden.
Hamcrest ist eine Matcher-Bibliothek, die Tests lesbarer und ausdrucksstärker machen kann – besonders bei komplexen Datenstrukturen.

Installation

pip install pyhamcrest

Import in Tests:

from hamcrest import assert_that, equal_to

Warum Hamcrest?

Vergleich:

def test_hamcrest_assert():
    result = 42
    assert_that(result, equal_to(42))

Der Vorteil zeigt sich bei komplexeren Assertions:

def test_hamcrest_start_with():
    name = "Max Mustermann"
    assert_that(name, starts_with("Max"))

def test_hamcrest_has_length():
    items: Sized = ['apple', 'banana', 'cherry']
    assert_that(items, has_length(3))

Tests lesen sich mehr wie Spezifikationen.

Listen & Collections

from hamcrest import assert_that, has_items
from collections.abc import Sequence

def test_compare_list_of_items():
    actual_list_of_items: Sequence[str] = ['apple', 'banana', 'cherry']
    assert_that(actual_list_of_items, has_items("apple", "banana"))

Fazit

pytest ist ein einfaches, doch mächtiges Framework zur Testautomatisierung in Python. Es kombiniert:

• geringe Einstiegshürde – einfache Tests schnell geschrieben
• hohe Flexibilität – Marker, Parameter, Coverage
• gute Tools-Integration – HTML-Reports oder CI-Coverage

Damit eignet es sich sowohl für Einsteiger als auch für professionelle Test-Pipelines.

Code

https://github.com/jboegeholz/pytest_tutorial

The post Pytest Tutorial appeared first on Creatronix.