Nach längerer Pause habe ich mein Portfolio-Projekt einem kleinen Re-Audit unterzogen.
Eigentlich wollte ich nur ein paar Dokumentationslücken schließen und wieder in den Code einsteigen. Dabei habe ich festgestellt, dass sich meine ursprüngliche Idee inzwischen deutlich verändert hat.
💡 Die ursprüngliche Idee
Als ich das Projekt begonnen habe, wollte ich hauptsächlich die Ergebnisse verschiedener Udemy-Kurse veröffentlichen.
Die Idee war einfach:
- Kurs durcharbeiten
- Projekt umsetzen
- Im Portfolio präsentieren
Auf den ersten Blick klingt das sinnvoll. Schließlich entstehen dabei funktionierende Anwendungen und man lernt eine Menge.
Mit etwas Abstand habe ich jedoch gemerkt, dass diese Projekte nicht unbedingt zeigen, was ich eigentlich zeigen möchte.
🤔 Warum ich Kursprojekte nicht mehr ins Portfolio aufnehmen möchte
Kursprojekte haben für mich mehrere Nachteile.
Zum einen stammen die grundlegenden Ideen meist vom Kursautor.
Architektur, Datenmodell und viele Entscheidungen wurden bereits getroffen. Das Ergebnis zeigt zwar, dass ich die Inhalte verstanden habe, aber nicht unbedingt, wie ich selbst Probleme analysiere und löse.
Zum anderen möchte ich meinen Quellcode öffentlich verfügbar machen.
Bei eigenen Projekten ist das unkompliziert. Bei Kursprojekten stellt sich dagegen schnell die Frage:
Darf ich das überhaupt veröffentlichen?
Selbst wenn die Antwort häufig „ja“ lautet, möchte ich mich mit solchen Unsicherheiten gar nicht erst beschäftigen.
Deshalb habe ich entschieden:
📌 Das Portfolio soll künftig hauptsächlich aus eigenen Projekten oder stark weiterentwickelten Varianten bestehen.
📚 Die Kurse verschwinden trotzdem nicht
Die investierte Zeit war natürlich nicht umsonst.
Kurse, Bücher, Videos und Dokumentationen sind weiterhin ein wichtiger Teil meines Lernprozesses.
Deshalb wollte ich diese Inhalte nicht einfach ausblenden.
Stattdessen habe ich angefangen, die Website anders zu betrachten:
Nicht nur als Portfolio, sondern auch als persönliches Wissensmanagement-System.
🔄 Zwischen Lernen und Anwenden
Ein weiterer Grund für die Neuausrichtung war eine Erkenntnis, die wahrscheinlich viele Entwickler kennen.
Über die Jahre habe ich zahlreiche Kurse, Videos und Tutorials konsumiert. Das Problem dabei ist, dass Lernen und Verstehen nicht automatisch bedeuten, dass man etwas eigenständig anwenden kann.
Oft entsteht das Gefühl, produktiv zu sein:
- noch ein Kurs
- noch ein Tutorial
- noch ein neues Framework
Tatsächlich bewegt man sich dabei aber häufig innerhalb eines vorgegebenen Rahmens.
Man folgt den Entscheidungen anderer und löst Probleme, die bereits für einen vorbereitet wurden.
Mir wurde irgendwann klar, dass ich mehr Zeit damit verbringen möchte, eigene Probleme zu lösen und eigene Entscheidungen zu treffen.
Das bedeutet nicht, dass Tutorials wertlos sind. Im Gegenteil: Sie sind oft ein hervorragender Einstieg in ein neues Thema.
Der eigentliche Lernprozess beginnt für mich aber erst danach:
- Anforderungen selbst formulieren
- Architekturentscheidungen treffen
- Fehler machen
- Lösungen überarbeiten
- Kompromisse finden
Genau deshalb möchte ich künftig stärker auf eigene Projekte setzen und Kurse eher als Wissensquelle dokumentieren als als fertige Portfolio-Arbeiten präsentieren.
🧠 Das eigentliche Problem
Je länger man lernt, desto mehr Quellen sammeln sich an.
Irgendwann stellt sich die Frage:
- Wo habe ich das gelernt?
- Welcher Kurs hat mich auf diese Idee gebracht?
- Welche Projekte basieren darauf?
- Habe ich darüber schon einmal geschrieben?
Mit klassischen Blogartikeln wird das schnell unübersichtlich.
Deshalb habe ich eine eigene Inhaltsstruktur aufgebaut.
🏗️ Mein Inhaltsmodell
Die wichtigsten Inhaltstypen sind:
👨🏫 Instructor
Personen, von denen Wissen stammt.
Beispiele:
- Kursleiter
- Autoren
- YouTuber
- Entwickler
📖 Source
Lernquellen wie:
- Udemy-Kurse
- Bücher
- Dokumentationen
- Videos
💻 Project
Eigene Projekte, Experimente und Umsetzungen.
📝 Post
Normale Blogartikel.
Dort dokumentiere ich Erfahrungen, Erkenntnisse und Entwicklungsschritte.
🏷️ Warum zusätzlich Taxonomien existieren
Die Custom Post Types bilden nur die Beziehungen zwischen den Inhalten ab.
Für die eigentliche Suche und Filterung nutze ich zusätzlich Taxonomien.
Projektart
Beispiele:
- Udemy-Kurs
- Eigenes Projekt
- Kundenprojekt
- Proof of Concept
Damit lassen sich Inhalte nach ihrem Charakter unterscheiden.
Technologie
Beispiele:
- React
- Bootstrap
- Tailwind
- Docker
- WordPress
Damit kann ich Inhalte technologieübergreifend verknüpfen.
Kategorie
Beispiele:
- Frontend
- Backend
- DevOps
- Datenbanken
Diese Taxonomie beschreibt Themengebiete.
Tags
Beispiele:
- PHP
- JavaScript
- WordPress
- MySQL
Tags dienen als zusätzliche Schlagworte.
🔎 Warum das später nützlich wird
Langfristig möchte ich Inhalte gezielt filtern können.
Zum Beispiel:
Zeige mir alle Projekte zum Thema PHP und Datenbanken.
Oder:
Welche Projekte basieren auf einem bestimmten Kurs?
Oder:
Welche Blogartikel habe ich bereits über React geschrieben?
Die Struktur dient also nicht nur den Besuchern der Website, sondern auch mir selbst.
Je mehr Inhalte entstehen, desto wichtiger wird es, Wissen wiederzufinden.
🧹 Auch technische Entscheidungen wurden hinterfragt
Im Zuge des Audits habe ich außerdem einige ältere Architekturideen überprüft.
Ein Beispiel war eine geplante globale Navigation für eine WordPress-Multisite-Installation.
Dafür hatte ich bereits:
- eigene Datenstrukturen
- Service-Klassen
- Caching über Transients
entwickelt.
Nach der erneuten Analyse wurde jedoch klar:
Ich habe aktuell gar kein Problem, das diese Komplexität rechtfertigt.
Die Funktion wurde deshalb archiviert.
Nicht weil die Idee schlecht war, sondern weil sie momentan keine aktive Anforderung erfüllt.
🎯 Mein Fazit
Das Re-Audit hat mir gezeigt, dass die eigentliche Stärke des Projekts nicht in der technischen Infrastruktur liegt.
Interessant sind nicht die Menüs oder die Caching-Strategie.
Interessant ist die Frage:
Wie kann ich Wissen, Lernquellen, Projekte und Erfahrungen langfristig miteinander verknüpfen?
Genau darauf möchte ich mich in den nächsten Entwicklungsschritten konzentrieren.
Das Projekt soll nicht nur zeigen, was ich gebaut habe.
Es soll auch dokumentieren:
- wie ich gelernt habe,
- woher bestimmte Ideen stammen,
- welche Technologien ich eingesetzt habe,
- und wie verschiedene Projekte miteinander zusammenhängen.
Am Ende entsteht dadurch hoffentlich nicht nur ein Portfolio, sondern eine durchsuchbare Wissensbasis über meinen eigenen Lern- und Entwicklungsweg.
Schreibe einen Kommentar