Arbeitsplatz Bild ECO-Soft GmbH

Bastian Schmidt, Software Developer bei ECO-Soft

Description

Bastian Schmidt von ECO-Soft redet in seinem Interview von seinem Werdegang als Developer – von den frühen Anfängen, bis hin zur aktuellen Arbeit als Developer – und welche Tipps er für Anfänger hat.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In „Bastian Schmidt, Software Developer bei ECO-Soft“ schildert Speaker Bastian Schmidt seinen Weg vom jugendlichen Gaming- und Scripting-Interesse über frühe Nebenprojekte zum Start als Web‑Full‑Stack‑Developer. Ein neuer Kunde brachte ihn unerwartet in BI-Themen, wo es um Datenquellen, Umstrukturierung, das Gewinnen von Informationen und die nutzerfreundliche Aufbereitung auf der Oberfläche geht – eine willkommene Abwechslung zum reinen Programmieren. Er hebt das kleine, junge Team mit kurzen Kommunikationswegen bei ECO-Soft GmbH hervor und rät Einsteigern, ein Interessensgebiet zu wählen, Ressourcen zu sammeln und mit kleinen Projekten Referenzen aufzubauen.

Vom Gaming zur Datenkompetenz: Der Weg von Bastian Schmidt (Software Developer bei ECO-Soft GmbH) vom Full‑Stack in die BI – und was Entwickler daraus lernen können

Einleitung: Eine Dev-Story, die bei den Grundlagen beginnt – und bei Wirkung aufhört

Wir bei DevJobs.at haben die Session „Bastian Schmidt, Software Developer bei ECO-Soft“ mit besonderer Aufmerksamkeit verfolgt. Der Speaker, Bastian Schmidt, zeichnet in wenigen Minuten eine erstaunlich dichte Laufbahn nach: von ersten Berührungspunkten in der Jugend über einen Einstieg als Web-Fullstack-Developer bis hin zum Sprung in Business Intelligence (BI) – inklusive Einblicken in Teamkultur, Lernwege und Arbeitsweise. Es ist eine Geschichte darüber, wie Neugier auf Daten und kurze Entscheidungswege in einem kleinen Team Ideen schnell in reale Produkte verwandeln.

Schon in seinem ersten Satz steckt der Kern seiner Motivation:

„Als Jugendlicher halt mit dem Computer ein bisschen im Gaming-Bereich … Berührungspunkte mit Programmieren, mit Scripting … das war da immer ein bisschen mein Interesse … das wird mein Beruf.“

Was folgt, ist ein komprimierter, praktischer Leitfaden für Entwicklerinnen und Entwickler, die ihren eigenen Weg finden oder den nächsten Karriereschritt prüfen wollen. Ohne Buzzwords, ohne Show – dafür mit sehr konkreten Eckpunkten: kleine Projekte, Daten verstehen, Nutzersicht ernst nehmen und zusammen schneller entscheiden.

Frühe Neugier: Gaming, Scripting und die ersten Community-Projekte

Bastian beschreibt einen Start, den viele Entwickler kennen: die spielerische Neugier am Computer. Aus dem „Gaming-Bereich“ wächst das Interesse für Scripting und kleinere Projekte. Wichtig ist nicht, womit man anfängt – wichtig ist, dass man anfängt.

„… habe dann eben auch in meiner Jugend immer ein bisschen kleinere Projekte programmiert, mich mit so Communities auseinandergesetzt … und habe dann mit 18 im Prinzip schon gewusst, ich würde gerne in die Richtung.“

Aus unserer Sicht stecken darin drei bleibende Lektionen:

  • Einstieg über Spaß: Der eigene Antrieb entsteht oft dort, wo Neugier und Spieltrieb aufeinandertreffen. Gaming wird zum Katalysator für Scripting.
  • Communities als Lernverstärker: Austauschräume helfen, schneller zu verstehen, was möglich ist – und geben Orientierung, wann ein Projekt „gut genug“ ist.
  • Frühe Selbstvergewisserung: „Mit 18 gewusst“ ist nicht Selbstgefälligkeit, sondern das Ergebnis von Ausprobieren und Rückkopplung. Wer macht, bekommt Klarheit.

Praxisnaher Tipp aus Bastians Startphase

Wer noch auf der Suche ist: Knüpfe an etwas an, das du ohnehin tust (z. B. ein Spiel modden, ein Tool für Freunde schreiben). Das senkt Einstiegshürden und erhöht die Chance, dranzubleiben.

Der Einstieg als Web-Fullstack-Developer: Breite vor Tiefe

