In dieser Folge stellen wir die Frage, ob Junior Developer im
Zeitalter von Cursor, Co, Pilot und Co.
Noch gebraucht werden oder ob sie künftig nur noch Kaffee
kochen. Wir klären, welche Skills für
Berufseinsteiger von morgen entscheidend sind, was einen
guten Junior ausmacht und warum frische Talente trotz KI
unersetzlich bleiben. Und damit Hallo und herzlich
Willkommen zu einer neuen Folge vom to do Developer Podcast, dem
deutschsprachigen Developer Podcast mit Robin Manuel Thiel.
Und mir malte lantin ich bin Visions Engineer bei Github und
Robin Manuel arbeitet seit vielen Jahren bei Microsoft und
wir sprechen hier privat über alle Themen rund um die
Softwareentwicklung und beschäftigen uns heute mal mit
dem Karriereeinstieg und dem, was sich da gerade tut.
Wie sich das Ganze verändert und ob es wirklich so ist, wie man
auf Youtube in letzter Zeit ganz häufig hört, dass es einfach gar
keine Stellen mehr zum Einstieg in die Softwareentwicklung gibt.
Aber bevor wir in das Thema reingehen, erstmal noch
eigentlich die wichtigste Sektion des Podcasts, nämlich
unsere Kaffeesektion. Genau, denn jeder gute
Deverdorfer weiß, egal ob Junior oder Senior, ohne Kaffee geht
bei den meisten wenig und deswegen sind wir euch ganz,
ganz dankbar, dass ihr uns hier auch für diesen Podcast mit
Kaffee aufgeladen habt. Und zwar sagen wir zweimal danke
an den Tobias, der hat uns 2 Kaffee ausgegeben und der
Benedikt hat 3 Kaffee ausgegeben und hat uns gesagt wir sollen
uns dabei. Davon bei den Coffee Twins einen
Zimtknoten holen. Wir haben da eine ganz lustige
Geschichte, wir haben scheinbar weise das gleiche Stammcafé hier
in München und sind da irgendwie, weil wir weil malte
und ich vor ein paar folgen, da ich auch mal zusammensaßen und
da unseren Kaffee geholt haben, ist das dem Benedikt scheinbar
aufgefallen, ganz lieben Dank dafür.
Und damit steigen wir direkt in die Folge ein und reden da
drüber. Wir.
Was macht eigentlich Junior Developer im Jahre 2025 aus und
auf was muss man sich eigentlich einstellen, wenn man jetzt neu
in die Softwareentwicklung einsteigen möchte?
Und ich rede jetzt hier nicht über das Thema Ausbildung oder
Studium, sondern tatsächlich den Berufseinstieg und was dabei
relevant wird, wenn ich jetzt meine Ausbildung oder vielleicht
auch meine meine Self Learning Journey abgeschlossen habe und.
Meine erste professionelle Aufgabe in einer Firma Suche.
Ich glaube erstmal so ein bisschen den den Reality Check,
also warum wir uns überhaupt diese Frage stellen und sich die
ganze Industrie eigentlich gerade diese Frage stellt ist,
dass man schon auch messen kann, dass zumindest bei
Jobausschreibungen im Moment juniorstellen verschwinden oder
zumindest abnehmen. Also Signal Fire hat da eine
Umfrage gemacht. Und die haben gesagt, von so
allen New Great Highers also es müssen nicht nur Junior
Developer sein. Alles was irgendwie so
Berufseinsteiger sind, sind im Moment nur noch 7% aller
ausgeschriebenen Stellen, sind halt eben für Menschen, die Früh
in ihrer Karriere sind und das ist gegenüber dem Jahr 2019 eine
Reduktion von rund 50% das heißt glaube ich nicht, dass dass
jetzt niemand mehr wie der neu oder frisch in diese in diese it
und Developer Welt kommt. Gebraucht wird aber, zumindest
sind auch nach dieser Studie, die sich die meisten CT OS
einig, dass KI da einen Einfluss drauf hat und zumindest diesen
diese Berufseinsteigerrolle transformiert, jetzt nicht nicht
ersetzt, aber transformiert und das liegt natürlich auch unter
anderem daran, dass wir Halt KI haben, die sehr guten Code heute
schon schreiben kann, was halt früher so ein bisschen Aufgaben
auch von Junior developern waren und das natürlich auch zu einem
Bruchteil der Kosten. Und 24 7 verfügbar sind und ich
Resultate innerhalb von ja manchmal weniger Minuten bekomme
anstatt von Stunden und Tagen. Also das ist glaube ich so ein
bisschen der Aufhänger und der Grund, warum man sich gerade die
Aufgabe, überhaupt die Frage stellt.
Wie sich diese Juniorrolle transformieren wird?
Jan, Du hast es gerade gesagt. Nicht alle Stellen sind
vielleicht so explizit für Junior und Developer
ausgeschrieben, manchmal sind es einfach developerstellen, wo
dann drin steht halt für Leute, die Früh in ihrer Berufslaufbahn
sind, häufig sind das so die ersten 234 Jahre.
Die dort in Frage kommen. Aber das ist auch ein ganz
wichtiger Punkt, dass bei vielen Einstiegspositionen mittlerweile
tatsächlich 23 Jahre Erfahrung erwartet werden, was so ein
bisschen Counter intuitiv ist. Das heißt, eigentlich denkt man
ja, wenn jemand frisch irgendwie aus Ausbildung und Studium
kommt, dann bringt diese Person eigentlich gar keine Erfahrung
mit oder nur extrem wenig, aber das ist zum Beispiel einer.
Der Punkte, der häufig in letzter Zeit genannt wird.
Dass selbst bei diesen Junior Positionen mittlerweile
Erfahrung benötigt wird und was eigentlich diese Erfahrung
ausmacht, darüber sprechen wir heute ein bisschen intensiver.
Also welche Skills braucht man, um erfolgreich als Developer ins
Berufsleben einzusteigen? Man muss dazu auch noch sagen,
dass sich das natürlich auch immer gut klickt, wenn man
schreibt, irgendwie, hey, wir brauchen keine Juniorinnenrollen
mehr. Was passiert mit Junior
Developern? Man muss, gerade wenn man sich
solche Statistiken anguckt, wie wie viele Stellenausschreibungen
gibt es, in welchen Rollen auch immer, so ein bisschen die
Marktlage im Auge behalten zwischen zwischen dieser Zeit
war covid, Wir hatten einen Wahnsinns Boom an an neuen SARS
Produkten, an E Commerce Shops, die irgendwie aus dem Boden
geschossen sind, also in also eine Riesen.
Künstlich befeuerte Nachfrage erstmal an überhaupt allen
möglichen Arten von Software developern.
Ki war damals noch gar nicht so weit, war gerade irgendwie in
den Kinderschuhen, aber Kapital war günstig aufzunehmen, ganz
viele Firmen, ganz viele Start Ups sind aus dem Boden
geschossen und haben auch teilweise überhired gerade große
Firmen, das ist jetzt weniger Junior Developer, aber gerade
große Firmen haben auch teilweise einfach nur Leute
gehired um sie weg vom Markt und Weg von der Konkurrenz zu haben.
Und das kühlt jetzt generell gerade so ein bisschen ab.
Also man muss diese Zahlen auch so ein bisschen mit Vorsicht
genießen, deswegen klar, es gibt eine Reduktion, ob die jetzt so
stark ist, wie wir sehen, ob das einzig oder alleine von KI
abhängig ist es fraglich, aber wir hatten eben schon gesagt,
diese Studie hat auch gezeigt, dass CT OS sich einig sind, dass
KI dann Einfluss drauf hat und deswegen stellen wir uns jetzt
in dieser Folge auf die Frage, welche Aufgaben bleiben denn,
welche Skills braucht man denn jetzt und warum sollten Teams
weiterhin Junior Developer fördern?
So weit können wir schon mal hinweggreifen.
Was würdest du denn sagen? Malte, was sind denn so
klassische Aufgaben eines Junior Developers, wenn jetzt jemand
irgendwie noch gar nicht mehr damit zu tun hat, fängt jetzt
irgendwie frisch in der.it an, wenn ich sag OK was, was werden
denn oder gerade so in dem Software Development, was sind
denn so die ersten Aufgaben, die du jetzt im Junior Developer der
in dein Team kommen würde? Geben würde.
Es ist mal ganz unabhängig davon, ob KI oder nicht, aber
was sind so klassische Tasks? Ja, also aus meiner Sicht sind
das vor allen Dingen Aufgaben, die Dir als Junior helfen.
Mit unserer Software vertraut zu werden, mit der Architektur, mit
der Technologie. Und das sind dann häufig
Aufgaben, die relativ eng umsteckt sind, halt irgendwelche
Bugfixes zu machen, kleinere Features zu implementieren,
vielleicht fehlende Tests zu ergänzen, irgendwelche Daten
einzupflegen. Das heißt, Aufgaben, die es dir
ermöglichen, über vielleicht 6 bis 12 Monate in unsere
Codebasis einzusteigen, die Technologie zu lernen und
einfach die Praxiserfahrung zu entwickeln, die du brauchst, um
bei uns erfolgreich zu sein, weil nur weil du vielleicht
irgendwie vorher schon mal Software geschrieben hast, heißt
es ja nicht, dass du. Mit der Software in unserem
Unternehmen sofort zurecht kommt.
Man hört halt häufig von ganz vielen Firmen.
Ja, bei uns ist alles anders und ganz speziell, das trifft auch
ganz oft zu, gerade wenn man sagt okay man geht nicht in so
eine klassische Softwarefirma, die auf irgendeinem modernen
Software Stack jetzt irgendwie einen SARS aufgebaut hat oder
irgendeine Webplattform, sondern man geht halt in gerade in
Deutschland in irgendwie die fertigende Industrie und baut
dann irgendwie Software, die irgendwie mit Hardware
zusammenarbeitet und dann irgendwie auch gemeinsam
verkauft. Aufstellt.
Das ist natürlich etwas, wo die wenigsten schon vorher mit
Erfahrung gesammelt haben und dementsprechend sind solche
kleineren Aufgaben häufig die Sachen, mit denen ich anfange.
Aber da sind natürlich auch viele Aufgaben dabei, die
mittlerweile automatisiert werden, und da reden wir nicht
nur über KI, sondern wir reden halt auch über andere Tools, die
Automatisierung vorantreiben. Wir hatten ja auch vor der KI
Welle schon immer mehr Tools, die mir helfen, automatisch
vielleicht irgendwie Tests zu generieren oder auch die
Erfahrung. Immer die Testabdeckung zu
Monitoren und diese Automatisierung übernimmt
natürlich viele dieser Aufgaben. Und jetzt durch KI wird es so
einfach wie nie zuvor, das heißt einfach in vielen Bereichen ist
es einfach ein Rechtsklick irgendwie zu sagen.
Fixed the Bug und dann kriege ich irgendwie einen KI
Vorschlag, muss dann am Ende nur noch validieren ob das ganze
wirklich funktioniert hat, aber diese intensive Beschäftigung
mit der Codebasis kann natürlich.
Dementsprechend wegfallen. Ja, die aber auch.
Sehr wichtig ist, du hast es gerade gesagt und das kann ich
nur bestätigen. Also die meisten Firmen, in die
ich reingehe und mit denen ich über auch gerade so KI gestützte
Softwareentwicklung spreche, die haben alle irgendwie so ein,
aber ja, aber bei uns ist ein bisschen was anders, wir nutzen
ein bisschen eine andere Technologie, wir haben
irgendwelche Altlasten, aber bei uns, wir haben eine andere
Businessanforderung, deswegen mussten wir hier das so und so
machen, ja, wir haben aber noch eine andere Struktur, ja, wir
sind aber noch auf der auf der alten Version von.
Framework XY. Das lernt man natürlich über
diese kleinen Aufgaben, die du eben beschrieben hast.
Und wenn die jetzt wegfallen, wird das schwieriger oder wenn
die halt irgendwie automatisiert werden.
Aber da muss man auch ganz klar sagen, diese Automatisierung, so
realistisch muss man sein, die kann das zumindest stand heute
ja auch nicht zu 100% alleine. Also es gibt ja diese ganzen
Coding Agenten oder auch halt irgendwie, wenn ich irgendwelche
Prompts in eine Kopeile rein schicke, da kommt sehr schnell
sehr viel Code raus, aber. Aber das muss ich ja trotzdem.
Diese Ergebnisse muss ich ja trotzdem irgendwie bewerten.
Noch mal die Prompts verfeinern und auch irgendwie mich fragen,
ist das überhaupt richtig, was daraus gekommen ist?
Also stimmt das überhaupt, muss das Ergebnis überprüfen, da gibt
es auch mittlerweile Methoden, dass eine KI da bessere
Ergebnisse liefern kann, die sie sich selber überprüfen kann,
aber alleine mal dem zuzuschauen und dann festzustellen, ob der
Bug dadurch wirklich gefixt wurde und vielleicht so ein
bisschen mehrere von diesen Agenten zu orchestrieren kann.
Kann ja auch ein ähnliches Learning hervorbringen wie den
Bug selber zu fixen, wenn man sich da, wenn man den Code eben
nicht einfach nur akzeptiert, sondern auch quasi selber noch
mal überprüft, sich selber fragt, warum sind denn da welche
Änderungen vorgeschlagen worden, hätte es denn keine bessere
Lösung dafür gegeben und so weiter.
Ja, ich glaube, du bist jetzt ja schon relativ tief drin in
diesem ganzen Ki softwareentwicklungsthema und
redest schon über Agenten. Aber selbst bei den einfachen
Dingen wie einer Code Auto Vervollständigung oder einer
Chat Funktion die mir hilft irgendwelchen.
Und welche Codevorschläge zu generieren, muss ich natürlich
diese Validierung und dieses Hinterfragen vornehmen.
Aber gerade mit den Agenten wird es halt noch herausfordernder,
weil die natürlich mit einem Durchlauf.
Vielleicht viel mehr Code erzeugen an ganz vielen
verschiedenen Stellen, die Miteinander interagieren.
Und ich habe dann auch nicht mehr nur einen Agenten, der
irgendwie arbeitet, sondern mehrere und muss dann auch
gedanklich immer zwischen den unterschiedlichen Aufgaben,
vielleicht hin und her springen, überwachen, ob halt alle auch
konsistent miteinander arbeiten und gerade dieses Multitasking
ist ja etwas, was ich vielleicht am Anfang meiner Karriere noch
gar nicht so beherrsche. Ich kenne vielleicht die
Codebasis nicht so gut. Habe vielleicht noch nicht in so
vielen Softwareprojekten gearbeitet und kann
dementsprechend nicht zwischen verschiedenen Dingen hin und her
springen und in der Vergangenheit waren das dann so
Aufgaben, die habe ich dann relativ spät in meiner
Berufslaufbahn, wenn ich vielleicht dann Engineering
Manager werde, erst übernehmen müssen, weil als Engineering
Manager muss ich ja auch schauen, an welchen Themen
arbeiten meine Leute gerade, muss vielleicht mal in einem
Code Review aushelfen, geh da mit rein, schau was die Leute
machen, muss da auch häufig Kontext switchen zwischen den
verschiedenen Aufgaben und. Muss die komplette Codebasis
irgendwie im Blick halten und verstehen.
Und jetzt habe ich plötzlich schon sehr früh in meiner
Karriere die gleichen Herausforderungen, das heißt,
ich habe schon gerade erst angefangen, irgendwie
professionelle Software zu entwickeln, muss aber plötzlich
die komplette Codebasis überblicken, weil irgendwelche
Agenten vielleicht hier und da Änderungen machen und vielleicht
mehrere Agenten gleichzeitig für mich an etwas arbeiten, und das
ist, glaube ich, ein ganz wesentlicher Unterschied
zwischen den Aufgaben, die ich vorhin beschrieben hatte, die
ich traditionell eigentlich am Anfang meiner Karriere häufig
mache, die sehr. Überschaubar sind.
Da geht es dann meistens wirklich nur darum.
Ich habe irgendwie eine Datei mit irgendwelchen Methoden und
muss dann dafür die Testcases schreiben oder ich habe einen
Bug, der betrifft vielleicht genau eine Methode, das heißt,
ich habe irgendwie vielleicht 20 Zeilen Code, die ich überblicken
muss und der Rest der Software ist Software.
Ist mir vielleicht erstmal in Anführungsstrichen egal, aber
damit komme ich jetzt halt jetzt mit der KI generierten Software
wahrscheinlich gar nicht mehr durch.
Ja, ich komme halt sehr, sehr schnell an so einen Punkt, wo
ich was reviewen muss, was ich ja eigentlich erst traditionell
ohne KI, später meiner Karriere irgendwann mal mache.
Und ich hatte das auch gelesen in so einem Artikel, dass das
irgendwie so vielleicht auch so ein wichtiger neuer Skill werden
könnte, so ein Multitasking zwischen Agenten, dass ich
einfach nur noch so Agenten, ja orchestriere, die jetzt für mich
irgendwie an mehreren Sachen durchlaufen, aber da weiß ich
auch nicht, ob ich da so ganz mit D Accord gehe, weil das hat,
da stoße ich ja irgendwann schneller, meine mentalen
Grenzen, also ich kann. So ein Kontext switching über so
ganz viele KI branches. Es funktioniert vielleicht, wenn
man Erfahrung hat für kleine Tasks, aber wir alle wissen,
wenn ich ein komplexes Problem habe, da muss ich das noch
selber durchdenken, da muss ich mich hinsetzen und ja, Cloud und
Koophalde und Cursor und so weiter die die tippen schneller
als ich, aber jeder weiß ja auch je weiter man irgendwie seiner
Karriere als Software Developer voranschreitet, desto weniger
Code schreibt man eigentlich und desto mehr.
Denkt man eigentlich über ein Problem nach?
Das wird jetzt wahrscheinlich ein bisschen früher kommen, das
finde ich aber gar nicht schlimm, weil das ist ja auch
der eigentliche Skill, den man aufbauen muss, du bist ja kein
guter Developer, weil du schnell tippen kannst.
Ein Buchautor, der schneller tippen kann als ein anderer, der
schreibt ja auch nicht bessere Geschichten als ein anderer und
was diese LMS ja wirklich gut können, ist sehr schnell Code
schreiben, aber. Aber nur, weil ich nur weil es
schnell ist, muss ich ja trotzdem bei komplexen Problemen
mir noch selber Gedanken machen und irgendwie auch vielleicht
die die Stelle finden, wo der Bug aufgetreten ist und so, und
das kommt jetzt glaube ich, ein bisschen früher an die Karriere.
Das fand ich eigentlich ganz spannend, dass du das gerade
gesagt hast, dass es ein Skill ist, der eigentlich später.
Früher erst kam der ja, aber wahnsinnig wichtig ist also
vielleicht ist es ja auch eine gute Entwicklung, was ich.
Ganz, ganz interessant finde bei dem, was du gerade gesagt
hattest, ist ja nur, weil ich mehr Zeichen schreibe, bin ich
jetzt nicht ein besserer Buchautor.
In der Softwareentwicklung gilt das gleich und das wissen wir
seit vielen Jahrzehnten, dass irgendwie Lines of Code per
Developer vielleicht nicht eine ideale Metrik ist, um irgendwie
die Produktivität. Meine Teams zu messen.
Jetzt verfallen natürlich wieder viele dazu, weil sie irgendwie
sagen, wir führen jetzt KI ein und wollen sehen, wieviel besser
unsere Teams durch KI werden und dann fängt man plötzlich an
irgendwelche lines of AI generated Code zu zählen, was ja
eigentlich absoluter Quatsch ist.
Es geht jetzt ja nicht darum, dass wir mehr Zeilen Code
erzeugen, sondern wir wollen einfach bessere Ergebnisse
erzielen, wir wollen effizienter sein, wir wollen vielleicht.
Mehr Funktionalität erzeugen und wenn das am Ende weniger
Zeilencode sind, ist das natürlich auch super und
insbesondere super. Wenn ich als Developer weniger
Zeilencode von Hand tippen muss, weil ich glaube, was mir als ich
sag jetzt mal Software engineer eigentlich mehr Spaß macht, ist
ja kreativ Probleme zu lösen und nicht irgendwie.
Die Tasten auf meiner Tastatur zu drücken und möglichst viele
Wörter irgendwie in meinen Code Editor zu schreiben und da ist
natürlich so ein bisschen so ein Paradigmenwechsel auch zu sehen,
dass es jetzt nicht mehr darum geht, dass wir als Junior
Developer sagen können, ich habe jetzt hier so und so viele Unit
Tests implementiert oder guck mal hier, ich habe irgendwie
diese API alleine umgesetzt, das sind 2000 Zeilen Code das. 2000
Zeilen Code können mittlerweile von so einem KI Tool in wenigen
Sekunden bis Minuten generiert werden.
Also da ist jetzt wirklich der Punkt erreicht, wo das absolut
kein Maßstab mehr sein kann. Ein anderer Skill oder eine
andere Aufgabe, die Junior Developer oft haben und die ich
eigentlich auch sehr wertvoll finde und die dann auch gar
nicht irgendwie berührt wird von sowas wie KI, ist das ganze
Thema. Irgendwie so Stakeholder
Kommunikation, oder? Sich irgendwie.
Vielleicht ist irgendwie so anforderungsklärung das richtige
Ding, also irgendwie als Beispiel, wenn irgendwie
Fachabteilungen so ganz vage Wünsche äußern, wie kann das der
Sport schneller werden, dann braucht es halt irgendwie
jemanden der der nachfragt, was genau damit gemeint ist, der
vielleicht auch irgendwie Kompromisse aushandelt, der aber
auch das Projekt und den Code versteht, also auch so ein
bisschen die Machbarkeit und auch vielleicht auch eine
Aufwandseinschätzung würde ich gar nicht sagen, den hat man
dann oft irgendwie gemeinsam im Team.
Aber. Aber auch, so die
Zwischenergebnisse präsentieren. Und das sind ja auch alles
Infos, die ich dann irgendwann brauche, selbst wenn ich das
dann durch eine KI machen lasse, denn so ein Large Language
Modell, das braucht ja in einem prompt präzise Informationen und
die können nicht zwischen den Zeilen lesen und diplomatisch
irgendwas verhandeln oder sollten vielleicht auch gar
nicht unbedingt eine Roadmap priorisieren oder sowas und A
lernt man da wahnsinnig viel über das eigene Unternehmen und
und auch über die Software die man baut, also auch den Business
Value der Software die man baut und die Kunden, die am Ende die
Software verwenden, aber natürlich auch.
Die eigene Software besser kennen, indem ich einfach weiß,
ah okay mal so ein Dashboard schneller werden, was hängt denn
da eigentlich alles dran? Ist das ein Problem mit der
Datenbank, haben wir Netzwerk Latenz ist unser Code langsam
ist unser Code irgendwie schlecht geschrieben, was muss
da alles für angefasst werden, wer ist denn dafür
verantwortlich und so weiter und das sind auch Sachen für die man
natürlich auch soft Skills braucht, das können wir ja
eigentlich gleich mal anschauen, welche neuen Skills sind denn
gefragt oder wie verändert sich das?
Aber das war auch immer eigentlich so eine Junior
Aufgabe, die ich auch immer sehr, sehr wichtig fand, weil du
halt sowohl das Unternehmen kennenlernst als auch die den
eigentlichen Sinn der Software ist ja keinen Selbstzweck
Software zu schreiben, wir machen das ja nicht um zu
programmieren, sondern immer um irgendwie Probleme zu lösen und
das lernt man damit auch noch mal besser kennen und die ganzen
Stakeholder, die irgendwie involviert sind.
Ja, ich fand ein Beispiel gerade ganz gut, weil es kann ja nicht
deine Aufgabe oder es sollte nicht deine Art und Weise sein,
neue Features zu implementieren, indem du einfach die.
Die Wagenaussagen dann als Stakeholder in einen prompt
Park. Mach mal das Dashboard
schneller, wenn ich irgendwie Cloud oder co Pilot sage, mach
mal das Dashboard schneller kriege ich entweder dumme
Rückfragen, die ich dann nicht beantworten kann, oder kriege
ich halt irgendwelche Ergebnisse die nicht das sind was
eigentlich das Business von mir will und es kann auch nicht das
Ergebnis sein, dass die Kollegen aus dem Business selber diesen
Wagen prompt in so ein KI Tool reinwerfen, sondern meine
Aufgabe ist es dann wirklich. Zu verstehen, in welcher
Technologie ist mein Dashboard implementiert?
Was wollen die Leute eigentlich, was meinen die damit mit, es
soll schneller werden, soll es schneller laden, soll es
irgendwie schneller sich aktualisieren und dann muss ich
natürlich reingehen, welche Komponente ist davon eigentlich
betroffen und dann kann ich natürlich auch gerne ein KI Tool
benutzen und sagen mit diesem Wissen was ich jetzt habe kann
ich das genau scropen und sagen okay das ist die Anforderung an
dieser Stelle sollen folgende Verbesserungen vorgenommen
werden also ich fand die. Ich fand ein Beispiel sehr gut
und viele denken jetzt, dass vielleicht dann die
Developerrolle irgendwie ganz wegfällt und wirklich das
Business dann hingeht und sowas in so einen prompt schmeißt.
Aber das scheitert dann spätestens dann, wenn man eine
gewisse Professionalität in der Softwareentwicklung hat, weil
natürlich diese Leute dann die ganzen Software Engineering
Fundamentals allein versionskontrolle, welche
deployments Möglichkeiten habe ich einfach auch nicht
verstehen, das heißt, sie können gar nicht auf dem Code.
Arbeiten und diese Änderungen selber vornehmen und dafür
brauchen wir halt die Software Engineers, die die Anforderungen
in tatsächlich die Software umsetzen.
Uns sagt ja auch keiner, dass die das dann nicht irgendwie mit
der Hilfe von KI machen können. Also das sind ja vielleicht so
jetzt die neuen Skills, die dann gefragt sind, also das A.
Natürlich glaube ich, das ist ein ganz essentieller Skill für
Junial Developer oder generell berufsansteigende so eine.
Gewisse, Wie kann man das beschreiben, so eine KI
Intuition eigentlich ist also vielleicht sich viel öfter die
Frage zu stellen, vielleicht können wir das ja irgendwie mit
KI lösen, dann aber richtig, wir hatten in Folge 121 mal über das
Thema Context Engineering gesprochen, was ja genau dieses
Ding ist. Selbst transformieren, was sind
die Informationen, die richtigen Informationen, die ich so einer
KI mitgeben muss, damit sie dann vielleicht das der Sport
schneller machen kann, was heißt das, an welchen Stellen soll es
schauen, an welchen Stellen soll es nicht schauen?
Was heißt denn genau eigentlich schneller?
Also da haben wir eine ganze Folge mal drüber gemacht und ich
glaube, vielleicht ist genau das im Context Engineering ja auch
ein Skill, den ich jetzt jemandem, der oder die in diesen
Beruf einsteigt und irgendwie so ein Junior berufseinsteigende
Rolle, was auch immer hat, direkt mal mal mitgeben würde,
weil wir müssen ja nicht wegdiskutieren, dass KI da ist.
Wir werden auf jeden Fall eine Generation haben, die jetzt
irgendwie mit KI aufwächst, die vielleicht auch eine viel
bessere Intuition dafür haben, was man damit machen kann oder
viel öfter zu diesem Werkzeug KI greift und.
Aber das muss, das muss man natürlich richtig verwenden.
Und ja, context Engineering könnte 1 von diesen neuen Skills
eben sein, die genal Developer dann heute mitbringen müssen,
ja. Ich sehe das so ein bisschen so
analog zu diesem Begriff der Digital Natives.
Ich glaube, wir, die wir jetzt seit 15 Jahren vielleicht und
mehr in dem Bereich der Softwareentwicklung unterwegs
sind, wir mussten jetzt über die letzten Jahre lernen, was KI
anders macht, aber. Aber andere, die jetzt in die
Softwareentwicklung einsteigen, die kennen es nicht anders.
Die wissen, dass es diese Tools gibt und sie haben von Tag 1 des
Lernens der Softwareentwicklung KI Tools eingesetzt und für die
ist das völlig normal, dass bestimmte Aufgaben, die man
vorher noch manuell tippen musste, jetzt natürlich KI
generiert umgesetzt werden. Das bedeutet aber nicht, dass
ich dann entsprechend. Am Ende besserer Engineer werde
genauso wie viele Digital Natives mit manchen
Digitaltechnologien einfach nicht umgehen können, weil sie
die Fundamentals nicht gelernt haben.
Und ich glaube ja, es gibt eine bessere Intuition, weil wenn man
das von Anfang an mitgenommen hat, dann kennt man auch so ein
bisschen die Grenzen, man weiß, wie muss ich mit so einem Lnm
sprechen, was sind die Dinge, die so ein Lnm gut kann, was
sind die Dinge, die es weniger gut kann, das sind vielleicht
Dinge, die man. Wenn man anders aufgewachsen
ist, erst lernen muss, die man jetzt intuitiv mitnimmt.
Und von daher findet ihr diesen KI intuitionsbegriff gar nicht
mal so verkehrt. Aber das heißt natürlich nicht,
dass man dadurch automatisch KI voll und ganz beherrscht und
jetzt nicht mehr die Grundlagen lernen muss.
Ja, nur weil du mit KI aufwächst, heißt das nicht, dass
du KI beherrscht. Finde ich.
Eigentlich finde ich einen validen Punkt und das Gleiche
ist bis. Ich glaube, dass wir uns, also
dass auch einer so ein neuer Skill, irgendwie von Junior
developern wird, früher höher im Stack anzusetzen.
Was meine ich damit? Also ich brauche jetzt keinen
Junior Developer mehr, der wie Boiler Plate Code schreibt, das
macht jetzt halt, aber ich glaube man muss sich jetzt eben
drauf fokussieren so Skills wie Debugging zum Beispiel früher zu
lernen oder unser System Design zu beherrschen oder auch
effizient zu kollaborieren und. Ich hatte, da habe ich eine ganz
eine ganz aktuelle Geschichte zu.
Ich habe gestern witzigerweise mit jemandem gesprochen und
gemerkt, dass Debugging ein so wichtiger Skill wird, und zwar
besonders in der Welt, wo du den Code wahrscheinlich nicht selber
geschrieben hast. Das war immer schon so, weil ihn
vielleicht ein Kollege oder eine Kollegin geschrieben hat, oder
jetzt, weil ihn vielleicht auch eine KI geschrieben hat, und ich
habe gestern erst jemandem geholfen, einen Geweibecoded
einen html Code zu fixen, das war einfach eine.
Eine satic Website, einfach HTML, CSS und und Java Script
und ich habe der Person erstmal die Chrome Debugging Tools
gezeigt und wie man sie benutzt und das war wirklich Augen
öffnend weil ich dann damit erstmal sehe.
Ah okay ich habe hier ein html Element was nicht an der Stelle
ist wo ich es haben will oder nicht so angezeigt wird wie ich
es haben will. Wie finde ich denn raus warum
das so angezeigt wird oder welches Element jetzt dafür
sorgt, dass ich irgendwie doch weiter scrollen kann.
Also ich will dass ich da also diesen Pkh mit der Maus über
Elemente fahre, dann auch sehe wo.
Fangen die an? Wo hören die auf, wieviel Margin
und wieviel Padding haben die denn bekommen, also wieviel
innen und außenabstand und ja wo, in welcher welcher Stelle?
Im CSS ist das denn definiert und das sind die Informationen
die ich rausfinden muss, also debuging so ein bisschen oft als
Fehlersuche, weil wenn ich der KI weil das ist nämlich der
Grund, warum die Person mich gefragt hat, damit ist sie nicht
weiterkommen, der KI immer wieder zu sagen, einfach nur das
Problem zu beschreiben und. Ohne zu beschreiben, wo es
schauen soll oder warum das Problem vielleicht entsteht.
Hat dann halt nicht zu Erfolg geführt und so haben wir relativ
schnell gesagt, Pass auf so und so kannst du selber herausfinden
wo das Problem liegt und das hat die Person jetzt einfach zu
einem ja muss man schon sagen besseren White coder gemacht,
weil was jetzt in der Lage ist selber herauszufinden warum
bestimmte Dinge so angezeigt werden wie sie werden und diese
Basics haben da halt erstmal gefehlt und ich glaube, dass wir
uns einfach jetzt früher. Mit diesen Debugging Skills
beschäftigen werden, weil wir immer an den Punkt kommen
werden, wo die KI nicht weiterkommt und wir dann
zumindest rausfinden müssen, warum ein Fehler auftritt, um
den dann noch präziser, selbst wenn wir selber nicht lösen
können, aber noch präziser irgendwie in so ein ki Tool
reingeben. Guck mal, hast du der ersten
Person auf der Reise vom Vipe Coder zu einem richtigen
Software Developer geholfen? Ja, das hatten wir, glaube ich,
in der in der Folge über Vipe Coating.
Habe mir doch mal kurz irgendwie gesagt, vielleicht gibt es so
eine neue Stufe von Developer noch unter Junior Developer
irgendwie so. Ich weiß gar nicht, wie wir sie
da genannt hatten, aber wir haben es doch nicht mit der Vipe
Coding Folge mal gesagt und vielleicht ist es wirklich so,
dass so eine Stufe weiter unten in dieser Karriereleiter in
Anführungszeichen dazu gekommen ist.
Durch Vipe Coding stimmt. Ja, ich meine gerade mit diesen
Tools und des Vipe Coding mit Tools wie irgendwie Cursor oder
irgendwelchen Agenten ist ja nur der erste Schritt.
Es kommen ja immer mehr Werkzeuge, wo ich einfach nur
auch mit natürlicher Sprache beschreibe und dann eine
komplette Anwendung bekomme und da werde ich dann vielleicht gar
nicht zu einem Coder, sondern vielleicht zu einem Software.
Software Creator, das heißt, ich habe am Ende irgendwie ein Stück
Software basierend auf meinen Anforderungen und meinen
Wünschen erzeugt, verstehe aber eigentlich gar nicht, wie diese
Software erzeugt wurde und der nächste Schritt und da bist du
ja jetzt hingekommen. Über die Developer Tools ist
wirklich in den Code reinzugehen und sich zum ersten Mal damit zu
beschäftigen. Was ist da hinter den Kulissen
entstanden, das dann zu debuggen und damit dann auch die Reise in
ein Verständnis zu machen, wie eigentlich Software funktioniert
und vielleicht ist da dein dein Freund AI native aber lernt
jetzt tatsächlich die die. Das wissen dazu, was man auch
braucht, um selber Software zu entwickeln.
Und damit kommen wir glaube ich auch zum nächsten Punkt.
Wir haben jetzt viel über das geredet, was sich verändert,
aber viele Dinge bleiben auch gleich.
Du hattest gesagt, man muss immer noch debuggen können und
das ist eine wesentliche Fähigkeit in der
Softwareentwicklung und da gibt es natürlich auch ganz viele
andere Fundamentals, wenn ich professionell Software
entwickle, muss ich weiterhin als.
Junior Developer Early in Career.
So Dinge lernen wie wie funktioniert
Quellcodeverwaltung, wie funktioniert git, wie
funktioniert Brunching, welche Architekturen gibt es, welche
Patterns gibt es? Ich habe jetzt auch letztens von
einem Freund, der auf der VR Developers Konferenz war,
gehört, dass gerade diese Architektur Sessions extrem gut
angekommen sind, dass da auch ganz viele Leute hingehen und
sagen okay coden Code schreiben, das kann jetzt irgendwie jeder.
Aber das, was ich als Developer noch lernen muss, ist wirklich,
wie baut man wartbare Software, welche Architektur Patterns gibt
es und das brauche ich natürlich im professionellen,
professionellen Umfeld umso mehr.
Ja, wie brauche ich eine skalierbare Software?
Also so Dinge, weil das ist ja oft sehr individuell auf die
eigene Anforderung und so, und das zeigt sich natürlich, stand
heute, ist das noch wahnsinnig wichtig, vielleicht, vielleicht
geht das in 10 Jahren auch irgendwie weg, vielleicht sagen
in 10 Jahren auch Ach was, wofür brauche ich Architektur
patterns, wofür brauche ich wartbarkeit.
Vielleicht ist die KI irgendwann so gut, dass sie das alles
irgendwie selber machen kann. Aber was du halt gerade sagst,
diese Thundermentals, also allein schon irgendwie releasen
Branchen, Get Clean Code, Lesbarkeit und so, solange dann
auch ein Mensch mitarbeiten muss und im Moment sieht es ja nicht
so aus, dass da, dass jemals kein Mensch mehr zumindest bei
großen komplexen Software Projekten mitarbeiten muss,
werden diese Skills halt auch immer wichtig bleiben und
alleine auch schon um zu überprüfen, dass.
Ob eine KI so was eventuell auch eingehalten hat?
Und dazu kommen natürlich so Sachen, die wir vorhin schon
erwähnt haben, wie Debugging oder Code Reviews.
Es wird immer mehr Code generiert, aber irgendjemand
muss sicherstellen, dass der Code korrekt ist, dass er
richtig ist, dass er die Aufgaben erfüllt, auch so ein
bisschen so ein Mentoring wird in Zukunft wichtig und ist auch
bei der Vergangenheit wichtig, das heißt, erfahrene Leute
müssen die Jüngeren mitnehmen, aber.
Aber genauso muss ich vielleicht jetzt in Zukunft auch mit KI
tools Partnern, gerade wenn ki tools irgendwie ganz viel
boilerplate Code auswerfen, muss ich sicherstellen, dass die
Qualität stimmt, dass das ganze Wartbar ist.
Es gibt im Moment ganz viele Beispiele von Developern, die im
Internet beschreiben, dass sie immer sehr erfolgreich und
schnell gestartet sind mit solchen in Anführungsstrichen
wahlcoding Tools, aber dann. Alle zu einem Punkt gekommen
sind, wo sie nicht mehr weiter gekommen sind, wo irgendwie der
Code sich nicht mehr durch einfaches prompten erweitern
ließ oder ergänzen ließ, weil halt einfach die Komplexität so
weit angestiegen ist, dass diese Tools einfach nicht mehr zurecht
kommen, insbesondere weil sie vielleicht nicht konsistent nach
einem bestimmten wartbaren Architektur Pattern vorgegangen
sind. Und vielleicht brauchen wir in
Zukunft dann. Auch entweder weiterhin oder
noch speziellere Architektur Patterns, die es den KI Tools
ermöglichen, auch komplexe und große Anwendungen noch zu
überblicken und um Funktionalitäten zu ergänzen.
Das wird spannend. Das dürfte jetzt ein bisschen
ab, aber vielleicht bauen wir irgendwann mal unsere
Architektur Patterns so oder unsere Wartbarkeit oder so einen
Clean Code so. Dass wir sagen, wenn wir das in
der und der Art und Weise bauen, dann kommt die KI auch besser
damit klar. Das fände ich, fände ich mal,
für eine eigene Folge. Einen interessanten
Gedankenansatz muss ich mir auch noch mal Gedanken zu machen, ob
das überhaupt einen Unterschied macht, aber.
Ich glaube, was ganz wichtig ist.
Viele Dinge, die wir gerade beschrieben haben, die hat man
in der Vergangenheit vielleicht so in den ersten Jahren seiner
professionellen Karriere gelernt.
Wenn ich vielleicht auch. Aus der Uni kommen habe ich ein
paar Sachen gelernt. Ich habe vielleicht schon mal
von Git gehört, habe irgendwie mal eine Architektur
kennengelernt, aber in den ersten Jahren meiner
Berufskarriere habe ich dann andere Skills dazugelernt, die
ich halt brauche, um später vielleicht mal Senior Developer
oder Engineering Manager zu werden, aber einige von den
Dingen werden jetzt so ein bisschen schon vorausgesetzt und
das hatte ich ganz am Anfang gesagt, in manchen
Stellenausschreibungen steht ja, das ist eine Junior Position,
aber wir erwarten irgendwie 2 bis 3 Jahre Berufserfahrung und.
Und da muss man jetzt tatsächlich auch reinschauen und
gucken, was sind so ein bisschen so die Dinge, in die ich auch
vielleicht neben meinem Studium, solange es noch nicht Teil der
Curricula wird, investieren muss, um halt auch qualifiziert
zu sein für diese Position, weil ich glaube, ich werde mich jetzt
nicht mehr in Zukunft damit qualifizieren, dass ich sagen
kann, hier, ich habe hier diese 5. 5 Softwareprojekte umgesetzt
weil irgendwie mittlerweile in Anführungsstrichen Wipe Coder,
das vielleicht in 3 Tagen nachholen können.
Das heißt ich kann jetzt auch nicht mehr einfach referenzieren
hier irgendwie meine 5 Gitter Projekte, guck mal, ich habe
hier eigene Software geschrieben, sondern ich muss
dann auch zeigen, dass ich. Verstehe wie diese Software
funktioniert, was der Code macht, in welcher Architektur
diese Software aufgebaut ist. Und das sind Dinge, die ich
vielleicht früher eher on the Job gelernt habe, die jetzt aber
teilweise einstellungsvoraussetzungen.
Sind es wird auch spannend, wie das vielleicht irgendwie die
Interviews der Zukunft so ein bisschen beeinflusst.
Also ich würde jetzt wahrscheinlich, wenn ich jetzt
ein Interview mit einem Coder führen würde, auch
wahrscheinlich eher ja, also a schauen, ob die Person überhaupt
schon sowas wie KI im Alltag einsetzt und wie gut sie darin
ist. Also dieser Skill, den wir
vorhin gesagt haben, diese. Diese KI oder diese Intuition
also vielleicht, anstatt dass man irgendwie eine Whiteboard,
irgendwie einen Sortierungsalgorithmus aufbauen
lässt. Vielleicht mal so eine Live
Prompting Challenge oder sowas bauen.
Also ich will gar nicht, dass ich bei so einem irgendwas Vibe
Code, sondern ich will sehen, wie arbeitest du mit Code, wie
lässt du dir vielleicht auch irgendwas erklären oder oder
kannst du mir nachher auch erklären warum da Code
entstanden ist? Mir ist gar nicht so wichtig
warum ob du den selber getippt hast oder ob den eine KI eine KI
gebaut hast. Aber kannst du erklären wie es
zu irgendwas gekommen ist? Also es war ja noch nie.
Einfacher zu programmieren. Deswegen hattest du vorhin
gesagt, ist das auch gar nicht mehr so viel wert.
Irgendwie zu sagen, komm, ich habe hier irgendwas gebaut, es
war aber auch noch nie einfacher, Programmieren zu
lernen, du kannst ja auch mit ki dir jeden Code, den du siehst,
jederzeit erklären lassen oder nochmal umschreiben lassen, oder
du hast ja die Menge an wissen da draußen und die
Möglichkeiten, das Programmieren selber zu lernen, war ja noch
nie einfacher und deswegen glaube ich auch, dass A.
Sich das Interview ändern wird für Junior Developer hinzu,
diesen ganzen Skills, die wir jetzt beschrieben haben.
Aber B du natürlich auch eine deutlich höhere Konkurrenz hast,
weil es eben noch noch nie einfacher war all diese Sachen
zu lernen und weil es immer noch ein attraktiver und mega cooler
Job ist, ist für uns allen ja auch irgendwo ein Hobby und da
kommen auf jeden Fall viele Leute auch auf den Arbeitsmarkt
und deswegen das, was du auch gerade sagst, so das was du
früher als Basics in der Juniorrolle gelernt hast, musst
du jetzt vielleicht heute schon mitbringen und vielleicht auch
in so einem Interview beweisen, dass du.
Diese alten Skills, diese Fundamentals, dass du die halt
drauf hast und vielleicht auch so Dinge, die eine KI nicht
kann, also soft Skills, kritisches denken,
Kollaboration, all solche Themen.
Ja, dann lass uns mal ganz kurz darüber sprechen, was man machen
kann, um guter Junior Developer zu werden.
Vielleicht ein paar Stichpunkte, einfach nur, um auch den
Zuhörerinnen und Zuhörern noch mal mitzugeben, was können Sie
jetzt tun, um sich halt auch zu qualifizieren für diese Jobs der
Zukunft, und vielleicht können wir auch.
Ein 2 Sachen noch ein bisschen tiefer eingehen.
Ich glaube, es ist ganz wichtig, dass wir schauen, dass wir
tatsächlich immer noch Software entwickeln können, ohne KI
einzusetzen, dass wir das auch weiterhin lernen, dass wir
gemeinsam mit KI, wird es gerade gesagt, ich kann mir von KI
Software erklären lassen, das heißt, ich sollte nicht die KI
für mich die Software schreiben lassen, sondern mit der KI die
Software schreiben. Weiterhin mit erfahrenen
Kolleginnen und Kollegen arbeiten, Mentoren suchen, die
mir auch wirklich diese Fundamentals auch beibringen
können. Und wenn ich das alles gemacht
habe, schadet es natürlich auch nicht, irgendwie sichtbar zu
sein, dass man in Open Source Projekten kollaboriert, dass man
selber Projekte auf github hat, das heißt, alle diese Dinge sind
weiterhin wichtig, sie waren in der Vergangenheit wichtig, aber
jetzt in Zukunft, wo es weniger darum geht, schnell zu lernen,
wie man viel Coach schreibt und. Sondern noch stärker auf diese
eher komplexeren Themen einzugehen, muss man natürlich
ein bisschen auch investieren in die Zeit, diese Dinge auch zu
erlernen. Ja, zusammenfassender Bau dein
Fundament auf ohne zu cheaten. Ich meine, es ist ja auch
natürlich nie verlockender gewesen, so Skills wie wie
benutze ich die Chrome developer Tools?
Einfach zu skippen, weil ich ja erst mal versuchen kann, so
lange eine KI zu prompen, bis die nicht mehr weiterkommt.
Also auch wirklich hier Grundlagen verstehen, hatten wir
schon gesagt, aber schalt doch mal ab und zu den Co Piloten aus
und guck mal ob du noch immer was selber machen kannst oder
selbst wenn nicht, dann sicherstellen, dass du jedes
Snippet irgendwie verstehst. Was damit aufgenommen wird, also
dieses Fundament ist glaube ich wichtiger denn je, aber auch
verlockender denn je, dass sich eben nicht richtig aufzubauen
und ich muss nicht wissen wie 1 und 01 und Nullen von links nach
rechts fliegen, aber. Aber halt, diese ganzen Themen,
die wir heute schon gesagt haben.
Ein zweites Thema ist immer, was ich finde, was einen guten
Junior Developer ausmacht, ist die richtigen Fragen zu stellen,
viel sich Einzuregen zu fragen. Man sagt auch manchmal so
Juniors stellen dumme Fragen in Anführungszeichen, gibt es dumme
Fragen weiß ich nicht, aber frische Leute die ins Projekt
kommen helfen auch oft so blinde Flecken auf zu.
Decken also, das trägt A natürlich auch zu einer
Diversität von so einem Team und auch aber auch natürlich zu
einer Diversität von Lösungsansätzen bei.
Das ist auch was, was so rein datengetriebene KI Modelle nicht
gut können, aber einfach auch viele Fragen stellen, sich viel
erklären zu lassen und einfach auch vielleicht auch Dinge zu
hinterfragen, die schon immer irgendwie als gegeben gesetzt
waren und wenn ich irgendwie einen Junior mal wirklich wenn
ich als Junior einen Ziele wirklich mal erklären lassen
muss, warum machen wir das eigentlich so und so?
Dann kommt man vielleicht auch selber schon mal als Senior an
den Punkt, wo man sagt, ja warum eigentlich.
Gute Frage und das ist auch so ein bisschen immer schon der
Grund gewesen, warum wir Juniors brauchen, wir haben ja schon
mal, glaube ich, vor ein paar folgen irgendwie gesprochen, es
hat noch nie jemand Junior Developer wegen ihrer krassen
Tech oder programming Skills eingestellt, sondern weil man
glaubt, dass man sie mal irgendwann in diese Richtung
formen kann, aber. Aber natürlich auch wegen dieser
kulturellen Aspekte. Und die wird natürlich gerade in
Zeiten, wo diese Coding Skills so n bisschen auch in Konkurrenz
mit KI generiertem Code stehen, immer wichtiger.
Ja, und manche gehen ja jetzt raus und sagen, in Zukunft
werden wir alle Software developer, weil die Tools
machen. Das ist uns total einfach.
Wir können jetzt Vibe Coden, aber ich glaube, das sind am
Ende häufig keine Software Developer sind Software Creator,
das heißt ich kann irgendwie ein Stück Software erzeugen, aber
das heißt nicht, dass ich. Software Developer und erst
recht kein Software engineer bin, weil ich natürlich diese
ganzen Fundamentals nicht beherrsche und in der
professionellen Softwareentwicklung reicht es
nicht, dass ich irgendwie ein bisschen prompten kann, da
gehören, wir haben ja gerade jetzt über eine halbe Stunde
drüber gesprochen, ganz viele andere Dinge dazu, von daher
diese Aussage, in Zukunft werden wir alle Software developer
sein. Wage ich zu hinterfragen.
Ich würde es eher Software Creator nennen, das heißt immer
mehr von uns werden die Möglichkeit haben Software zu
erzeugen, auch irgendwie die eigenen Eltern, die Kinder,
verwandte. Ich glaube jetzt der richtige
Zeitpunkt denen auch zu sagen, Hey schaut euch mal diese
modernen Tools an, ihr könnt auch mal euer eigenes Projekt
einfach mal an einem Wochenende umsetzen, ohne
Softwareentwickler sein zu müssen.
Das bedeutet noch lange nicht, dass die euch dann den Job
wegnehmen. In der professionellen
Arbeitswelt, wo ganz andere Dinge erforderlich sind.
Finde ich wie gesagt Software Creators ja auch nur weil ich
mit irgendwie einer KI ein Bild erzeugen kann, bin ich ja kein
Designer und natürlich manchmal ist das völlig valide, es gibt
Crazy Businesses die nur auf Excel basieren oder auf
irgendwelchen No co Tools und natürlich kann ich, wie du
gerade gesagt hast, am Wochenende mit Cloud wie eine
App bauen, aber das macht mich ja nicht zu einem Engineer.
Ja ne, also klar ist das auch so ne vielleicht Gate keepen wir ja
auch so ein bisschen diese developer Welt, aber ich glaube
zum Besseren hin also ich glaube für bessere Qualität und ich
glaube also ich finde das gut, dass das du gerade irgendwie
unter. Unterschieden hast zwischen
jemandem, der wirklich domänenwissen hat, der debuggen
kann und jemanden, der einfach nur irgendwas erstellen kann,
weil diese Software Creator dann ist ja eigentlich KI nichts
anderes als ein yet another Low Coach Tool, das haben wir auch
schon mal gesprochen, es ist es ermöglicht mehr Leuten einen
Computer dazu zu bringen was zu bauen oder bestimmte Dinge
Sachen zu machen, das ist toll, aber du bist dann halt was
anderes als ein Software developer, sondern du bist
irgendwie da. Ist halt noch ein Unterschied
was diese echte Profession macht und.
Und jemanden, der jetzt einfach durch durch Tools auch ein
ähnliches Ergebnis erzeugen kann.
Aber eben wenn man tief reinguckt und wenn man in die
Details geht und wenn man darauf irgendwie eine skalierbare große
Infrastruktur haben will, eben doch noch ein paar Skills
mitbringen muss und das sind vielleicht auch genau die
Skills, die Journal Develop heute schon sehr früh lernen und
dann im Laufe ihrer Karriere ausbauen.
Ja, und es sind auch vielleicht genau die Dinge, die vielen von
uns auch einfach Spaß machen. Wir haben halt auch immer ein
bisschen im Netz geschaut und da gibt es halt auch Gegenstimmen,
da gibt es Leute, die sagen Wenn am Ende das Einzige für mich in
der Zukunft sein wird, irgendeine KI zu prompten, dann
will ich vielleicht gar kein Softwareentwickler mehr sein.
Bei mir macht es Spaß, wirklich komplexe Probleme über Code zu
lösen, analytisch zu denken, Sachen zu abstrahieren, abstrakt
mathematisch zu denken und wirklich diese technischen
Aufgaben zu erfüllen. Und wenn ich dann am Ende
irgendwie im Wettbewerb stehe zu irgendwelchen Leuten, die
vibecoden prompton, dann ist das vielleicht auch nicht mehr der
der richtige Job für mich. Ja, das ist ja vor allem auch
ein Skill, den ich, den ich super schnell lernen kann.
Also es ist ja nicht so, dass ich sagen kann, ich muss jetzt 3
Jahre studieren, um gut prompton zu lernen, sondern da bin ich ja
in in Konkurrenz mit allen, die sich mal irgendwie eine Stunde
auf Youtube irgendwie einen Workshop oder ein Tutorial zu zu
prompton oder sowas angeschaut haben.
Es gibt Leute, die haben noch nie mit KI irgendwas gebaut.
Die haben nach einem Tag den Dreh raus und wissen, was
funktioniert, was gut funktioniert, was schlecht
funktioniert, kommen nach einer Woche an die Grenzen und merken
dann, dass es schon einen Unterschied macht, ob ich
bestimmte einen bestimmten Kontext mitgebe und so, und dann
können ja alle das Gleiche, es gibt ja niemanden, der bedeutend
besser prompten kann als alle anderen und deswegen ist das
vielleicht auch einfach ein Karriereumfeld, in dem du dich
nicht unbedingt bewegen willst, wenn es nur darum geht, kann ich
ein kleines bisschen besser prompten als jemand anders.
Gut, dann fassen wir mal zusammen und schauen wir, was
wir aus der ganzen Folge mitnehmen können.
Wir haben also gehört, Juniorrollen sind nicht tot, ich
glaube, die öffentliche Wahrnehmung, die.
Betrügt da ein bisschen, insbesondere natürlich viel, was
irgendwie im Internet unterwegs ist.
Ganz stark irgendwie. Us Tech Bubble fokussiert ist
und die können es sich vielleicht teilweise auch
einfach leisten nur Seniors zu heiern, weil sie dann anderen
Firmen einfach die ganzen Leute wegnehmen.
Die müssen dann vielleicht gar nicht in die Juniors
investieren, aber ich glaube gerade.
In Deutschland und vor allen Dingen in der Breite ist die
Realität nicht so, dass Junior rollen tot sind, sondern sie
verändern sich. Und wenn man die entsprechenden
Fundamentals mitbringt, mit der Intuition, wie KI Tools
funktionieren, dann bleibt man auch weiterhin am Jobmarkt
gefragt. Ja, also Junior rollen gehen
nicht weg, aber wie ich. Immer wenn eine neue Welle an
Technologie kommt, wenn sich irgendwas verändert, werden sie
transformiert. Ich meine, heute braucht auch
keiner mehr die Skills, irgendwelche Lochkarten zu
beschreiben, sondern es ist, glaube ich ganz normal, dass
sich, wenn neue Technologien kommen, ob es jetzt die
Dampfmaschine oder Kii gibt, dass Berufseinsteigende sich
leicht anderen Skills widmen müssen und natürlich auch so ein
bisschen sich irgendwie diesem anpassen müssen und deswegen.
Find ich eigentlich ganz spannend, dass du hast vorhin so
n bisschen gesagt, es gibt diese, es gibt diese, wie hast
du es glaub ich genannt durch die Software Creator und sowas
und vielleicht werden unsere werden unsere Junior Developer.
Auch Ärzte so was wie Junior Engineers, weil sie, weil wir
schon viel früher wirklich diesen Engineering Teil vom
Software Engineering, dass die Wagen, die Architektur und so
weiter brauchen und dieses reine Junior Developers, also das
reine Tippen von Code, ja, das wird sich verändern, aber
berufseinsteigende und Rollen für Berufseinsteigende.
Die werden ja nicht weggehen. Das wird sich und auch diese
Hose schenken werden mit ganz viel Quellcode sich beschäftigen
müssen, mit leicht anderen Themen, aber das ist, glaube
ich, völlig normal. Es gibt aber trotzdem noch
Juniors, ob wir sie in Zukunft Junior Developer oder Junior
Engineers nennen, das weiß ich nicht, das sind natürlich andere
Skills nötig, aber dieses Early in Career, das braucht man immer
brauchen, das wird man auch weiterhin brauchen, allein schon
um die Pipeline zu sichern, um irgendwann mal Seniors draus zu
machen, denn wenn ich nur Seniors einstelle, dann
verlassen wir irgendwann mein Unternehmen und ich habe keine.
Keinen mehr in der in Anführungszeichen Pipeline, aber
das wird es ganz klar weiterhin geben, nur halt mit leicht
anderen Fähigkeiten und Skills, die jetzt halt benötigt werden.
In der aktuellen Marktlage. Und tatsächlich, in dieser
aktuellen Welle von immer mehr KI Tools ist es wichtig, diese
KI Tools wirklich als Werkzeug zu benutzen, als Lernwerkzeug
und nicht als Krücke, um Dinge zu überdecken, die man selber
nicht kann. Das heißt die Skills selber zu
laufen sollte man weiterhin erwerben.
Die muss man erwerben, um im Berufsleben erfolgreich zu sein.
Und am Ende wird man nicht ersetzt werden durch
irgendwelche Vibe Coder, sondern gegebenenfalls durch Kolleginnen
und Kollegen, die die Fundamentals haben, aber
gleichzeitig viel Code erzeugen können, weil sie diese KI Tools
beherrschen. Wie sieht es denn bei euch aus,
so an die Community? Welche Skills oder Ki Skills
fehlen euch so im Team? Also habt ihr.
Habt ihr da das, wo ihr sagt, Ey, das sind wirklich, da haben
wir Skills, die uns fehlen, wo wir diese KI Intuition, die wir
vorhin so ein bisschen genannt haben, glaube ich im Team noch
nicht haben. Und viel wichtiger ist
eigentlich, wie fördert ihr Berufseinsteigende, gibt es bei
euch, also merkt ihr schon, dass diese Junior Developer Rolle
weggeht oder dass sich das transformiert, wie wir so ein
bisschen zu dem Fazit gesagt haben, hinzu so einer
Engineering Rolle das. Das wäre für uns mal super
spannend, weil man liest ganz ganz viel von irgendwelchen
übergefundeten Silicon Valley Start UPS, da liest man ganz
viel, was sich gut klickt in irgendwelchen Artikeln oder in
irgendwelchen Youtube Videos oder was sagt ihr denn, wie ist
das denn bei euch im Unternehmen müsst ihr das Unternehmen ja
auch gar nicht nennen, aber lasst uns das mal gerne wissen,
wie ihr diese Transformation beobachtet, was ihr da
feststellt, gerne in den Kommentaren, entweder wenn ihr
uns auf youtube schaut, in den youtube Kommentaren auf Spotify
kann man auch Kommentare hinterlassen oder.
Oder wenn ihr sagt, weiß ich nicht, ob ich das öffentlich
machen will, können wir auch gerne privat per e Mail
besprechen. Es gibt auch eine E Mail Adresse
in der Beschreibung, lasst uns gerne mal wissen wie das bei
euch in euren Firmen und in euren Teams aussieht, dass wir
so ein bisschen einen breiteren Überblick dazu bekommen, wie es
denn in der Realität ist und nicht irgendwie auf 230 gut
klickende youtube Videos. Und die Insights davon können
wir dann ja auch gerne noch mal nächste Folge mitnehmen und
zusammenfassen. Und wenn euch die Folge
weitergebracht hat, wenn sie euch gefallen hat, lasst uns
gerne eine positive Bewertung da.
Das könnt ihr auch auf Spotify, auf Apple Podcast und auf
youtube gerne machen, mit einem Daumen nach oben und natürlich,
wir hatten es vorhin erwähnt, unsere Lieblingssektion im
Podcast ist immer die Kaffeesektion, auch ihr könnt
uns gerne einen Kaffee ausgeben, ihr findet in den Shownotes den
Link zu buy mir coffee. Dann seid auch nächste Woche
wieder dabei, wenn eine neue Folge vom to do Cast, dem
Developer Podcast, ansteht. Jeden Montag gibt es eine neue
Folge, immer abwechselnd, einmal fassen wir die News der letzten
2 Wochen zusammen und einmal gibt es ein von uns
aufbereitetes recherchiertes Thema wie dieses hier.
Wir freuen uns also sehr, wenn ihr auch nächsten Montag wieder
mit dabei seid und bis dahin schreibt viel Code, habt eine
gute Zeit und bis ganz bald. Bis dann.