Eigentlich sollte ich zehn Projekte bewerten. Am Ende waren es 29.
Als Teil des Serverpod Developer Expert Programms bin ich gerade in der Jury von „Build Something Real“, dem aktuellen Serverpod-Hackathon. Die Einreichungsfrist war am 14. Oktober, die Gewinner sollen am 22. Oktober bekannt gegeben werden.
29 Projekte geben einem reichlich Gelegenheit, über gute Einreichungen nachzudenken. Meine wichtigste Erkenntnis richtet sich an jeden, der selbst an einem Hackathon teilnimmt: Versetzt euch vor der Abgabe in die Position des Menschen, der euer Projekt bewerten soll.
Dieser Mensch sieht eure Anwendung zum ersten Mal. Er kennt weder eure Idee noch eure Daten oder Abläufe. Und möglicherweise muss er deutlich mehr Projekte bewerten, als ursprünglich geplant war.
Macht es ihm so leicht wie möglich, euer Projekt tatsächlich zu benutzen.
Jede Minute Einrichtung fehlt beim Ausprobieren
Wenn ich erst einen Account anlegen, eine E-Mail bestätigen und anschließend eine leere Anwendung mit Daten befüllen muss, vergeht Zeit. In dieser Zeit habe ich noch keine eurer eigentlichen Funktionen ausprobiert.
Das gilt auch für die lokale Einrichtung. Ein Repository mit Startanleitung ist hilfreich. Eine direkt erreichbare Demo im Browser ist für mich als Juror aber der deutlich bessere Einstieg, sofern das Projekt das ermöglicht.
Der Weg sollte möglichst kurz sein: Demo öffnen, mit einem vorbereiteten Zugang einloggen und einen sinnvollen Ablauf ausprobieren. Die passenden Beispieldaten sind schon vorhanden. Eine kurze Beschreibung erklärt, was ich tun kann und woran ich den Nutzen erkenne.
Bei einer Anwendung zur Aufgabenplanung möchte ich beispielsweise sehen können, wie sie mit Aufgaben umgeht. Dafür sollte ich nicht erst selbst ein Projekt erstellen, Aufgaben eintippen und weitere Nutzer anlegen müssen. Bereitet eine Situation vor, in der eure Idee sichtbar wird.
Je weniger Zeit die Einrichtung braucht, desto mehr Zeit bleibt, um die Stärken eures Projekts zu entdecken.
Prüft den Zugang zum Repository
Bei einigen Einreichungen war das Repository privat und für mich nicht zugänglich. Damit konnte ich den Code nicht ansehen.
Ob ein Repository öffentlich sein muss oder gezielt für die Jury freigegeben werden kann, hängt von den jeweiligen Teilnahmebedingungen ab. Entscheidend ist, dass die vorgesehenen Prüfer tatsächlich Zugriff haben.
Kontrolliert deshalb den Link, den ihr einreicht, und die dazugehörigen Berechtigungen. Euer eigener Zugriff sagt noch nichts darüber aus, ob die Jury denselben Inhalt sehen kann.
Ein Demo-Zugang hilft nur, wenn der Login funktioniert
Es gab auch Demos, bei denen der Einstieg durchdacht wirkte. Ein Demo-Nutzer war vorbereitet, alles schien bereit. Dann habe ich auf Login geklickt und bekam eine Fehlermeldung. An dieser Stelle war Schluss.
Was dahinter vielleicht alles funktioniert hätte, konnte ich über die Demo nicht herausfinden. Eine Beschreibung oder ein Video kann zusätzliche Einblicke geben. Den eigenen Test des versprochenen Ablaufs ersetzt das für mich nicht.
Testet deshalb vor der Abgabe genau die Version, die ihr verlinkt. Öffnet sie in einem frischen Browserfenster ohne bestehende Sitzung. Verwendet den angegebenen Demo-Zugang und geht den vorgesehenen Ablauf bis zum Ergebnis durch.
Funktioniert der Login? Sind die Beispieldaten vorhanden? Erreicht die Anwendung ihr Backend? Funktioniert auch der nächste Schritt nach dem ersten Bildschirm?
Ein erfolgreicher Test auf dem eigenen Rechner reicht dafür nicht. Die eingereichte Demo muss für einen Menschen funktionieren, der eure Entwicklungsumgebung nicht hat.
Gestaltung gehört zur Qualität
Bei einem Hackathon erwarte ich kein fertiges Produkt mit einem bis ins letzte Detail ausgearbeiteten Designsystem. Aber ich erwarte eine Oberfläche, die verständlich ist und bei der jemand auf die Gestaltung geachtet hat.
Das ist auch für die Bewertung relevant. Wenn ich nicht erkenne, was anklickbar ist, Beschriftungen kaum lesen kann oder den nächsten Schritt suchen muss, erschwert mir das den Zugang zur Funktion.
Die veröffentlichten Kriterien dieses Hackathons berücksichtigen ausdrücklich Funktionalität sowie handwerkliche Qualität und technische Kreativität. KI-gestützte Entwicklung ist ausdrücklich willkommen. Für mich gehört dazu auch, sich bei den eigenen Schwächen gezielt Unterstützung zu holen.
Wer mit einem KI-Agenten baut und wenig Erfahrung mit Gestaltung hat, kann ihm passende Design-Skills, gute Referenzen und klare Vorgaben mitgeben. Damit lässt sich gezielter an Hierarchie, Abständen, Lesbarkeit und konsistenten Bedienelementen arbeiten.
Ein Skill allein garantiert kein gutes Ergebnis. Anschauen und prüfen muss man die Oberfläche weiterhin selbst. Aber eine offensichtlich nachlässige Gestaltung akzeptiere ich unter diesen Voraussetzungen nicht einfach als unvermeidbar.
Was die Teilnahme auch ohne Gewinn wertvoll macht
Für mich gibt es mehrere gute Gründe, an einem Hackathon teilzunehmen: Spaß am Bauen haben. Etwas Neues lernen. Sich in einem festen Zeitrahmen ein Ziel setzen und üben, es zu erreichen. Vielleicht trifft einer dieser Gründe zu, vielleicht alle. Und vielleicht gewinnt man am Ende auch noch.
Man muss dafür nicht alles schaffen, was man sich vorgenommen hat. Auch ein teilweise erreichtes Ziel kann die Teilnahme lohnend machen. Wer an einer schwierigen Aufgabe arbeitet und dabei etwas lernt, hat seine Zeit sinnvoll genutzt.
Die Demo zeigt, ob ihr an den ersten Nutzer gedacht habt
Eine schlecht vorbereitete Demo macht es mir schwerer, Vertrauen in ein Projekt zu entwickeln. Eine sorgfältig vorbereitete Demo zeigt mir dagegen, dass jemand über die reine Implementierung hinausgedacht hat: Wie erlebt ein anderer Mensch meine Anwendung zum ersten Mal?
Das ist Teil der Arbeit am Produkt. Ein vorbereiteter Zugang, sinnvolle Daten und ein funktionierender Ablauf machen die geleistete Arbeit überhaupt erst erlebbar.
Wenn ich selbst eine Einreichung vorbereiten würde, wären das meine letzten fünf Prüfungen:
- Ist die Demo über den eingereichten Link direkt erreichbar?
- Funktioniert der vorbereitete Zugang ohne meine bestehende Sitzung?
- Sind sinnvolle Beispieldaten vorhanden, mit denen sich der Kernablauf ausprobieren lässt?
- Ist das Repository für die vorgesehenen Prüfer zugänglich?
- Kann ein Fremder erkennen, was er tun soll, und den Ablauf bis zum Ergebnis durchspielen?
Plant dafür bewusst Zeit ein. Auch wenn es verlockend ist, bis zur letzten Minute noch eine Funktion einzubauen.
Nach 29 Projekten ist mein wichtigster Rat: Gebt der Jury möglichst viel Gelegenheit, eure Arbeit auszuprobieren. Eine gute Demo sorgt dafür, dass diese Gelegenheit genutzt werden kann.