Bastian begann „als ganz normaler Web-Fullstack-Developer“ und bekam „Front, Backends, Datenbanken“ mit. Das klingt unspektakulär, ist aber ein fruchtbarer Boden: Full-Stack vermittelt End-to-End-Verständnis. Wer weiß, wie Frontend-Entscheidungen Datenbankabfragen beeinflussen – und umgekehrt –, agiert souveräner, wenn neue Anforderungen kommen.

„Angefangen habe ich als ganz normaler Web-Fullstack-Developer und habe dort eben Front, Backends, Datenbanken mitgekriegt – alles.“

Diese Breite erleichtert zwei Dinge:

  • Kontextwechsel: Man kann dort mitreden, wo die eigentliche Engstelle ist – sei es bei Daten, Logik oder Oberfläche.
  • Brückenschläge: Wenn später ein BI-Fokus dazukommt, ist der Sprung kleiner, weil Datenmodell, APIs und Darstellung nicht mehr getrennte Welten sind.

Unerwarteter Sprung in Richtung Business Intelligence: Wenn Daten zur eigentlichen Story werden

Der Wendepunkt kam über einen neuen Kunden: Das Team sollte BI-Lösungen anbieten. Bastian wurde – nach eigenen Worten – „recht unerfahren reingeschmissen“. Entscheidend ist, was danach passiert: Statt zu verharren, entsteht Faszination für die Datenseite.

„… in dieses Thema bin ich dann eigentlich auch recht unerfahren reingeschmissen worden, aber es war ein sehr interessantes Thema, weil da geht es viel mehr eben um die Datenseite … Daten umstrukturieren … wo kriege ich verschiedene Daten her, wie kann ich mir da jetzt Informationen rausziehen … und eben auch, wie sorge ich das dann auf der Oberfläche dem User an …“

Damit benennt er vier Aufgaben, die BI von klassischer Anwendungsentwicklung unterscheiden – und zugleich verbinden:

  1. Datenumstrukturierung: Rohdaten sind selten berichtsreif. Sie müssen in Strukturen überführt werden, die Fragen beantworten können.
  2. Datenquellen verbinden: „Wo kriege ich verschiedene Daten her?“ ist nicht nur technisch, sondern auch fachlich. Welche Quelle trägt zur Antwort bei?
  3. Informationen extrahieren: Aus Daten Informationen machen – also Kennzahlen, Trends, Zusammenhänge – erfordert Auswahl und Verdichtung.
  4. Oberflächen gestalten: Nichts davon zählt, wenn Nutzer die Erkenntnisse nicht verstehen oder nutzen. BI bleibt Arbeit „am Menschen“.

Bastian bringt es auf den Punkt: Wer „nicht nur programmieren will, sondern auch ein bisschen Abwechslung“ sucht, findet in BI ein reiches Feld.

Warum gerade dieser Wechsel Sinn ergibt

Aus unserer redaktionellen Sicht fügt sich Bastians Weg logisch: Full-Stack schärft das Ende-zu-Ende-Denken; BI vertieft das Verständnis für Daten als Produkt. In BI lernt man, Fragen zu stellen („Was will der User wirklich wissen?“) – und Antworten in Modelle, Aggregationen und Visualisierungen zu gießen. Das ist weniger „Feature bauen“ als „Erkenntnis liefern“.

Wer diesen Wechsel in Betracht zieht, sollte zwei Dinge mitbringen – genau das, was Bastian implizit zeigt:

  • Offenheit, unerfahren zu starten – und sich hineinzudenken.
  • Freude daran, Technik und Nutzerperspektive zu verbinden.

Teamkultur: Klein, jung, direkt – und dadurch schnell

Bastian betont den Charakter seines Teams mehrfach. Die Stichworte: „kleines junges Team“, „man kann mit jedem reden“, „Hilfe holen“, „Kommunikationswege sehr kurz“. Vor allem aber: Von der Idee zum Ergebnis ist es nicht weit.

„… kann dann auch wirklich sozusagen von der Idee zum Endprodukt sehr, sehr leicht und sehr schnell gehen und damit auch recht gut Ideen iterieren und ausprobieren …“

Diese Beschreibung ist mehr als nett: Sie ist ein Produktivitätsversprechen. Kurze Wege erlauben schnelle Schleifen:

  • Idee – Rücksprache – Umsetzung – Feedback – Iteration.
  • Hypothesen zügig prüfen statt monatelang planen.
  • Verantwortung dort, wo die Information ist – beim Developer, der nah am Problem arbeitet.

