über mich
Ein bisschen dazu, wie ich arbeite.
Ich bin Entwickler aus der Schweiz. Fünf Jahre lang habe ich die Software gebaut, auf die sich Unternehmen wirklich verlassen: Websites für Kunden, interne Dashboards, Fachanwendungen und die Integrationen, die alles zusammenhalten, meist innerhalb einer Agentur. Ich habe viel gelernt und mit guten Leuten gearbeitet. Aber ich wollte näher an beide Enden der Arbeit: näher an die Person, für die ich baue, und näher an die schwierigen Teile der Umsetzung selbst. Also arbeite ich jetzt direkt als Freelancer, ohne Agentur dazwischen.
Die schwierigen Teile sind das, wofür ich meine eigene Zeit aufwende, und in den Demos kannst du sie sehen: weniger ein Portfolio bereits erledigter Kundenarbeit, mehr die Technik, in die ich am tiefsten gehe, von maschinellem Lernen auf Autograd-Ebene über verteilten Echtzeit-Zustand bis zu GPU-Grafik und -Simulation.
Jede davon läuft live und zeigt ihr eigenes Innenleben. Mir ist lieber, ich zeige dir, wie etwas funktioniert, als dass ich dich bitte, mir aufs Wort zu glauben.
// zusammenarbeit
Genau diese Direktheit ist der Punkt. Du sprichst mit der Person, die das Ding tatsächlich baut, nicht mit einem Account Manager, der hin und her vermittelt. Der Umfang bleibt ehrlich, weil ich es bin, der ausliefert, und wenn um 23 Uhr etwas kaputtgeht, repariert es die Person, die es geschrieben hat. Ich nehme weniger Kunden an, damit jeder genau das bekommt.
// wie ich arbeite
Hier ist, warum dir diese Tiefe nützt. Ich arbeite eine Ebene unter den meisten Webentwicklern: Autograd, GPU-Kernels, verteilter Zustand. Was du auch baust, es ist selten das Schwierigste, an dem ich je gearbeitet habe. Du brauchst keinen Transformer. Aber jemand, der einen von Hand herleiten kann, liest deine Codebasis schnell, findet die tragenden Teile und muss sich nicht durch die unbekannten Stellen führen lassen.
Drei Arten, zusammenzuarbeiten:
- Bauen. Ein definiertes Projekt, von Anfang bis Ende ausgeliefert. Ich verantworte es vom ersten Commit bis zum Ding, das in Produktion läuft.
- Laufend. Ein paar Stunden pro Woche auf Retainer. Ich bleibe die Person, die dein System kennt, damit Änderungen und Fixes von jemandem kommen, der den vollen Kontext schon hat, statt von einem Fremden, der sich kalt einliest.
- Rettung. Etwas Halbfertiges, Geerbtes oder in Flammen. Ich lese es, sage dir ehrlich, was zu retten ist, und flicke es entweder oder sage es klar.
Zum Preis: nicht der günstigste Tab, den du öffnest, aber ein gutes Stück weniger als eine Agentur, die die Arbeit sowieso an jemanden wie mich weitergegeben hätte. Du zahlst für die Umsetzung, nicht für die Schichten drumherum.
der name
Warum jDKOderso?
Meine Initialen sind J.D.K., was du, wenn du je einem Projekt beim Kompilieren zugesehen hast, auch als Java Development Kit erkennst. Das war nicht geplant. Das Universum hat einem Entwickler einfach die Initialen JDK in die Hand gedrückt und mich herausgefordert, keine Marke daraus zu machen. Oderso ist der Rest von mir, der Teil, der keine Runtime ist. Zusammengesetzt: jDKOderso. Rechtlich klar getrennt von Oracle, emotional benachbart zu einem guten Build-Log.
/* das obligatorische Mission Statement (es bin nur ich) */
Erstmal, um es klar zu sagen: jDKOderso ist keine Firma. Kein Team, kein Büro, kein "wir": es ist eine Person und ein Browser-Tab, den ich zuzumachen vergessen habe. Der Markenname lässt die Zeile nur ordentlicher aussehen.
Trotzdem ist jede persönliche Seite vertraglich verpflichtet, ein paar inspirierende Worte zu haben, also hier meine: Ich finde, jedes Semikolon ist ein Versprechen, ich lese lieber die Dokumentation, als irgendetwas zu disruptieren, und ich jage keine Einhörner. Ich profiliere sie.
Mission: nur behalten, was kompiliert. Vision: am Freitagnachmittag immer noch neugierig sein.
/* gezeichnet, ich, mit allen Hüten gleichzeitig */
erreich mich unter [email protected]