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.

Microsoft Kinect v1 – damals für die Xbox 360 erschienen – ist eine sehr beliebte Kamera mit einem zusätzlichen Infrarot-Tiefensensor.
Sie ist in Robotikkreisen sehr beliebt, weil sich durch die Tiefeninformation und die dadurch möglichen Umrechnungen in eine Point Cloud, Greifbewegungen von Roboterarmen automatisieren lassen.

Funktionsweise

• Der IR-Projektor wirft ein bekanntes Punktmuster
• Das Muster wird auf Objekten verzerrt
• Die IR-Kamera sieht diese Verzerrung
• Aus der Abweichung vom Referenzmuster wird die Tiefe berechnet

Disclaimer

Die Kinect benötigt eine externe Stromversorgung und funktioniert nicht ausschließlich über USB.

Ich hatte mit der Verbindung zu einer Ubuntu VM mit UMT und macos kein Glück. Hier kam es permanent zu frame drops. Deswegen bezieht sich dieses Tutorial auf die Einrichtung auf einem Raspberry Pi 4 mit ROS 2 Humble.

Anschluss am Raspberry

Ihr solltet die blauen USB 3.0 Ports verwenden.

Software

In diesem Tutorial werden wir

• libfreenect
• image_pipeline
• kinect_ros2

installieren

libfreenect

libfreenect ist ein Open Source Treiber für die Kinect, der auf macOS, Windows und Linux läuft.

Bauen und installieren

cd ~ 
git clone https://github.com/OpenKinect/libfreenect.git 
cd libfreenect 
mkdir build && cd build 
cmake .. -DBUILD_EXAMPLES=ON 
make 
sudo make install 
sudo ldconfig

Jetzt könnt ihr mit

freenect-camtest

ausprobieren, ob die Kinect bereits funktioniert. Es sollte “Received video frame” als Ausgabe kommen.

freenect-glview

freenect-glview ist ein weiteres Tool, um die Kinect zu testen, ihr könnt es mit:

freenect-glview

starten

Wenn der Befehl nicht gefunden wurde, müsst ihr noch die fehlende Abhängigkeit freeglut3-dev (Free OpenGL Utility Toolkit) installieren

sudo apt install freeglut3-dev

und die build-Schritte von oben wiederholen

ROS2-Anbindung

Voraussetzung ist ein funktionierender ROS-2-Workspace (~/ros2_ws) mit gesourcter Umgebung. Falls ihr das noch nicht gemacht habt, könnten euch diese Artikel helfen:
https://creatronix.de/so-installierst-du-ros-2-auf-dem-raspberry-pi-ball-chaser-mit-ros2/
https://creatronix.de/so-schreibst-du-pakete-und-nodes-in-ros/

Image Pipeline installieren

cd ~/ros2_ws/src 
git clone https://github.com/ros-perception/image_pipeline 
cd image_pipeline 
git checkout humble 
cd ~/ros2_ws 
colcon build 
source install/setup.bash

Um zu schauen, ob alles korrekt funktioniert, können wir nun in einem Terminal

ros2 run image_proc image_proc

und in einem zweiten Terminal:

ros2 run rqt_image_view rqt_image_view

ausprobieren.

Wenn ein Live-Bild in rqt_image_view erscheint, funktioniert die Image Pipeline korrekt.

rosdep initialisieren

Falls ihr bisher kein rosdep verwendet habt, müsst ihr das einmalig machen:

cd ~/ros2_ws 
sudo rosdep init 
rosdep update

kinect_ros2 installieren

Obwohl das Paket offiziell nur bis Galactic gepflegt ist, lässt es sich unter Humble aktuell problemlos aus dem Source bauen.

cd ~/ros2_ws/src 
git clone https://github.com/fadlio/kinect_ros2/tree/galactic 
cd ~/ros2_ws 
rosdep install --from-paths src --ignore-src -r -y 
colcon build
source install/setup.bash

Jetzt können die launch files gestartet werden

ros2 launch kinect_ros2 pointcloud.launch.py

Der Node kinect_ros2 publiziert jetzt die Topics /depth/image_raw und /depth/camera_info
Ihr könnt das auf der Kommandozeile mit

ros2 topic list

überprüfen.

Wir können jetzt auch die Bilder aufzeichnen und via rosbag in einem mcap speichern. Wir prüfen zuerst, ob die mcap-Erweiterung installiert ist:

ros2 bag info --storage-id mcap

Falls nicht

sudo apt install ros-humble-rosbag2-storage-mcap

Aufnehmen können wir nun mit

ros2 bag record /camera/depth/points -s mcap

Da die Datenmenge bei Bilddaten schnell sehr groß werden können, kann man mcap auch komprimiert aufzeichnen:

ros2 bag record \
/camera/depth/points \
-s mcap \
--compression-mode file \
--compression-format zstd

The post So verwendest du die Kinect unter ROS 2 appeared first on Creatronix.