Was wir daraus ableiten

  • Kommunikationsdesign ist Architektur. Kurze Wege sind kein Zufall, sondern gelebte Praxis.
  • Mentale Sicherheit („man kann … Hilfe holen“) ist Beschleuniger. Wer nicht blockiert bleibt, liefert.
  • Führung erreichbar zu haben („einfach mit dem Chef reden“) setzt Ideen frei – und filtert früh, was Sinn macht.

Die Essenz von Bastians Ratschlag: Fokussieren, Ressourcen bündeln, kleine Produkte bauen

Gegen Ende der Session gibt Bastian eine kompakte Handlungsanleitung – für Einsteiger ebenso wie für alle, die einen Richtungswechsel erwägen:

„… einfach einmal ein Thema sucht, bei dem man interessiert ist … Ressourcen zusammensammelt, sich … informiert … und dann … kleinere Projekte … baut … zum Beispiel im Webdevelopment … eine kleine Website innerhalb von einer Woche oder einem Monat … die kann genau das … und dann baut man immer weiter … irgendwann … ein fertiges Produkt … Referenz … und da merkt man dann auch einfach, ist das wirklich was für mich … und man lernt natürlich auch dabei was.“

Wir hören darin sechs Schritte:

  1. Thema wählen: Web, Game, Sprache – egal, Hauptsache interessiert.
  2. Ressourcen kuratieren: Wenige, gute Quellen statt viele Tabs.
  3. Kleines Ziel definieren: „Die kann genau das.“ Ein Satz muss reichen, um Scope zu beschreiben.
  4. Zeitboxen setzen: „Woche oder Monat“ – genug, um zu liefern; kurz genug, um zu lernen.
  5. Iterativ erweitern: Aus dem Kleinen heraus wachsen, nicht erst Großes planen.
  6. Referenz schaffen: Fertigstellen, zeigen, darauf aufbauen.

So setzt du „klein anfangen“ konkret um

Aus Bastians Rat lässt sich ein minimalistisches Vorgehen ableiten:

  • Formuliere eine Problem-Überschrift: „Eine Seite, die X zeigt.“ Wenn du den Satz nicht in 10 Sekunden sagen kannst, ist der Scope zu groß.
  • Sammle genau drei Ressourcen: Ein Tutorial, eine Doku, eine Beispielanwendung. Nutze sie, bis sie ausgereizt sind.
  • Plane eine feste Abgabefrist: 7 bis 30 Tage. Entscheide dich vorab.
  • Definiere ein Abschlusskriterium: Was bedeutet „fertig“? Ein klickbarer Link, ein Screenshot mit Kernfunktion, eine Demo vor Freundinnen oder Kollegen.
  • Schließe ab, bevor du erweiterst: Erst referenzierbar machen, dann nächsten Schritt planen.

Warum das wirkt: Genau so beschreibt Bastian sein eigenes Lernen in der Jugend – Projekte, Communities, Fokus auf Machen und Ausprobieren.

BI, aber menschlich: Daten sind erst auf der Oberfläche wertvoll

Ein roter Faden in Bastians Erzählung ist der Weg von Daten zur Oberfläche. BI endet nicht bei Modellen, sondern bei Menschen, die mit Ergebnissen arbeiten. Aus dem O-Ton lassen sich drei Qualitätsfragen destillieren:

  • Versteht der User, was er sieht? Wenn nicht, fehlen Struktur, Kontext oder Legende.
  • Kann der User handeln? Daten, die keine Entscheidung stützen, bleiben Zahlensalat.
  • Stimmt die Herkunft? Wer mehrere Datenquellen verknüpft, muss Herkunft und Aktualität kenntlich machen – sonst fehlt Vertrauen.

Auch hier lauert Bastians Pragmatismus: Gute Oberfläche ist nicht Selbstzweck. Sie ist Brücke zwischen Erkenntnis und Wirkung.

Vom „reingeschmissen werden“ zum Lernmotor: Unsicherheit als Feature

„Recht unerfahren reingeschmissen“ ist keine Lücke im Lebenslauf, sondern eine Lernarchitektur. Drei Gründe:

  • Du lernst das, was gebraucht wird – nicht das, was zufällig im Tutorial steht.
  • Du lernst schnell, weil Feedback unmittelbar ist.
  • Du lernst im Team, weil Fragen erlaubt sind und Hilfe greifbar ist.

Entscheidend ist die Umgebung. Bastians Teamkultur – direkt, hilfsbereit, iterativ – verwandelt Unklarheit in Fortschritt. Das ist ein Hinweis für alle, die den nächsten Arbeitgeber wählen: Achte auf Kommunikationswege, Hilfsbereitschaft und Iterationsgeschwindigkeit.

