Sample journey
Software engineering
This is one generated journey, shown in full: the fifteen-week arc, and one learning day from it. Your own is built from a conversation about your work, so it comes out narrower than this.
The fifteen weeks
Foundations
01Code Reviews: Fallstricke vermeidenAnalyse konkreter Code-Review-Beispiele und typischer Fehler in der Praxis.
- 02Technische Architektur: Microservices
Aufbau, Vorteile und Herausforderungen von Microservices mit einem realen Use Case.
- 03Agile Methoden: Code Reviews
Integration von Code Reviews in agile Workflows mit praktischen Anpassungen.
Deepening
04Code Review-Tools: GitLab vs. GitHubVergleich der Funktionen und Workflows beider Plattformen für effiziente Reviews.
- 05Architekturentscheidungen: Event Sourcing
Vertiefung in Event Sourcing mit Implementierungsdetails und Fallstricken.
- 06Code Quality: Static Analysis
Anwendung statischer Analysetools wie SonarQube für bessere Codequalität.
- 07Clean Code: Refactoring-Praktiken
Schritt-für-Schritt-Anleitungen zum Refactoring von Problemcode.
Application
08Code Review: Konflikte lösenStrategien für konstruktive Diskussionen bei Meinungsverschiedenheiten.
- 09Architekturentscheidungen: CQRS
Anwendung von Command Query Responsibility Segregation in realen Projekten.
- 10Code Reviews: Automatisierung
Einführung von CI/CD-Pipelines mit automatisierten Test- und Review-Schritten.
- 11Technische Schulden: Management
Identifikation und Priorisierung von technischer Schulden in Projekten.
Mastery
12Architektur: Serverless vs. KubernetesVergleich der Skalierbarkeit und Wartbarkeit beider Ansätze.
- 13Code Reviews: Sicherheitsaspekte
Sicherheitslücken erkennen und beheben in Code Reviews.
- 14Architektur: Event-Driven Systems
Design und Implementierung von ereignisgesteuerten Systemen.
- 15Code Reviews: Kulturelle Unterschiede
Einfluss von Teamkultur und Kommunikation auf effektive Reviews.
What a learning day asks of you
Every day is the same five exercises, in the same order. The content changes with your niche; the shape does not.
- Vocabulary — Meet the terms your field actually uses, each with a meaning and a real sentence.
- Fill in the gap — Put those terms back into their own sentences. It unlocks once the vocabulary exercise is done.
- Content lesson — Read a text from your field, then answer two rounds on it — true or false first, then open questions in your own words.
- Scenario — Write a response to a situation from your work. The register it demands comes from the situation, not from you.
- Role-play — Talk to a counterpart with their own agenda. You work toward a goal, and they push back.
One learning day
Five exercises, about fifteen minutes each, five days a week. Here is day one.
The reading
Typische Code-Review-Fehler analysieren
Häufige Fehler bei Code Reviews Code Reviews sind ein zentraler Bestandteil der Softwareentwicklung, doch selbst erfahrene Entwickler machen oft die gleichen Fehler. Analysieren wir drei typische Probleme und wie sie vermieden werden können. Ein häufiger Fehler ist die Unfähigkeit, zwischen stilistischen und technischen Problemen zu unterscheiden. Ein Reviewer könnte beispielsweise einen Code als unleserlich kritisieren, obwohl die eigentliche Schwachstelle in der Logik liegt. Solche subjektiven Bewertungen führen zu unnötigen Diskussionen und verzögern den Prozess. Beispiel: Ein Junior-Entwickler schreibt eine Funktion mit verschachtelten Schleifen. Statt die Performance zu optimieren, kritisiert der Senior-Entwickler nur den Code-Stil. Die eigentliche Problemstelle – die ineffiziente Schleifenstruktur – bleibt unentdeckt. Ein Team in einem mittelgroßen Unternehmen führt wöchentliche Code Reviews durch.
10 terms from it
| Term | Meaning | In a sentence |
|---|---|---|
| Code Reviews | A process where developers examine each other's code to find mistakes, improve structure, and ensure best practices. It's a collaborative step before merging code into the main project. | Code Reviews sind ein zentraler Bestandteil der Softwareentwicklung, doch selbst erfahrene Entwickler machen oft die gleichen Fehler. |
| Schwachstelle | weak point | Ein Reviewer könnte einen Code als unleserlich kritisieren, obwohl die eigentliche Schwachstelle in der Logik liegt. |
| Richtlinien | Established principles or rules that guide decisions or procedures. They provide consistency and structure in professional settings. | Ohne definierte Richtlinien für Code Quality, Selbsttests oder Dokumentation werden Reviews chaotisch. |
| Race Conditions | A bug where the outcome of a program depends on the sequence or timing of unrelated events, leading to unpredictable errors. | Ein Reviewer markiert ständig Variablennamen als zu kurz, ohne auf Security-Lücken oder Race Conditions einzugehen. |
| Checkliste | A list of items to be checked or completed, often used to ensure nothing is overlooked in a process. | Ein guter Ansatz ist die Erstellung einer Checkliste mit technischen und organisatorischen Anforderungen. |
| Kriterien | Standards or characteristics used to evaluate, judge, or make decisions. They define what is acceptable or required. | Ein weiterer Fehler ist das Fehlen klarer Kriterien. |
| Nomenklatur | A system of naming things, concepts, or variables in a specific field. It ensures clarity and consistency. | Das Team verliert wertvolle Zeit mit Debatten über Nomenklatur, während kritische Fehler übersehen werden. |
| Logik | The systematic and coherent arrangement of thoughts, steps, or commands in a program or argument. | Obwohl die eigentliche Schwachstelle in der Logik liegt. |
| Performance | How fast or efficiently a program or system operates. It often refers to runtime speed and resource usage. | Statt die Performance zu optimieren, kritisiert der Senior-Entwickler nur den Code-Stil. |
| verschachtelten | When elements like loops or blocks are embedded inside one another, often making code harder to read or debug. | Ein Junior-Entwickler schreibt eine Funktion mit verschachtelten Schleifen. |
The same terms, as gaps
The second exercise puts them back into their own sentences.
- sind ein zentraler Bestandteil der Softwareentwicklung, doch selbst erfahrene Entwickler machen oft die gleichen Fehler.(Answer: Code Reviews)
- Ein Reviewer könnte einen Code als unleserlich kritisieren, obwohl die eigentliche in der Logik liegt.(Answer: Schwachstelle)
- Ohne definierte für Code Quality, Selbsttests oder Dokumentation werden Reviews chaotisch.(Answer: Richtlinien)
The scenario
A development team at a tech company is preparing for an important code review. Junior developers have implemented a new function that fails an automated test. The team lead notices that discussions are often derailed by subjective style critiques instead of focusing on technical flaws. The team needs to develop a structured approach for the review.
The role-play opens
Your counterpart
Ich sehe, du hast die neuen Funktionen implementiert, aber der automatisierte Test schlägt immer noch fehl. Kannst du mir erklären, wie du die technischen Abhängigkeiten geprüft hast?
The conversation continues from here in the app, and your counterpart pushes back.
Questions
- How long is a Software engineering journey?
- Fifteen weeks. It opens on “Code Reviews: Fallstricke vermeiden” and ends on “Code Reviews: Kulturelle Unterschiede”. Five learning days a week, five exercises a day, about fifteen minutes each.
- Is this exactly my niche?
- This page shows one example. Your own journey is built from a conversation about your actual work, so it comes out narrower and more specific than the sample here.
- What about listening and speaking?
- The exercises are text today. Audio Mode, which reads a whole learning day aloud and takes spoken answers, is coming.
Start this journey
Every new account gets one full week of Voice, free. You will know by Friday whether this is for you.