// Softwarearchitekt / Consultant / Maker
Erst verstehen,
dann bauen.
Gute Systeme brauchen oft weniger, als man denkt. Nicht alles muss skalieren, aber falls doch, kann ich helfen.
Nur weil man es bauen kann
In der Softwareentwicklung lässt sich heute fast alles bauen. Die Werkzeuge sind so gut, dass das Wie selten das Problem ist. Und wir Entwickler bauen gern das, was glänzt. Das liegt nicht nur an uns: Eine Lösung gilt heute oft als umso besser, je angesagter das Schlagwort ist, das draufsteht. Kubernetes, Microservices und Event Sourcing sind für sich genommen großartig und lösen echte Probleme. Nur weil man einen Hammer hat, ist aber noch lange nicht jedes Problem ein Nagel. Für jedes Problem das passende Werkzeug, und manches muss man auch gar nicht reparieren.
Die eigentliche Frage ist also nicht, ob man etwas bauen kann, sondern ob es sich lohnt. Schön ist vieles. Ob es seinen Preis wert ist, steht auf einem anderen Blatt.
Das beste Beispiel dafür, das ich habe, ist diese Seite.
- Commits
- 160
- Zeilen Code
- 10.666
- Tage vom ersten zum letzten Commit
- 15
- Tage seit dem letzten Commit
- 0
Eine Visitenkarte im Netz hätte gereicht: wer ich bin, was ich mache, wie man mich erreicht. Eine Seite, ein Nachmittag. Stattdessen gibt es jetzt ein Terminal mit 32 Befehlen (Tendenz steigend). Der Lebenslauf ist erst nach einem kleinen Rätsel im Terminal zu sehen, die Skills hängen in einem interaktiven Graphen und ein Capture the Flag gibt es auch noch…
Braucht das jemand? Nein. Gebaut hab ich es trotzdem, weil ich es kann und es keiner bezahlen muss. Einen echten Zweck hat die Seite kaum, außer dass ich ein bisschen was dabei gelernt habe. Und natürlich das Wichtigste: ES GLÄNZT!
Privat war das eine gute Entscheidung. Hätte mir ein Kunde dafür ein Budget gegeben, wäre es eine ziemlich schlechte gewesen, und das hätte ich ihm auch so gesagt. Ich bin kein Jasager, mir ist die eigentliche Sache wichtiger als das Budget. Coole Sachen will ich natürlich auch machen, aber da, wo sie etwas bringen, und nicht nur, weil sie jemand bezahlt.
In Kundenprojekten passiert genau das ständig, nur mit fremdem Geld. Gebaut wird, was technisch geht oder was sich gut anfühlt, und ob es das eigentliche Problem löst, fragt keiner oder erst, wenn es schon steht. Deshalb will ich erst wissen, was wirklich gebraucht wird, bevor ich anfange. Oft ist das kleiner als gedacht. Manchmal auch größer, dann weiß man aber wenigstens, warum. Erst verstehen, dann bauen.
Die Seite hier bleibt trotzdem so.
Weitere Projekte
Es gibt auch noch weitere Projekte, die ich neben der Arbeit baue. Das reicht von .NET-Bibliotheken über diverse 3D-Druck- und Laserprojekte bis zum Dartomat, an dem ich seit 2013 immer wieder schraube und verbessere. Und ab und zu auch ein Open-Source-Beitrag wie bei HomeRacker, wo ich die Website und den Konfigurator beigesteuert hab.
Capture the Flag
Weil ich es oben schon erwähnt habe: Auf dieser Seite steckt ein kleines
Capture the Flag. Öffne das Terminal mit / oder Strg + K und tippe ctf,
um es zu starten.
Du weißt nicht, was das ist? Starte es einfach, es wird dir erklärt. Falls du deine Zeit lieber anders totschlagen willst, gibt es in meiner Projektliste auch das ein oder andere Spiel.
Das Spiel läuft im Terminal, und das gibt es erst ab Tablet-Breite.