Ein Full-Stack-Blick hilft auch in BI

Bastian betont nicht explizit „Architektur“, aber zwischen den Zeilen ist klar: End-to-End-Denken bleibt sein Vorteil. Wer Frontend kennt, baut verständlichere Visualisierungen. Wer Backend kennt, modelliert robuster. Wer Datenbanken kennt, plant Datenflüsse realistischer. Genau dieser Dreiklang – Oberfläche, Logik, Daten – taucht in seinem BI-Teil wieder auf: umstrukturieren, Quellen verbinden, Informationen extrahieren, sinnvoll anzeigen.

Lernpfade ohne Mythos: Kein Geheimrezept, nur konsequentes Ausprobieren

Nichts in Bastians Erzählung klingt mystisch. Er markiert einen nüchternen Pfad:

  • Interesse finden.
  • Ressourcen fokussieren.
  • Kleines Projekt bauen.
  • Fertigstellen und als Referenz behalten.
  • Wiederholen – und dabei merken, was liegt und was nicht.

Gerade die Stelle „… merkt, okay, das macht mir Spaß, okay, das wäre jetzt nichts für mich …“ nimmt den Druck. Nicht jeder Pfad muss passen – Hauptsache, du probierst ihn in echt aus.

Leitlinien für Einsteiger und Quereinsteiger – destilliert aus Bastians Story

  • Beginne mit Eigeninteresse: Was dich neugierig macht, trägt dich durch zähe Phasen.
  • Arbeite in klaren Zeitfenstern: Woche oder Monat – Hauptsache, du schließt ab.
  • Suche dir Menschen: Communities, Kolleginnen, Kollegen – Fragen stellen beschleunigt.
  • Denke in Referenzen: Jedes fertige Mini-Produkt ist ein Baustein für dein Profil.
  • Verknüpfe Technik und Nutzen: Ob Full-Stack oder BI – am Ende zählt, was beim User ankommt.

Teamarbeit als Multiplikator: Warum „kurze Wege“ so viel bewirken

Wenn Bastian sagt, „man kann … einfach mit dem Chef reden“ und „von der Idee zum Endprodukt sehr, sehr leicht und sehr schnell gehen“, steckt darin ein Organisationsprinzip: Entscheidungen dorthin rücken, wo Informationen entstehen. Für Entwickler bedeutet das:

  • Ideen nicht parken, sondern testen.
  • Feedback nicht vertagen, sondern nutzen.
  • Verantwortung nicht schieben, sondern übernehmen.

Das Ergebnis: Mehr fertige Dinge, weniger halbfertige Gespräche.

Fazit: Eine klare Dev-Story mit echtem Kompass

„Bastian Schmidt, Software Developer bei ECO-Soft“ zeigt, wie ein Weg in der Softwareentwicklung ohne große Effekte, aber mit klaren Schritten funktioniert: neugierig starten, breit lernen, in Daten eintauchen, Nutzerperspektive ernst nehmen, als Team schnell werden und konsequent kleine Produkte liefern. Sein pragmatischer Rat – Thema wählen, Ressourcen bündeln, fokussiert ein Mini-Produkt bauen, iterieren, Referenz schaffen – ist so universell wie wirksam.

Wer den Sprung in Themen wie BI erwägt, findet in Bastians Erfahrung zusätzliche Bestätigung: Datenarbeit ist mehr als Technik. Es geht um die Herkunft der Daten, ihre Umstrukturierung, das Herausarbeiten von Informationen – und darum, wie all das auf der Oberfläche erscheint, damit Nutzer etwas damit anfangen können. Genau dort entfaltet Software Wirkung.

Für uns als Redaktion bleibt aus dieser Session vor allem eines hängen: Karrierewege entstehen selten am Reißbrett. Sie entstehen, wenn Menschen – wie Bastian – früh anfangen, echte Dinge zu bauen, Hilfe einzuholen, sich in Neues „reinschmeißen“ lassen und so lange iterieren, bis aus einer Idee ein Produkt wird.

„… von der Idee zum Endprodukt sehr, sehr leicht und sehr schnell … Ideen iterieren und ausprobieren …“

Das ist keine Floskel, sondern eine Haltung. Wer sie annimmt, kommt voran – ob im Full-Stack, in BI oder überall dort, wo Software echten Nutzen stiften soll.

Weitere Tech Lead Stories

Weitere Dev Stories