Bergmann Infotech

Interview: Entwickler für sich selbst

Home

>

Solutions Journal

>

Interview: Developer for yourself

Philipp Bondarev

Python developer

LinkedIn logo – part of Bergmann Infotech's professional networking.

Manchmal beginnt der Weg in die IT nicht mit einem Team oder erfahrenen Mentoren, sondern mit einsamen Versuchen herauszufinden, warum das eigene Programm einfach nicht läuft. So begann auch der Weg von Philipp, einem Python-Entwickler – er brachte sich den Beruf vollständig selbst bei. Heute ist er für die Architektur komplexer Systeme verantwortlich. Dies ist seine Geschichte über Selbstbildung, Disziplin und die Philosophie der „Notwendigkeit und Suffizienz“

— Wie begann dein Weg in die Entwicklung?

Viele Menschen haben das Glück, ihre Karriere „unter den Fittichen“ erfahrener Kolleg:innen zu beginnen. Ich hingegen musste alles selbst herausfinden – was aber nichts Außergewöhnliches ist.

Mein Weg fühlte sich an wie ein Tasten im Dunkeln: ein ständiger Kampf mit dem Gefühl, in einem Strom neuer Informationen zu ertrinken. Man schlägt sinnbildlich mit dem Kopf gegen das Eis, um zu begreifen, was man gerade gelesen hat. Jeder Schritt und jede Codezeile lasten wie eine Verantwortung auf den Schultern.
Mit der Zeit wurde mir klar, dass es völlig normal ist, Neues nicht beim ersten Versuch zu verstehen. Erst wenn man eine kritische Masse an Wissen sammelt, beginnen sich ganz natürlich Parallelen zu bereits bekannten Konzepten zu bilden.

— Wie bist du zur Programmierung gekommen?

Jeder betritt die Welt der Entwicklung auf seine eigene Weise. Bei mir war der Auslöser die Ineffizienz der Prozesse in dem Konstruktionsbüro, in dem ich sieben Jahre lang gearbeitet hatte. Es gab dort keine Programmierer, also bewaffnete ich mich mit Artikeln und Büchern.

Ich begann damit, interne Anwendungen zu entwickeln, die sich als sehr nützlich für unsere Abteilung erwiesen. Sie wurden gebraucht und haben mir wirklich Spaß gemacht — was dazu führte, dass ich meinen Fokus schnell von der eigentlichen Arbeit im Büro auf das Lösen technischer Aufgaben durch Software verlagerte.
Und ich muss sagen: Die Erfahrung aus dem Konstruktionsbüro hat mir später in der Entwicklung sehr geholfen.

— Was hat sich verändert, als du zum ersten Mal an einem groß angelegten System gearbeitet hast?

Drei Jahre später bekam ich die Möglichkeit, an einem deutlich größeren System zu arbeiten. Für einen Moment hoffte ich schüchtern, endlich mit erfahreneren Kolleg:innen zusammenzuarbeiten — mir fehlte wirklich die Möglichkeit, alltägliche Entwicklerprobleme mit jemandem zu besprechen.

Doch… ich war erneut der einzige Backend-Entwickler und gleichzeitig derjenige, der die Aufgaben eines Systemarchitekten übernehmen musste. Alle Entscheidungen lagen auf meinen Schultern, und aufgrund einer NDA konnte ich die meisten Dinge nicht einmal in öffentlichen Chats diskutieren.

— Wie bist du damit umgegangen, keine Kolleg:innen zu haben, die du um Rat fragen konntest?

Manchmal kann man sehr spezifische Fragen in Communities diskutieren, aber wie gesagt, auch das ist durch die NDA eingeschränkt. Also treffe ich die meisten Entscheidungen selbst.
Was mir hilft, ist ein Prinzip, das ich noch aus meiner Zeit als Ingenieur kenne – das Prinzip der Notwendigkeit und Suffizienz. Alles Weitere wächst darum herum wie ein Kristall um einen Kristallisationskeim.

— Wie zeigt sich dieses Prinzip in deiner täglichen Arbeit?

In fünf Jahren an diesem Projekt bin ich durch viele Phasen gegangen – von Begeisterung und der schnellen Übernahme neuer Konzepte bis hin zum Nachgeben gegenüber Nutzerwünschen (hier sind die Nutzer andere Entwickler und Manager), selbst wenn das den Code verschlechtert hat. Ich schwöre, manchmal hatte ich fast körperliche Schmerzen, wenn ich mir ansah, was da unter meiner „Feder“ entstanden war.
Aber mit der Zeit hat sich alles stabilisiert.

Braucht jemand einen Endpoint „bis gestern“? Gut, machen wir.
Sie wollen die Tests verschieben und direkt die Autorisierung implementieren? Ich halte das nicht für eine gute Idee, aber ich überarbeite die Anforderungen eben und nutze ABAC, obwohl ACL völlig ausreichen würde…

— Was bedeutet es für dich, solo zu arbeiten?

Allein zu arbeiten bedeutet, die Balance zu finden zwischen einer „idealen“ Lösung und einer „funktionierenden“.
In einem Team wird man rechtzeitig eingebremst.
Allein kann man sich dagegen leicht verlieren und unzählige Abstraktionsschichten sowie “Adapter-Manager-Gateways” bauen – und am Ende läuft ein kompletter k8s-Cluster auf einer einzigen Maschine.

Wahre Meisterschaft besteht darin, problematische Entwicklungspfade frühzeitig zu erkennen und sie mit minimalem Aufwand zu vermeiden.

— Was hilft dir, Overengineering zu vermeiden und rechtzeitig aufzuhören?

Ich komme immer wieder zu der Frage zurück: „Ist das, was ich jetzt tun möchte, wirklich notwendig? Und ist das, was ich bereits getan habe, ausreichend?“

Frag dich selbst: Wie oft hast du Zeit investiert, um zwei Abstraktionen zu trennen, nur damit man eine davon später austauschen kann? Wie oft ändern sich die gewählten Technologien tatsächlich?
Warum ein universelles Repository bauen, wenn das ganze Projekt nur eine einzige Datenquelle verwendet?
Meistens lautet die Antwort auf all diese Fragen: nein – oder etwas, das dem sehr nahekommt.

— Ist Einfachheit ein Kompromiss oder Reife?

Ich verstehe das Bedürfnis nach Eleganz und den Drang, jeden möglichen Fall abzufedern. Aber sehr oft ist das schlicht unnötig.

Gleichzeitig plädiere ich nicht dafür, grundlegende Prinzipien über Bord zu werfen – Generationen von Entwickler:innen haben sie unter Mühen und nächtlichen Tränen erarbeitet. Der Preis war zu hoch, um sie einfach zu ignorieren.
Wichtig ist, die feine Linie zwischen dem Notwendigen und dem Ausreichenden zu halten.

— Und wenn du deinen gesamten Weg mit einem einzigen Rat zusammenfassen müsstest – welcher wäre das?

Lass die Begeisterung, die du zu Beginn hattest, nicht verblassen.
Die Neugier auf alles Neue sollte dich jeden Morgen aus dem Bett ziehen und dich auf die Jagd nach Wissen schicken – um den natürlichen Hunger eines denkenden Menschen zu stillen.

Programmieren ist ein einzigartiges Handwerk, das es dir ermöglicht, die strenge Logik des Ingenieurwesens mit der brennenden Inspiration kreativer Arbeit zu verbinden.

We take care of the search for a solution for you.

Inform us about your needs. We will call you for a first chat after receiving your request.

Your data has been sent successfully.

Your data has been sent successfully.