Ich bin Christian Schrödel. Entwickler, Technical Lead und Speaker.

Ich arbeite seit mehr als zehn Jahren in Softwareprojekten, aktuell als Technical Lead in der Automotive-Industrie. Zu Hause bin ich in Nürnberg; fachlich komme ich aus der Android-Entwicklung.

Angefangen hat es im Elektrotechnikstudium mit einem Wahlpflichtfach zur Android-App-Entwicklung. Aus „Das probiere ich mal aus“ wurden erst Android UI und UX und später die Frage, warum manche technische Entscheidung im echten Projekt funktioniert und andere nur auf dem Whiteboard gut aussieht.

Heute beschäftige ich mich viel mit Softwarearchitektur, fachlichen Anforderungen, Risiken und KI. Mich interessiert vor allem der Moment, in dem aus einer technisch möglichen Lösung eine Entscheidung wird, für die ein Team später geradestehen muss.

Wie ich in Projekten arbeite

Neue Technologien lerne ich am liebsten praktisch kennen. Ich probiere sie aus, suche ihre Grenzen und schaue, was davon im Projekt tatsächlich hilft. Ein gelungenes Demo-Projekt ist nett. Der Montagmorgen im Team ist meist der ehrlichere Test.

Bei Android hat mich von Anfang an gereizt, dass technische Entscheidungen sofort sichtbar werden. Eine Oberfläche kann funktionieren und sich trotzdem falsch anfühlen. Diese Nähe zwischen Code, Gestaltung und Nutzung prägt bis heute, wie ich auf Software schaue.

Guter Code ist wichtig. Er löst nur nicht automatisch das richtige Problem. Deshalb frage ich oft zuerst nach dem fachlichen Ziel, den Risiken und den Menschen, die mit einer Entscheidung weiterarbeiten müssen.

Was Technical Lead für mich im Alltag heißt

Ein Teil meiner Arbeit besteht aus Entwicklung und Architektur. Ein anderer Teil besteht darin, unklare Situationen so weit zu sortieren, dass ein Team wieder entscheiden kann.

Ich kenne dabei auch nicht immer sofort die richtige Antwort. Oft ist es hilfreicher, Unsicherheit offen zu benennen, Annahmen zu prüfen und einen nächsten Schritt zu wählen, den man später noch korrigieren kann.

Bei Reviews, Architekturfragen oder neuen Rollen versuche ich nicht nur eine Lösung vorzugeben. Mir ist lieber, jemand versteht, warum wir eine Entscheidung treffen, und kann beim nächsten Mal selbst besser abwägen. Das dauert manchmal länger als ein kurzes „Mach es so“, zahlt sich aber aus.

Mit KI gehe ich genauso um: erst ausprobieren, dann kritisch prüfen und erst danach in den Arbeitsalltag übernehmen. Plausibler Code ist noch kein guter Code. Das gilt übrigens auch ohne KI.

Warum ich darüber spreche und schreibe

Viele meiner Themen beginnen nicht mit einer Content-Idee, sondern mit einer Situation aus dem Entwickleralltag: ein Review, das sich im Kreis dreht, eine Entscheidung mit zu vielen Unbekannten oder ein Tool, das im Demo-Video deutlich kooperativer war als im Projekt.

Solche Beobachtungen halte ich fest. Wenn sich ein Muster wiederholt, mache ich daraus ein Video, einen Newsletter oder einen Vortrag. Manchmal bleibt es auch einfach eine offene Frage. Das ist in echten Projekten keine ungewöhnliche Endstation.

Ich teile dabei auch Dinge, die nicht funktioniert haben oder die ich heute anders einschätze. Fertige Antworten gibt es im Netz schon genug. Mir hilft mehr, wenn nachvollziehbar wird, wie jemand zu einer Entscheidung gekommen ist.

Wenn du in einem Projekt festhängst, kannst du mir über Frag Chris deine Frage schicken. Wenn ich sinnvoll helfen kann, antworte ich dir persönlich. Ob ich die Frage später anonymisiert aufgreifen darf, entscheidest du im Formular.

Mehr davon findest du auf YouTube und im Newsletter. Dort ist auch Platz für die Umwege, die in der Rückschau gern aus Geschichten verschwinden.