Wir haben bei uns in der Organisationseinheit, wo ich unterwegs bin, nicht einmal ansatzweise so ein System. Mein Kollege und ich sind ca. mittlerweile 12-15 Jahre im Bereich C# unterwegs. Schwerpunkt ist Organisationsprogrammierung, Systembetreuung, Cloud-Architektur etc. Einen Stempel "Senior-Entwickler" habe ich nicht. Gefühlt aber vor drei bis vier Jahren habe ich das erreicht. Verschiedene Architekturansätze, Guidelines, deine / eure Konferenzen haben meinen Blick deutlich erweitert und mich weiterentwickelt. Was ich vor zehn Jahren als nervig und überflüssig empfand, finde ich heute super und sehr wichtig. Ab einem gewissen Zeitpunkt hat man eine "Reife" erreicht, die sich auch wiederspiegelt. Wenn ein junger Mensch bereits diese Reife und Verständnis hat, kann er deutlich weiter sein als ältere. Und somit auch den Status "Senior" für sich beanspruchen.
Hey, ja dieses Gefühl der Erfahrung kenne ich auch :) Problem bei der eigenen Einschätzung nach Junior/Senior ist halt oft, das 90% der Entwickler sich für Seniors halten, aber nur 20 % es wirklich sind - leider ein sehr subjektives Thema! Gruß David
Das Thema hat auch mit der eigenen Einschätzung zu tun, ich beobachte auch viele Entwickler, die gerade mal mit ein paar Projekte gemacht haben und sich als senor sehen, deine Idee mit der Baseline finde ich insofern gut, weil man immer wieder mal herausgefordert wird und die Seniorität kontinuierlich in Frage stellt, cooles Thema, mega Video!
Moin. Ich habe mal in einem Unternehmen als Berufseinsteiger gearbeitet, in dem die Seniors sozusagen erweiterte Rechte und Pflichten hatten. Sie durften ihre Arbeitspakete stückeln und an Juniors delegieren, standen aber in der Pflicht, die Ergebnisse aber auch abzunehmen und die Verantwortung dafür zu tragen. War sehr gut für den Wissenstransfer, so dass ich nach zwei Jahren sicher komplette Projekte durchführen konnte vom Workshop mit dem Kunden bis zur Go-Live Betreuung. Der Aufstieg zum Senior (zumindest auf dem Papier) blieb mir allerdings verwehrt, nachdem die Firma verkauft worden ist und die neuen Herren die Entwicklungsabteilung als reinen Kostenfaktor betrachtet haben, da ja kein messbarer Umsatz erzeugt wird. Manchmal muss man halt auch das Unternehmen wechseln, um Senior zu werden.
Ich bin als Junior gleichzeitig mit einem Senior in ein wirklich gutes Team eingestiegen. Das war mein erster Job als Dev und ich hatte wirklich noch absolut keine Ahnung. Nach 3 Monaten gab mir unsere damalige PO ein Ticket des Senior Devs, weil er nach 5 Wochen immer noch keine Lösung hatte. Das war reines Frontendticket. Es hat 2 Tage gedauert, bis ich nicht nur den Quatsch entfernt habe, den er geschrieben hat, sondern auch eine funktionierende Lösung präsentieren konnte. Unnötig zu sagen, dass der "Senior" 3 Wochen später gekündigt wurde. Im Endeffekt bedeuten die Labels wirklich nur wenig, außer fürs Gehalt. Wir haben Seniors, die sind richtig gut und verdienen die Bezeichnung, wir haben Seniors (gehabt), bei denen ich eher die Hände überm Kopf zusammenschlage, wir haben aber auch Juniors, die andere komplett outperformen, aber aufgrund fehlender Berufserfahrung (nicht coding Erfahrung) so einkategorisiert werden.
Ein guter Entwickler arbeitet mit anderen zusammen. Bei euch geht etwas komplett schief. Ein Konkurrenzkampf zwischen Entwickler ist der Super-GAU. Wenn ich ein PO hätte, der so etwas macht, würde ich kündigen. Glaub mir, irgendwann kommt der Entwickler, der dich raus kickt.
Hab meine Ausbildung erfolgreich abgeschlossen und bewerbe mich seit Monaten auf Junior- und Traineestellen, weil ich leider ein Ausbildungsunternehmen erwischt habe welches nicht ausgebildet hat sondern eher die Leute als billige arbeitskraft für anderweitige Tätigkeiten genutzt hat. Anstatt ein Unternehmen sagt der Junge hat die Zähne zusammen gebissen hat sich eigenständig all das wissen für die Ausbildung angeeignet und hat dann auch noch bestanden, wird man abgelehnt, weil man nicht den TechStack mitbringt den man ja noch lernen kann vor allem bei Stellen als Trainee oder Junior. Aber dann groß schreien das wir Fachkräftemangel haben und über 200.000 nicht besetzte IT-Stellen... Keine Ahnung wieso die Menschlichkeit immer mehr abnimmt und man Neulingen die es lernen wollen keine Chance bietet.
Ich verstehe das ganze Thema, aber ich als jemand der 10 Jahre private IT-Erfahrung mitbringt und "noch" vermutlich eher als Junior gehandhabt werde (solche Begriffe sind bei uns unerwünscht) fühle mich dann ein bisschen so als würde meine private Erfahrung abgewertet werden. Dabei habe ich ja genauso wir Unternehmen kleine und große Projekte gemacht vom Twitter Bot zum Betriebssystem über ne Webverwaltung im Homelab. Das tut manchmal weh aber ich überspiel das, die Leute meinen es ja auch nicht böse
Also wenn ich das mal als nicht entwickler (dafür ambitionierter hobby c#ler), beleuchte gibts aber auch bei einigen Firmen schon vorher einige schwierigkeiten. Als ich mich damals nach der Schule bei einer Firma für den Fachinformatiker in Systemintegration beworben habe, hat mich der Ausbilder bzw. könnte auch einer aus der Personalabteilung gewesen sein. Der hat mich erst einmal gefragt, was ich denn schon alles könnte. Das ich zwar mich zu dem zeitpunkt anfänglich mit Datenbanken, SQL usw. beschäftigt habe war dem letztendlich nicht genug. Da fragt man sich hinterher, wieso eigentlich eine Ausbildung machen, wenn man vorher schon alle können soll. Oder ist die Aufgabe eines Ausbildungsbetriebes nicht auch die Ausbildung eines Menschen zu fördern?
Hey, ja natürlich das ist es, bei Azubis frage ich aber auch regelmäßig ab, wie viel derjenige sich in seiner Freizeit schon damit beschäftigt hat - finde das nicht verwerflich, sondern zeigt wie stark das Interesse bei demjenigen für die IT ist :) Was war Deine Antwort? Gruß David
@@DavidTielke grundsätzlich sollte das aber mMn erst an zweiter Stelle stehen. Der Beginn einer Ausbildung ist oft der Beginn eines neuen Weges, der einem nicht verwehrt werden sollte, weil man den Weg nicht schon halb gelaufen ist. In unserer Ausbildungsgruppe (Telekom, da sind das dann 10-15 in der gleichen Fachrichtung am Standort, die gemeinsam starten) hatten wir auch mehrere, die vorher noch nie was in der Richtung gemacht haben, das aber super spannend fanden. Klar, bei mir half damals das zuvor abgebrochene Informatikstudium, aber das hat vermutlich nur dafür gesorgt, dass ich in einer bestimmten Abteilung gelandet bin, nicht, dass ich überhaupt darf.
Bring es dir selbst bei. Als dev vergeude nicht Jahre mit Studium. Mach Praktika, strahle mit Können, statt grauen Theorien. Abschlüsse werden immer uninteressanter. Bei uns zählt auch was schon an Wissen da ist. Eine Basisaffinität gehört schon dazu. Die Ausbilder in Unternehmen haben eh selbst kaum Zeit, oder nehmen sie sich nicht. Graue Lehrtheorie reicht heute nicht mehr, ausser bei kleinen, regionalen Unternehmen als PC Techniker.
Senior und Junior oder Silver und Gold oder Platin sind am Ende alles nur Labels. Wertschätzung in der Arbeit finde ich am wichtigsten. Ob das jetzt eine Person ist die neu im Projekt ist und sich besonders schnell einarbeiten konnte oder eine Person die schon lange dabei ist und an vielen Fronten gleichzeitig geholfen hat. Wenn die Wertschätzung stimmt, ist der Titel egal. Am Ende ist die Softwareentwicklung auch immer eine Diskussion. Und es gibt wesentlich mehr als das stumpfe schreiben von Software. Man zieht als Team immer an einem Strang und niemand hat mehr zu sagen als eine andere Person. Insbesondere technische Entscheidungen werden vorab besprochen und Code gegenseitig reviewed. Da gibt es weder die absolute Entscheidungsgewalt, noch ein richtig oder falsch. Kurzum: nenn mich Junior, nenn mich Senior, nenn mich wie du willst. Ich mache meine Arbeit und arbeite mit und für das Team
Wir haben noch Senior Developer aber wir unterscheiden nicht mehr zwischen Junior und Senior. Mein Titel ist einfach "Developer", wie inzwischen jeder neu angestellter Entwickler. Wir wissen halt, dass neue Entwickler erstmal eingearbeitet werden müssen und machen dies dementsprechend auch. So gibt es halt keine merkwürdigen Blicke von Kollegen, wenn neue Mitarbeiter als "Senior" eingestellt werden aber man selbst noch "Junior" ist, obwohl man schon länger im Unternehmen arbeitet und die Prozesse und das Tooling schon recht gut kennt. Ich finde diese Einteilung auch nicht wirklich sinnvoll. Wie du schon sagtest, sieht es halt merkwürdig aus, wenn ein Senior zu einem Junior zurückgestuft wird, nur weil er jetzt mit einer anderen Sprache arbeitet, die er noch nicht so gut beherrscht. Die Einstufung wird also von vielen eher als eine Einbahnstraße gesehen. Einmal Senior, immer Senior. Und ja, ich kenne auch Senior Developer, die zwar schon 20+ Jahre als Entwickler tätig sind aber nach ihrem Studium stehengeblieben sind und sich nicht weitergebildet haben. Die haben dann z.B. von SOLID noch nie etwas gehört.
Hey, bin total bei Dir - schön das Du das auch so siehst. Finde die Leistungsklassen zur Qualitätssteigerung aber total in Ordnung, diese Junior/Senior-Sache ist halt doof... Gruß David
Ich sehe das anders David. Ich bin ein Senior-Entwickler und im Vergleich mit meinem früheren Ich (als Junior-Software-Entwickler) bringe ich eine Menge wertvolles Wissen "drum herum mit" das nicht technologiespezifisch ist. D. h. würde ich von heute auf Morgen statt .Net Java machen, würde ich mich immer noch nicht als Silver oder Junior Entwickler sehen. Warum nicht nicht? Fangen wir an bei den (1) Anforderungen, ich weiß wie es ist mit Kunden zu diskutieren, weiß wo ich Kunden widersprechen kann, wann ich mich auch mal in interne Themen eimischen darf, und wann ich besser schweige, ich kann gut Anforderungen spezifizieren z. B. in Jira oder anderen Tools, Wireframes erstellen, hab oft gute UI-Ideen usw. Andere Themen sind (2) Projekt-Management, (3) Teams/Teamzusammenhalt/Arbeit (z. B. Teamphasen -> hab alle erlebt (inkl. heftige Stormingphasen) und hab darin meine Erfahrungen gesammelt). Ich war Junior, Senior, Technical Lead in Projekten und hab einfach eine Menge Erfahrung in all den unterschiedlichen (positiven wie negativen) Phasen/Momenten von Projekten. D. h. mit dem Wissen werde ich IMMER eine Bereicherung für Projekte sein. Aber auch bei technischen. Ich kenne allgemeine Themen und tückische Problemchen die unabhängig von Technologien sind. Beispiele: Probleme mit Regions (z. B. unterschiedliche Dezimaltrennzeichen), die ganze Zeitzonen-Thematik (kann meistens die Umrechnungen locker im Kopf machen), Zeichenkodierung (kann auswendig den Unterschied zwischen ISO 852 und ASCI, ANSI und UTF-16 sagen), kenne auch "ältere" Themen wie SOAP, XML (xPath) die auch heute noch immer wieder in aktuellen Projekten z. B. bei Schnittstellen aktuell sind, hab viel Erfahrung mit Deployment, man denke auch an Authentifizierung wie OIDC, usw. diese "allgemeinen" Themen hast du immer ein Projekten und ein Senior kennt diese eher als ein junger Junior. Und weiter kann ich Full Stack: vom Docker-Container, Windows Server, paar DBs, Backend und Frontend (wieviele können Memory Leaks in den DevTools aufspüren?). Und in den meisten Projekten hast du heute mindestens Docker, eine relationale DB und ein Frontend (zumindest bei uns). So dass ich eigentlich nie "blank" anfange. Auch liebe ich die Konsole, statt Klikibunti, d. h. ich kenne die cmd, die Powershell, die bash und komm damit zurecht, ich liebe sie sogar. D. h. ich kann GitHub-Action Pipes schreiben, oder in Jenkins... und auch VI geht natürlich und ich drehe nicht ab, weil ich ein paar Tastaturkürzel kennen muss. Übrigens, ein weiteres Argument: ich habe mich intensiv mit Lerntechniken beschäftigt und würde behaupten dass ich mit meinen 40 Jahren fast alle 20jährigen schlage, wenn es darum geht mich in neue Themen einzuarbeiten. Change Management, Veränderungen, ich habe so viele Wandlungen mitgemacht... Daher, ich würde mich nicht auf einen Silver oder Junior zurückstufen lassen. Vielleicht irgendwann wenn ich 60 bin und senil werde :)
Du beschreibst das aber genau so wie David es nicht meint und kritisiert. Es geht nicht um das früher im zeitlichen Sinne sondern um die Skills die du für ein Projekt mitbringst. Wenn es jemanden gibt der eine schnellere Auffassungsgabe hat als du, dabei aber Anfang 20 ist, dann könnte er auf deinen heutigen Wissensstand auch schon früher sein. Demnach könnte er für das aktuelle Projekt genauso wertvoll wie du und demnach auch Senior sein. Es hilft dir sicher wenn du schon viel gemacht und erlebt hast, aber das bedeutet eben nur, dass du besser sein wirst als jemand der dir in Potenzial und Fähigkeitwn ähnlich ist aber dem die Berufserfahrung fehlt.
Nun, für mich gibt es noch einige andere Eigenschaften: Ein Senior ist sich seiner in ihn gesetzten *Verantwortung* bewusst und entsprechend bereit sein, diese zu übernehmen. Ein Senior sollte selbstkritisch sein und nicht nach Ausreden suchen ( die „Dreckstools“, die blöden Anwender“, …) sondern sich und sein Handeln hinterfragen und zu verbessern - Ständig! Ein Senior ist gewandt in der Anwendung seiner Werkzeuge und setzt diese weise ein. Er hat ein ausgeprägtes Gespür für den richtigen, aber auch falschen Weg. Ein Senior strebt nach ständiger Verbesserung seiner Kenntnisse und sollte sich ständig Weiterentwickeln (tägliche Code- Katas) und offen für Neues sein - und er sollte dabei durchaus kritisch sein, und stets fair und auch *selbstkritisch* handeln. Das sind für mich Kriterien eines guten Seniors und ich versuche mich daran zu orientieren…
du hast absolut Recht mit der Unterscheidung Gefahr oder nicht für das Projekt... sollte jeder erfahrene Etwickler beurteilen können. Ich habe selbst mehrfach die Domain gewechselt und verstehe das man da klein bei geben sollte... Domain ist prio 1
Jobtitel waren bei uns immer so dermaßen beliebig, dass wir gewitzelt haben und uns selbst Titel ausgedacht. (Aber dann natürlich nicht umgesetzt, war ja nur ein Scherz.) Mein Favorit: Superior Developer. Egal wie gut du bist, ich bin Superior.
Ich kenne die Aufteilung eher als „Junior Dev“, „Dev“ und „Senior Dev“. Die meisten sind nach paar Jahren einfach Entwickler, also kein Junior mehr, bleiben aber auch das ganze Leben auf dem Level, also kein Senior. Dieses Thema Baseline klingt sehr technisch. Ein guter .Net Entwickler wäre demnach immer ein Junior, wenn er zB plötzlich Java entwickeln muss. Seniorigkeit beinhaltet aber auch Softskills (zb wie rede ich mit dem Kunden) und Basistechnologien (zb AuthN/AuthZ) die sprachenübergreifend gelten. Das kommt zumindest im Video gar nicht vor. Den Entwickler und den Senior Entwickler trennt in meinen Augen dann vor allem die Verantwortung. Der Senior treibt Projekte eigenständig voran, arbeitet teamübergreifend, führt Projekte fachlich und hat dabei immer das große Ganze im Blick. Darum werden viele gute Entwickler nie Senior, weil sie das nicht wollen oder nicht können.
Ich finde diese Fokussierung auf die Frage, ob man alle in einem Projekt eingesetzten Frameworks beherrscht, etwas verengend und oberflächlich. Ich bin auf meiner aktuellen Position definitiv senior, wäre aber nach der Definition im Video in fast jedem anderen Unternehmen erstmal junior, da es eigentlich nie vorkommt, dass man alle Frameworks kennt, dazu sind es einfach zu viele. Dennoch finde ich mich nicht vergleichbar mit einem junior, der direkt von der Uni kommt. Erfahrung ist goldwert und der Sinn dafür, was eine gute Architektur im Großen und Clean Code im Kleinen ausmacht, ist nicht abhängig von Frameworks und entsprechenden Kenntnissen.
Dem würde ich zu 100% zustimmen. Neben der Beherrschung des Tech-Stacks gibt es so viele Punkte, die einen guten Entwickler ausmachen, z.B.: - relevante Domainexpertise - Verständnis der relevanten Stakeholder, deren Rolle Bedürfnisse und Bedeutung - Verständnis der Projekt/Organisationsstrukturen und Rahmenbedingung - die Fähigkeit und Bereitschaft Wissen zu teilen und weiterzugeben - Fähigkeit zum Erkennen von Schwachstellen im Entwicklungsprozess und/oder der Kommunikation etc. und die Übernahme von Verantwortung/Initiative zur Verbesserung - Offenheit, Neugier und der Wille sich weitrrzuentwickeln und dazuzulernen - Gelassenheit und Stresstoleranz, Toleranz und ein Auge für den Rest des Team, wenn es mal Druck gibt - [...] Viele der oben genannten Punkte sind sicherlich positiv mit Projekterfahrung korreliert - mehr aber auch nicht. Insbesondere bei sehr senioren Entwicklern können auch mal Motivation und Neugier nachlassen und im extremfall sogar der Anschluss an moderne Entwicklungsprozesse/Technologien verloren gehen. Dazu kommt, dass insgesamt natürlich nicht jeder Entwickler alles davon abdecken muss sondern es reicht, dass das Team dies abdeckt. Insgesamt wäre ich mit der Klassifizierung in "Senior" und "Junior" aber mehr noch mit der Einteilung in "Projektrisiko" und "Projektnutzen" sehr zurückhaltend. Ein demütiger intelligenter, kommunikationsstarker Junior, der sich einarbeitet, motiviert ist und nachfragt ist u.U. weniger ein "Projektrisiko" als ein von sich überzeugter, sturer erfahrener Kollege, der nicht erkennt, dass Teile seiner Erfahrung/Lösungsmuster aus einem oder mehreren Projekten nicht auf die neue Umgebung übertragbar sind, der endlose Diskussionen über nicht essentielle Designaspekte anzettelt (a la "Leerzeichen" versus "Tabulatoren"), seine Kollegen demotiviert und bei der Teilung von Wissen mauert ... Was die Baseline angeht: Im Optimalfall fühlen sich zu je 50% das Team und der "neue" Mitarbeiter dafür verantwortlich, diese so schnell wie möglich zu erreichen.
Bei uns wird dabei gar nicht unterschieden - ist aber auch eine recht kleine und merkwürdig organisierte Firma. Ich finde es aber nicht schlimm, ich finde, untereinander sollten die Kollegen sich ihren "Status" selber erarbeiten oder beweisen können. Und finanziell sollte eine Firma dann auch bereit sein, gute Leistungen auch besser zu bezahlen - am besten von sich aus. Was ich zu dem Thema am besten in Erinnerung habe: Ein alter C++-Entwickler, hat über 20 Jahre in dem Job gearbeitet. Kam aus einem Elektrotechnik-Studium, hat dann in der Firma ein Projekt übernommen und seit dem nichts anderes gemacht. Das Projekt war/ist ziemlich groß, bewegt viel Geld, ist allerdings auch ein heilloses Chaos, das vor jedem Update für sehr viele Probleme gesorgt hat. Außerdem war es technologisch locker 10-20 Jahre veraltet und weil es so unbeherrschbar wurde, wurden viele Funktionen in viele C#-Programme (.NET 2.0, selten auch 4.5) ausgelagert, die XML-Dateien entgegen genommen und mit XML-Dateien geantwortet haben. Ihm wurde immer sehr viel Erfahrung nachgesagt, in dem einen Projekt mag das auch stimmen, ich bin aber der Meinung, dass die 20 Jahre nur wenig wert sind. Ich will ihm den katastrophalen Zustand des Projektes (gab's schon vor ihm) nicht zuschreiben, aber er hat die 20 Jahre eben nur diese eine Art zu Arbeiten kennen gelernt, die heute so viele Probleme verursacht. Bei neuen C++- oder sogar C#-Projekten hätte er mMn. den Stand eines Juniors. Er war allerdings der Typ Mensch, der sich ganz einschätzen kann und hat selber zugegeben, dass er eigentlich nur dieses Projekt kannte, das war ganz angenehm. Ein anderer Kollege, der das selbe Projekt noch länger begleitet hat, dabei aber nicht aktiv mitentwickelt, sondern nur zwischen Tür und Angel Architektur- und Design-Entscheidungen getroffen hat, der war von seiner Erfahrung überzeugt und das - da waren wir uns eigentlich alle einig - war ein wirkliches Problem. Und von der Sorte gab es noch mehr in der Firma, z.B. einer, der mir mit einer unerschütterlichen Zuversicht erklärt hat, warum ein Switch mir 30 im Code völlig unabhängigen Cases mit je über 1000 Zeilen (es ging um Dokumenten-Druck) besser sei, als z.B. ein geeignetes Pattern und je Dokument eine in sich abgeschlossene Klasse. Auch er hat nie etwas anderes kennen gelernt, als dieses eine Projekt, in dem solche riesigen chaotischen Dateien normal waren. Das heißt nicht, dass die alle dumm sind - sind sie nicht - aber sie haben zu lange immer das gleiche gesehen und glauben, dass das so gut ist. Für mich hängt Erfahrung weniger mit der Zeit, sondern mit der Anzahl verschiedener Projekte zusammen. Wer viele Projekte kennengelernt, ihren Aufbau und die Folgen daraus gesehen hat, hat mMn. langfristig sehr viel mehr davon. Und natürlich aktuelles KnowHow und aktuelle Technologien, aber darauf wird ja scheinbar nur sehr wenig Wert gelegt, wie ich bei einem aktuellen Kunden sehr eindrucksvoll bewundern "darf".
grad zum letzten Part: in einer Ausbildung oder einem Bachelorstudium ist das, was man lernt, nicht eine Programmiersprache, oder mehrere, sondern "wie lerne ich eine neue Sprache?", "wie lerne ich neue Methodiken?", "wie erarbeite ich mir eine sinnvolle Architektur, die ich selbst in 10+ Jahren spontan wieder aufrufen und daran weiterarbeiten kann?" und so weiter. und das ist es, was gute Entwickler (alle Angestellten in der IT eigentlich) ausmacht: Sich selbst weiterentwickeln und die richtigen Technologien gewinnbringend einsetzen.
@@Todbrecher Das klingt nach einem Erfahrungsbericht? Dann hast/hattest Du großes Glück mit deiner Ausbildung. Bei mir war es eher: Hier Aufgabe XY, wenn Du Fragen hast, dann frag. Das galt aber nur für mich so, weil ich vorher schon programmieren konnte, die anderen Azubis saßen teilweise im Support ...
@@Palladin007 das sind die gesammelten Erfahrungen, die ich selbst und durch Bekannte in der IT erlebt habe, in den letzten rund 8 Jahren. für das "Wie lerne ich" ist die Uni bzw die BErufsschule zuständig, gerade in den IT-Fächern bleibt eh keine Zeit, großartig Tools und Sprachen zu erlernen. ich hatte mit Sicherheit nicht großes Glück, sondern du mit deiner Ausbildungsfirma oder eben Abteilung pech. in der IT ist "mach mal, wenn du nich weiter kommst frag mich" tatsächlich der sinnvollste Weg, um das "Wie lerne ich" in der Praxis zu üben. im Beruf später muss man das dann ja schon können, und dann gibts keinen mehr, der dir was vorkaut.
In meiner Firma gibt's keine offizielle Trennung zwischen Senior und Junior. Ich selbst sehe mich definitiv mit 27 nicht als Junior. Für mich halt Senior und Junior nicht zwingend was mit Technologie sondern eher was mit tiefergehendem Wissen zu tun. Wie z.B kenn der Dev, Designpattern, schreibt er Nachhaltige Software, kennt er sich mit Caching, Autorisierung, Authentifizierung etc. aus. Wenn man tiefergehendes breites Wissen in solchen Bereichen hat ist man für mich jedenfalls Senior. Noch ein Zeichen ist bist du als Entwickler eher der, der andere um Hilfe fragt oder kommen eher andere zu dir
Hey Nicolai, sehr interessant, die Diskussion mit dem "anderen Helfen oder suchst Du hilfe" hatte ich heute in einem Kundenworkshop, finde ich einen sehr interessanten Ansatz :) Gruß David
Es wäre interessant, wenn Du ein Video für Entwickler machst, die Senioren sind aber keine Erfahrung im IT Bereich haben, aber sie sammeln wollen bzw. die Kenntnisse erwerben wollen. Gibt es für die überhaupt eine Chance in der Branche? Wenn ja wo?
Ich finde, eine solche Zweiteilung greift zu kurz und demütigt gar erfahrendere Entwickler, die aber noch keine Seniorität erreicht haben. Junior ist ein Einsteiger, ein Rookie. Das sollte man auch wirklich nur für solche verwenden, um allen im Team zu sagen, schaut mal auf den drauf, mentort ihn. Niemand mit mehr als zwei bis drei Jahren Praxiserfahrung nach seiner welch auch immer gearteten Ausbildung sollte noch als Junior bezeichnet werden. Für mich ergibt da eher die Einteilung Junior, Regular und Senior Sinn. Der Regular ist genau das, jemand, der im laufenden Projekt nicht die Base-Line zum Senior überschritten hat, das kann ggf. auch wechseln, ist aber ein passenderes Framing. Der Senior ist dann aber wirklich schon ein alter Hase, das schließt eben nicht nur die Implementierungsskills ein, sondern eben auch den Umfang der selbstständigen Arbeit und Erarbeitung von neuen Themen, als auch Softskills in Sachen Team-Mentoring und Vorbildfunktion, als auch die Bereitschaft zur Übernahme von Verantwortungen über die reine Entwicklung hinaus mit ein.
Wer entscheidet dann über die eingesetzten Technologien, wenn ein neues Projekt startet? Wenn die Gold-Entwickler entscheiden dürfen, dann wird es keinen Fortschritt geben. Warum sollte ich mir das antun, dass ich mich für neue Dinge entscheide, wenn ich dann zurück gestuft werde. Die neuen, die mit neuen Ideen kommen werden dann wohl ausgebremst.
Was mir in deinem Video fehlt sind Technologie unabhängige skills, wie z.b. Umgang mit Konflikten im Team oder effektive Einarbeitung in unbekannte Domänen. Hat es einen Grund warum du so etwas nicht mit auf nimmst?
@@DavidTielke damit untergräbst du jetzt alle Frauen die genau das Gegenteil von deiner Aussage sind! Meine Freundin würde dir die Ohren langziehen. Denk also beim nächsten mal dran 😉 Content war wieder super 👍
Noch ein Aspekt, es gibt Unternehmen, die von den Amis die Hierarchie kopiert haben mit Junior, Middle, Senor und Principal developer, diese Modell ist statisch und kann die dynamische Natur der Entwicklungsbranche nicht gegenhalten, deshalb ist die Idee mit dem herabstufen oder aufsteigen lassen fair und zeitgemäß, zumal die Leute auch wenn sie auf einer Stelle sind meistens in Komfortzonen residieren und Herausforderungen eher nicht wollen... :)
Es ist schwierig zu sehen. Ein „Senior“ hat halt schon viel Erlebt und kann auf Situationen reagieren, wie es ein „Junior“ nicht kann. Auch wenn dieser nur kurz in einem Projekt ist. Ich habe es erlebt, das es viele „Programmierer“ (Ich schreibe bewusst) die lange dabei sind, das System in und auswendig kennen und dennoch, keine Entwickler sind, weil sie einfach nur den Code um Fragmente Erweitern und damit für eine Entropie die ihres gleichen sucht, erzeugen. Es gibt Seniors, die das Falsche vermitteln, weil sie es seit Jahren und Jahrzehnten so gewohnt sind so zu arbeiten und es nicht ändern wollen. Deswegen würde ich diese Unterscheidung generell nicht machen wollen. Ein gutes Team ergänzt sich und steht nicht im Konkurrenzkampf. Auch Seniors können von den Jungen lernen. Wobei es anders rum mehr anzutreffen ist. Es gibt „Juniors“ die haben die neuen Sprachfeatures drauf und sind in der Programmiersprache sehr sehr gut. Was teilweise auch klar ist, lernen sie auch nicht immer die alten Sprachfeatures. Der Mehrwert ist einzig ein Team was sich ergänzt.
Wenn man sich nicht im Code auskennt ist "Code um Fragmente Erweitern und damit für eine Entropie die ihres gleichen sucht, erzeugen" ja vielleicht die eigene Entropie des Nichtverstehens? Was viele Juniors leider ueberhaupt nicht verstehen ist die Kosten-Nutzen analyse von Software Design
@@llothar68 Das ist natürlich ein Argument. Aber ich denke nicht, dass Junior Entwickler die Kosten-Nutzenrechnung nicht verstehen. Das ist eine Sache der Intepretation. Kosten Nutzen, für mal eben schnell schnell ist enorm hoch. Beim ersten Hinschauen. Auf der Langen Bank, kann so eine kleine schnell, schnell Änderung fatale Folgen auf die Kosten und den Nutzen haben. Weil diese Änderung ein Nachspiel hat, wo alle anderen Änderungen drauf basieren. Macht man es vernünftig, dauert es eben mal nicht schnell schnell, sondern etwas länger. Wird aber so im Code umgesetzt, ohne die Entropie bewusst zu erhöhen. (man wird nie alle Fälle finden) Dadurch kann der Aufwand in der Zukunft minimiert werden. Nichts ist schlimmer als ein Programmcode, wenn man sich nicht an Regeln hält. Wenn man keine Regeln hat, wird jeder Programmierer so programmieren wie er will. Bis hin, das nur derjenige, der den Code erstellt hat, diesen sauber lesen kann. Wenn man Glück hat. Viele verstehen ihren eigenen Code schon 6 Monate später nicht mehr. Wenn es saubere Strukturen gibt, und gängige Praktiken eingehalten werden, wird jeder Entwickler, der diesen Code sieht schneller lesen und verstehen können. In dem Buch Entwurfsmuster von Kopf bis Fuß, fand ich den Vergleich recht passend: Der eine bestellt in der Imbisbude Pommes rot/weiß Der andere Pommes Schranke Wieder ein anderer Pommes mit Ketschup und Mayo. Alle meinen das Selbe, reden aber was völlig unterschiedliches. Diese einfache und simple Beispiel zeigt, wie wichtig seine sauber definierte Gundlage ist. Ja jeder kann es machen wie er will. Leider.
Ich selbst bin Senior Developer. Wobei mir persönlich der Titel primär nicht wichtig ist. Qualität lässt sich nicht zwangsläufig an Titeln messen. In der Realität sind die Titel mehr Marketingrelevant, weil die Arbeitswelt eben darauf konditioniert ist Personen zu klassifizieren und levelbasiert Gahaltsranges und andere Vergünstigungen daran zu koppeln. Und ob nun jemand in einem Unternehmen befördert wird hängt in erster Linie nicht von seinen Fähigkeiten, egal ob Soft oder Hardskills ab sondern vom Nasenfaktor und/oder dem jeweiligen Vorgesetzten, denn Beförderungskriterien in Unternehmen sind meist sehr interpretierbar bzw. Wenn 99% der Beförderungskriterien erfüllt sind, wird eine Nicht-Beförderung mit dem fehlenden 1% begründet oder damit, dass dann das Verhältnis nicht mehr stimmt. Für mich gibt es gut oder schlecht. Und wie im realen Leben macht es die Mischung. Ein 'erfahrener' Entwickler, ich z.B. hab im Frontend bis vor zwei Jahren noch mit Swing entwickelt, kann z.B von einem jüngeren z.B. in Angular/Typescript lernen während der jüngere/unerfahrene von mir z.B. in punkto Herangehensweise, Methodik profitieren kann.
Das sehe ich etwas anders, denn aus mehreren Gründen, ist so ein erfahrungsbasiertes Modell in der Praxis besser. Natürlich kann man einen C++ Entwickler mit 25 Jahren Berufserfahrung nicht in einem Java-Projekt als Senior Entwickler anpreisen, genausowenig wie man einen Ohrenarzt einfach mal als Zahnarzt einsetzen kann. Dennoch ist die Erfahrung im jeweiligen Bereich aber nun einmal da und das muss sich natürlich auch im Gehalt ebenso wie in Verantwortung, Pflichten und Rechten widerspiegeln. Dass ein Senior wieder zu einem Junior zurückgestuft wird, habe ich noch nie erlebt und das würde vermutlich auch in den allermeisten Fällen zu einer Kündigung führen oder noch schlimmer zu interner Sabotage. Ein "degradierter" Entwickler verliert ja nicht automatisch seine Fähigkeiten und kann viel Schaden anrichten, ganz ohne dass man ihm Vorsatz nachweisen könnte. Mit Gold/Silber dürfte es sich ähnlich verhalten, wenn man nicht klar eine solche "Baseline" daran knüpft, also etwa Gold Technologie X / Silber Techologie Y. Aber wer würde denn fortlaufend überprüfen können, wer welche Baseline erfüllt oder nicht erfüllt? Wenn jemand ein Doktortitel hat, wird der ja auch nicht wieder aberkannt, weil der Träger nach 20 Jahren anderer Tätigenkeiten in seinem ursprünglichen Bereich kaum noch auf dem Niveau eines Studenten ist. Im Übrigen dürfte Silber/Gold ein Vokabular sein, mit dem Kunden nichts anfangen können. Wenn ein Projekt ausgeschrieben wird, will man i.d.R. Senior Entwickler darin haben. Nur Senioren sind aber i.d.R. nicht machbar und nur Junioren werden vom Kunden nicht akzeptiert, also trifft man sich in der Mitte. Hat man keine Senioren für die Zielplattform kann man u.U. etwas schummeln, wenn man gute Junioren hat, denen man dann Senioren aus "verwandten" Bereichen zur Seite stellt. Denn zum einen kommt es meist nicht gut an, 20 jährige Mitarbeiter als teure Senioren zu präsentieren und zum anderen ist Erfahrung ja nicht nur für eine konkrete Technologie relevant. So könnte etwa der erfahrene C++ Entwickler trotzdem schon Schwächen im Archtekturkonzept erkennen, die der Java-Junior nicht gesehen hat, obwohl das Projekt mit Java realisiert werden soll. Senior vs. Junior bedeutet im Übrigen nicht, dass Seniorentwickler automatisch immer besseren Code schreiben, auch wenn das meistens so sein wird. Ein Grund kann dabei beispielsweise Betriebsblindheit sein, etwa weil der Senior wegen fehlendem Austausch mit Kollegen sich ein fehlerhaftes Vorgehen angeeignet hat oder elegante neuere Alternative einfach nicht kennt. Der Bereich Software und Tools ist heute überdies so komplex, dass es praktisch unmöglich ist, überall auf dem Laufenden zu bleiben, insbesondere, wenn noch Arbeit "nebenbei" erledigt werden muss. So entsteht bei Junioren der Eindruck, dass der Senior sein Geld eigentlich nicht wert ist, weil er nicht einmal dies oder jenes kann. Dazu kommt noch, dass nicht jeder neue Trend bzw. neues Framework automatisch besser ist. Einen bewährten und funktionierden Ansatz aufzugeben, will wohl überlegt sein. Lange Rede, kurzer Sinn, Senior / Junior an Erfahrung zu knüpften halte ich durchaus für einen validen Ansatz, aber immer unter der Maßgabe, junge Talente nicht zu ignorieren und mögliche Betriebsblindheit von Senioren nicht auszuschließen.
Zu deiner letzten Frage im Bezug auf "Senior-Entwickler der nichts drauf hatte": Ja, das habe ich leider ziemlich heftig erlebt. Wir haben mehrere Teams, die in verschiedenen Software-Projekten arbeiten. Für einen Großauftrag wurden notdürftig verschiedene Leute aus verschiedenen Teams abgestellt. Es dauerte nicht lang, da hatte unser gemischtes Team bereits eine Deployment-Chain errichtet, die Architektur geplant und erste Tests für TDD implementiert. 2 Monate später stieß dann die angekündigte Verstärkung hinzu. (2 Senior Entwickler aus dem C++ Bereich). Wir mussten die beiden erstmal in GIT einlernen, da sie nur SVN kannten... Gitlab CI/CD war folglich Raketenwissenschaft... Wir haben den beiden keinen Vorwurf gemacht, konnten die erste Meilenstein Deadline allerdings nicht einhalten... Die beiden haben über 15 Jahre in ihrer Tech-Bubble arbeitet. Ich hab mir daher angewohnt, viele Infos aus der Ferne zu einzuholen ... Ich hab zum Beispiel noch nie mit SCRUM gearbeitet (nur Kanban), aber ich weiß, was das ist. (Durch deine Videos als Einstieg und danach weiter vertieft) ... Es ist nicht verkehrt solche Konzepte zu kennen und irgendwie auch unsere Aufgabe als Entwickler, stets ein offenes Ohr zu haben. Man muss ja nicht direkt Experte sein, es nur im besten Fall schon mal gehört haben und einordnen können. Ich hab z.B. auch noch nie etwas mit Blockchain entwickelt, versteh aber das Prinzip. Sollte jetzt irgendwann mal etwas in die Richtung kommen, dann hab ich keine Angst mehr :D So. Genug aus der Praxis. Ich muss weiter coden. Wünsch dir was. LG
1:25 ich wünschte das wär wirklich so Problem was ich sehe ist eher folgendes: Seniors sind so tief in der Domäne und Technik, dass nur sie ihren Code verstehen 😂 Der Code funktioniert und ist performant, aber Clean ist er nicht unbedingt und wirkt für andere Entwickler, die nicht so tief mit den Details vertraut sind, wie schwarze Magie.
Da fehlt einfach KISS. Immer die einfachste Lösung. Wenn du etwas nicht brauchst, benutzte es nicht. Baue keine generische Lösungen für nichtvorhande Anforderungen.
ich bin jetzt nun ja im Bereich Devops angesiedelt, da ist das grundsätzlich nicht soo prägant bisher (ich bin zum Beispiel einfach nur "Devops Engineer", was anderes gibt es bei uns nicht). Das Prinzip Silver und Gold löst exakt mein Problem mit Junior und Senior, und da bin ich auch genau deiner Meinung, warum ich Jr. und Sr. ncht so gut gewählt finde.
Warum nur Schwarz / Weiß? Es gibt doch eigentlich Junior Entwickler, Entwickler, Senior Entwickler. Also zumindest bei uns in der Firma. Nach 2 Jahren ungefähr ist man normaler Entwickler und dann steigt man nie zum Senior auf :D Zumindest hadert es da noch bei uns... Nachtrag: Würde man mich in irgendeiner Weise herunterstufen, würde ich direkt den Arbeitgeber wechseln. Dann lieber gar nicht erst aufsteigen. Dann würde ich allerdings ebenfalls wechseln. Sollte ich vielleicht mal...
Grundsätzlich gebe ich dir Recht, aber meiner Meinung nach, ist dieses Leistungsprinzip auch sehr toxisch und spiegelt nicht die gesamte Wirklichkeit. Ein 20-jähriger Single-Entwickler hat nun mal nicht die selben Lebenshaltungskosten, wie ein 35-jähriger Familienvater mit 2 Kindern. Vor allem hat er nicht die gleiche Zeit, sich in neue Technologien neu einzuarbeiten. Nach deiner Logik müsste jeder talentierte 20-jährige mehr verdienen, als ein 35-jähriger, der vielleicht bisschen abgehängt wurde? Ist das fair - kann man sicherlich gut darüber streiten. Aber meiner Meinung nach ist das genau der Hauptgrund, wieso so extrem viele Entwickler mit 40 Burnout haben. Das Berufsbild ist geistig extrem fordernd und ein 40-jähriger hat oft nicht die geistige Aufnahmefähigkeit wie ein frischer Uniabgänger. Wollen wir dann Richter und Kassierer auch nach Kunden bezahlen? Oder Polizisten nach Knöllchen? Weiß nicht, ob das so ein toller Trend ist, den du hier aufzeigst. In dieser Welt will ich nicht leben - aber das muss jeder für sich wissen!
Moin, da hast du etwas ganz falsch verstanden - ich habe bei der Kritik extra noch gesagt, dass es KEIN Gehaltsmodell ist - folglich sollte nicht der Junior- Seniorstatus über das Gehalt entscheiden, sondern andere Dinge und die liegen außerhalb des Scopes dieses Videos. Die Unterteilung Junior / Senior oder wie in meinem Fall Silver/Gold ist immo einig und alleine dazu da, die Entwickler in "Leistungsklassen" einzustufen um die Softwarequalität zu steigern und hat rein gar nichts mit der Bezahlung zu tun. Von daher stimme ich die bei deinen Aussagen was die Bezahlung angeht total zu! Gruß David
Ich bin Vater von 3 Kinder, in der Zeit hatte ich auch nicht die Zeit. Jetzt wo meine Kinder ihre eigene Wege gehen, habe ich mehr Zeit für mein Beruf und habe als Senior Entwickler vieles dazu gelernt, weil es mir auch Spaß macht. Bin in meinem Team der Techleader, kann sehr gut bei Entscheidungen mitsprechen oder kann Proaktiv Verbesserungen vorschlagen. Die Junior Entwickler sind auf dem neuesten Entwicklung Stack aber es fehlt ihnen die Erfahrungen in allen Gebieten.
Ich denke, dass Erfahrung eine riesen große Rolle spielt. Man bekommt mit der Zeit ein Gefühl für die Technologie und fühlt sich nicht ganz so verloren. Zeit ist da wirklich relativ. Hatte schon Momente, wo ein Studententeam aus 4 Leuten im Praxissemester für eine Aufgabe knapp 5 Monate gebraucht haben und zwei Vollzeit-Entwickler das Ding nochmal in 2 Wochen neu entwickeln mussten, weil deren Ansatz kompletter Bullshit war. Keiner hat die dafür verurteilt, aber wirtschaftlich war das ein Totalausfall... Es gibt aber auch Entwickler, die gar keine Lust haben sich weiter zu bilden (das kann man auch in der Arbeitszeit) und 20 Jahre Schema F fahren und dann am Ende gar nicht mehr klar kommen, wenn man zum Beispiel in einem anderen Projekt nen Buildserver mit Docker nutzt. Alles schon erlebt. Ich glaub das hat auch viel mit der inneren Einstellung zu tun. Ob jetzt ein 20 Jähriger wirklich die kinderlose Zeit nutzt, oder lieber Battlefield spielt ist doch gar nicht gesagt :D
@@DavidTielke Die Softwareentwicklung und deren Entwickler haben schon gewisse Ähnlichkeiten zum Sport und Fahrerklassen. Wettbewerb, Perfektionismus, Fehler, ganz viel Teamwork, unvorhersehbare Ereignisse usw. Jede Runde eine neue Herausforderung.
Ich bin seit 6 Jahren in einer Firma als Developer tätig und wäre dort niemals zum Senior ernannt worden. (gibt es bei uns irgendwie nicht ...). Jetzt hatte ich gestern ein Interview und ich wurde direkt als Senior kategorisiert. Sieht natürlich im Lebenslauf nicer aus, erhöht allerdings auch den Druck ... :D
ich war von anfang an als "Programmierer" eingestellt, plötzlich war ich dann Full Stack Senior Developer (war plötzlich der Titel des Jahresgesprächsformulars)
In Spanien Direkteinstieg als Señor Developer.
Hahaha
Wir haben bei uns in der Organisationseinheit, wo ich unterwegs bin, nicht einmal ansatzweise so ein System. Mein Kollege und ich sind ca. mittlerweile 12-15 Jahre im Bereich C# unterwegs. Schwerpunkt ist Organisationsprogrammierung, Systembetreuung, Cloud-Architektur etc.
Einen Stempel "Senior-Entwickler" habe ich nicht. Gefühlt aber vor drei bis vier Jahren habe ich das erreicht. Verschiedene Architekturansätze, Guidelines, deine / eure Konferenzen haben meinen Blick deutlich erweitert und mich weiterentwickelt. Was ich vor zehn Jahren als nervig und überflüssig empfand, finde ich heute super und sehr wichtig. Ab einem gewissen Zeitpunkt hat man eine "Reife" erreicht, die sich auch wiederspiegelt. Wenn ein junger Mensch bereits diese Reife und Verständnis hat, kann er deutlich weiter sein als ältere. Und somit auch den Status "Senior" für sich beanspruchen.
Hey,
ja dieses Gefühl der Erfahrung kenne ich auch :)
Problem bei der eigenen Einschätzung nach Junior/Senior ist halt oft, das 90% der Entwickler sich für Seniors halten, aber nur 20 % es wirklich sind - leider ein sehr subjektives Thema!
Gruß David
Das Thema hat auch mit der eigenen Einschätzung zu tun, ich beobachte auch viele Entwickler, die gerade mal mit ein paar Projekte gemacht haben und sich als senor sehen, deine Idee mit der Baseline finde ich insofern gut, weil man immer wieder mal herausgefordert wird und die Seniorität kontinuierlich in Frage stellt, cooles Thema, mega Video!
Moin. Ich habe mal in einem Unternehmen als Berufseinsteiger gearbeitet, in dem die Seniors sozusagen erweiterte Rechte und Pflichten hatten. Sie durften ihre Arbeitspakete stückeln und an Juniors delegieren, standen aber in der Pflicht, die Ergebnisse aber auch abzunehmen und die Verantwortung dafür zu tragen. War sehr gut für den Wissenstransfer, so dass ich nach zwei Jahren sicher komplette Projekte durchführen konnte vom Workshop mit dem Kunden bis zur Go-Live Betreuung.
Der Aufstieg zum Senior (zumindest auf dem Papier) blieb mir allerdings verwehrt, nachdem die Firma verkauft worden ist und die neuen Herren die Entwicklungsabteilung als reinen Kostenfaktor betrachtet haben, da ja kein messbarer Umsatz erzeugt wird.
Manchmal muss man halt auch das Unternehmen wechseln, um Senior zu werden.
Alleine schon der Thumbnail ist super. Danke für die interessanten Gedanken zum Senior Dev
Hey,
sehr gerne - finde das Thumbnail auch klasse, schön das es dir auch gefällt!
Gruß David
Ich bin als Junior gleichzeitig mit einem Senior in ein wirklich gutes Team eingestiegen. Das war mein erster Job als Dev und ich hatte wirklich noch absolut keine Ahnung. Nach 3 Monaten gab mir unsere damalige PO ein Ticket des Senior Devs, weil er nach 5 Wochen immer noch keine Lösung hatte. Das war reines Frontendticket. Es hat 2 Tage gedauert, bis ich nicht nur den Quatsch entfernt habe, den er geschrieben hat, sondern auch eine funktionierende Lösung präsentieren konnte. Unnötig zu sagen, dass der "Senior" 3 Wochen später gekündigt wurde.
Im Endeffekt bedeuten die Labels wirklich nur wenig, außer fürs Gehalt. Wir haben Seniors, die sind richtig gut und verdienen die Bezeichnung, wir haben Seniors (gehabt), bei denen ich eher die Hände überm Kopf zusammenschlage, wir haben aber auch Juniors, die andere komplett outperformen, aber aufgrund fehlender Berufserfahrung (nicht coding Erfahrung) so einkategorisiert werden.
Komische Firma. Dann war der Dev von vornherein kacke? Wofür war er denn eingestellt? Du bist dann der nächste der geht, wenn du 1 Ticket failst? 😅😅
Ein guter Entwickler arbeitet mit anderen zusammen. Bei euch geht etwas komplett schief. Ein Konkurrenzkampf zwischen Entwickler ist der Super-GAU. Wenn ich ein PO hätte, der so etwas macht, würde ich kündigen.
Glaub mir, irgendwann kommt der Entwickler, der dich raus kickt.
Hab meine Ausbildung erfolgreich abgeschlossen und bewerbe mich seit Monaten auf Junior- und Traineestellen, weil ich leider ein Ausbildungsunternehmen erwischt habe welches nicht ausgebildet hat sondern eher die Leute als billige arbeitskraft für anderweitige Tätigkeiten genutzt hat.
Anstatt ein Unternehmen sagt der Junge hat die Zähne zusammen gebissen hat sich eigenständig all das wissen für die Ausbildung angeeignet und hat dann auch noch bestanden, wird man abgelehnt, weil man nicht den TechStack mitbringt den man ja noch lernen kann vor allem bei Stellen als Trainee oder Junior.
Aber dann groß schreien das wir Fachkräftemangel haben und über 200.000 nicht besetzte IT-Stellen...
Keine Ahnung wieso die Menschlichkeit immer mehr abnimmt und man Neulingen die es lernen wollen keine Chance bietet.
Ich verstehe das ganze Thema, aber ich als jemand der 10 Jahre private IT-Erfahrung mitbringt und "noch" vermutlich eher als Junior gehandhabt werde (solche Begriffe sind bei uns unerwünscht) fühle mich dann ein bisschen so als würde meine private Erfahrung abgewertet werden. Dabei habe ich ja genauso wir Unternehmen kleine und große Projekte gemacht vom Twitter Bot zum Betriebssystem über ne Webverwaltung im Homelab. Das tut manchmal weh aber ich überspiel das, die Leute meinen es ja auch nicht böse
Also wenn ich das mal als nicht entwickler (dafür ambitionierter hobby c#ler), beleuchte gibts aber auch bei einigen Firmen schon vorher einige schwierigkeiten. Als ich mich damals nach der Schule bei einer Firma für den Fachinformatiker in Systemintegration beworben habe, hat mich der Ausbilder bzw. könnte auch einer aus der Personalabteilung gewesen sein. Der hat mich erst einmal gefragt, was ich denn schon alles könnte. Das ich zwar mich zu dem zeitpunkt anfänglich mit Datenbanken, SQL usw. beschäftigt habe war dem letztendlich nicht genug. Da fragt man sich hinterher, wieso eigentlich eine Ausbildung machen, wenn man vorher schon alle können soll. Oder ist die Aufgabe eines Ausbildungsbetriebes nicht auch die Ausbildung eines Menschen zu fördern?
Hey,
ja natürlich das ist es, bei Azubis frage ich aber auch regelmäßig ab, wie viel derjenige sich in seiner Freizeit schon damit beschäftigt hat - finde das nicht verwerflich, sondern zeigt wie stark das Interesse bei demjenigen für die IT ist :)
Was war Deine Antwort?
Gruß David
@@DavidTielke grundsätzlich sollte das aber mMn erst an zweiter Stelle stehen. Der Beginn einer Ausbildung ist oft der Beginn eines neuen Weges, der einem nicht verwehrt werden sollte, weil man den Weg nicht schon halb gelaufen ist.
In unserer Ausbildungsgruppe (Telekom, da sind das dann 10-15 in der gleichen Fachrichtung am Standort, die gemeinsam starten) hatten wir auch mehrere, die vorher noch nie was in der Richtung gemacht haben, das aber super spannend fanden.
Klar, bei mir half damals das zuvor abgebrochene Informatikstudium, aber das hat vermutlich nur dafür gesorgt, dass ich in einer bestimmten Abteilung gelandet bin, nicht, dass ich überhaupt darf.
Bring es dir selbst bei. Als dev vergeude nicht Jahre mit Studium. Mach Praktika, strahle mit Können, statt grauen Theorien. Abschlüsse werden immer uninteressanter. Bei uns zählt auch was schon an Wissen da ist. Eine Basisaffinität gehört schon dazu. Die Ausbilder in Unternehmen haben eh selbst kaum Zeit, oder nehmen sie sich nicht. Graue Lehrtheorie reicht heute nicht mehr, ausser bei kleinen, regionalen Unternehmen als PC Techniker.
@@rookieew ich bring es mir doch schon seit 2020 bei. Momentan vertiefe ich die Spieleentwicklung mit unity und Modellierung mit Blender.
Senior und Junior oder Silver und Gold oder Platin sind am Ende alles nur Labels.
Wertschätzung in der Arbeit finde ich am wichtigsten. Ob das jetzt eine Person ist die neu im Projekt ist und sich besonders schnell einarbeiten konnte oder eine Person die schon lange dabei ist und an vielen Fronten gleichzeitig geholfen hat. Wenn die Wertschätzung stimmt, ist der Titel egal.
Am Ende ist die Softwareentwicklung auch immer eine Diskussion. Und es gibt wesentlich mehr als das stumpfe schreiben von Software. Man zieht als Team immer an einem Strang und niemand hat mehr zu sagen als eine andere Person. Insbesondere technische Entscheidungen werden vorab besprochen und Code gegenseitig reviewed. Da gibt es weder die absolute Entscheidungsgewalt, noch ein richtig oder falsch.
Kurzum: nenn mich Junior, nenn mich Senior, nenn mich wie du willst. Ich mache meine Arbeit und arbeite mit und für das Team
Wertschätzung ist zwar ganz nett, ich bevorzuge Geld. Und das kommt mit Titeln.
Wir haben noch Senior Developer aber wir unterscheiden nicht mehr zwischen Junior und Senior. Mein Titel ist einfach "Developer", wie inzwischen jeder neu angestellter Entwickler. Wir wissen halt, dass neue Entwickler erstmal eingearbeitet werden müssen und machen dies dementsprechend auch. So gibt es halt keine merkwürdigen Blicke von Kollegen, wenn neue Mitarbeiter als "Senior" eingestellt werden aber man selbst noch "Junior" ist, obwohl man schon länger im Unternehmen arbeitet und die Prozesse und das Tooling schon recht gut kennt.
Ich finde diese Einteilung auch nicht wirklich sinnvoll. Wie du schon sagtest, sieht es halt merkwürdig aus, wenn ein Senior zu einem Junior zurückgestuft wird, nur weil er jetzt mit einer anderen Sprache arbeitet, die er noch nicht so gut beherrscht. Die Einstufung wird also von vielen eher als eine Einbahnstraße gesehen. Einmal Senior, immer Senior. Und ja, ich kenne auch Senior Developer, die zwar schon 20+ Jahre als Entwickler tätig sind aber nach ihrem Studium stehengeblieben sind und sich nicht weitergebildet haben. Die haben dann z.B. von SOLID noch nie etwas gehört.
Hey,
bin total bei Dir - schön das Du das auch so siehst. Finde die Leistungsklassen zur Qualitätssteigerung aber total in Ordnung, diese Junior/Senior-Sache ist halt doof...
Gruß David
Ich sehe das anders David. Ich bin ein Senior-Entwickler und im Vergleich mit meinem früheren Ich (als Junior-Software-Entwickler) bringe ich eine Menge wertvolles Wissen "drum herum mit" das nicht technologiespezifisch ist. D. h. würde ich von heute auf Morgen statt .Net Java machen, würde ich mich immer noch nicht als Silver oder Junior Entwickler sehen. Warum nicht nicht?
Fangen wir an bei den (1) Anforderungen, ich weiß wie es ist mit Kunden zu diskutieren, weiß wo ich Kunden widersprechen kann, wann ich mich auch mal in interne Themen eimischen darf, und wann ich besser schweige, ich kann gut Anforderungen spezifizieren z. B. in Jira oder anderen Tools, Wireframes erstellen, hab oft gute UI-Ideen usw. Andere Themen sind (2) Projekt-Management, (3) Teams/Teamzusammenhalt/Arbeit (z. B. Teamphasen -> hab alle erlebt (inkl. heftige Stormingphasen) und hab darin meine Erfahrungen gesammelt). Ich war Junior, Senior, Technical Lead in Projekten und hab einfach eine Menge Erfahrung in all den unterschiedlichen (positiven wie negativen) Phasen/Momenten von Projekten. D. h. mit dem Wissen werde ich IMMER eine Bereicherung für Projekte sein.
Aber auch bei technischen. Ich kenne allgemeine Themen und tückische Problemchen die unabhängig von Technologien sind.
Beispiele: Probleme mit Regions (z. B. unterschiedliche Dezimaltrennzeichen), die ganze Zeitzonen-Thematik (kann meistens die Umrechnungen locker im Kopf machen), Zeichenkodierung (kann auswendig den Unterschied zwischen ISO 852 und ASCI, ANSI und UTF-16 sagen), kenne auch "ältere" Themen wie SOAP, XML (xPath) die auch heute noch immer wieder in aktuellen Projekten z. B. bei Schnittstellen aktuell sind, hab viel Erfahrung mit Deployment, man denke auch an Authentifizierung wie OIDC, usw. diese "allgemeinen" Themen hast du immer ein Projekten und ein Senior kennt diese eher als ein junger Junior.
Und weiter kann ich Full Stack: vom Docker-Container, Windows Server, paar DBs, Backend und Frontend (wieviele können Memory Leaks in den DevTools aufspüren?). Und in den meisten Projekten hast du heute mindestens Docker, eine relationale DB und ein Frontend (zumindest bei uns). So dass ich eigentlich nie "blank" anfange.
Auch liebe ich die Konsole, statt Klikibunti, d. h. ich kenne die cmd, die Powershell, die bash und komm damit zurecht, ich liebe sie sogar. D. h. ich kann GitHub-Action Pipes schreiben, oder in Jenkins... und auch VI geht natürlich und ich drehe nicht ab, weil ich ein paar Tastaturkürzel kennen muss.
Übrigens, ein weiteres Argument: ich habe mich intensiv mit Lerntechniken beschäftigt und würde behaupten dass ich mit meinen 40 Jahren fast alle 20jährigen schlage, wenn es darum geht mich in neue Themen einzuarbeiten. Change Management, Veränderungen, ich habe so viele Wandlungen mitgemacht...
Daher, ich würde mich nicht auf einen Silver oder Junior zurückstufen lassen. Vielleicht irgendwann wenn ich 60 bin und senil werde :)
Du beschreibst das aber genau so wie David es nicht meint und kritisiert. Es geht nicht um das früher im zeitlichen Sinne sondern um die Skills die du für ein Projekt mitbringst.
Wenn es jemanden gibt der eine schnellere Auffassungsgabe hat als du, dabei aber Anfang 20 ist, dann könnte er auf deinen heutigen Wissensstand auch schon früher sein. Demnach könnte er für das aktuelle Projekt genauso wertvoll wie du und demnach auch Senior sein.
Es hilft dir sicher wenn du schon viel gemacht und erlebt hast, aber das bedeutet eben nur, dass du besser sein wirst als jemand der dir in Potenzial und Fähigkeitwn ähnlich ist aber dem die Berufserfahrung fehlt.
Nun, für mich gibt es noch einige andere Eigenschaften: Ein Senior ist sich seiner in ihn gesetzten *Verantwortung* bewusst und entsprechend bereit sein, diese zu übernehmen. Ein Senior sollte selbstkritisch sein und nicht nach Ausreden suchen ( die „Dreckstools“, die blöden Anwender“, …) sondern sich und sein Handeln hinterfragen und zu verbessern - Ständig! Ein Senior ist gewandt in der Anwendung seiner Werkzeuge und setzt diese weise ein. Er hat ein ausgeprägtes Gespür für den richtigen, aber auch falschen Weg. Ein Senior strebt nach ständiger Verbesserung seiner Kenntnisse und sollte sich ständig Weiterentwickeln (tägliche Code- Katas) und offen für Neues sein - und er sollte dabei durchaus kritisch sein, und stets fair und auch *selbstkritisch* handeln. Das sind für mich Kriterien eines guten Seniors und ich versuche mich daran zu orientieren…
du hast absolut Recht mit der Unterscheidung Gefahr oder nicht für das Projekt... sollte jeder erfahrene Etwickler beurteilen können. Ich habe selbst mehrfach die Domain gewechselt und verstehe das man da klein bei geben sollte... Domain ist prio 1
Jobtitel waren bei uns immer so dermaßen beliebig, dass wir gewitzelt haben und uns selbst Titel ausgedacht. (Aber dann natürlich nicht umgesetzt, war ja nur ein Scherz.)
Mein Favorit: Superior Developer. Egal wie gut du bist, ich bin Superior.
Ich kenne die Aufteilung eher als „Junior Dev“, „Dev“ und „Senior Dev“. Die meisten sind nach paar Jahren einfach Entwickler, also kein Junior mehr, bleiben aber auch das ganze Leben auf dem Level, also kein Senior.
Dieses Thema Baseline klingt sehr technisch. Ein guter .Net Entwickler wäre demnach immer ein Junior, wenn er zB plötzlich Java entwickeln muss. Seniorigkeit beinhaltet aber auch Softskills (zb wie rede ich mit dem Kunden) und Basistechnologien (zb AuthN/AuthZ) die sprachenübergreifend gelten. Das kommt zumindest im Video gar nicht vor.
Den Entwickler und den Senior Entwickler trennt in meinen Augen dann vor allem die Verantwortung. Der Senior treibt Projekte eigenständig voran, arbeitet teamübergreifend, führt Projekte fachlich und hat dabei immer das große Ganze im Blick. Darum werden viele gute Entwickler nie Senior, weil sie das nicht wollen oder nicht können.
Ich finde diese Fokussierung auf die Frage, ob man alle in einem Projekt eingesetzten Frameworks beherrscht, etwas verengend und oberflächlich. Ich bin auf meiner aktuellen Position definitiv senior, wäre aber nach der Definition im Video in fast jedem anderen Unternehmen erstmal junior, da es eigentlich nie vorkommt, dass man alle Frameworks kennt, dazu sind es einfach zu viele. Dennoch finde ich mich nicht vergleichbar mit einem junior, der direkt von der Uni kommt. Erfahrung ist goldwert und der Sinn dafür, was eine gute Architektur im Großen und Clean Code im Kleinen ausmacht, ist nicht abhängig von Frameworks und entsprechenden Kenntnissen.
Dem würde ich zu 100% zustimmen. Neben der Beherrschung des Tech-Stacks gibt es so viele Punkte, die einen guten Entwickler ausmachen, z.B.:
- relevante Domainexpertise
- Verständnis der relevanten Stakeholder, deren Rolle Bedürfnisse und Bedeutung
- Verständnis der Projekt/Organisationsstrukturen und Rahmenbedingung
- die Fähigkeit und Bereitschaft Wissen zu teilen und weiterzugeben
- Fähigkeit zum Erkennen von Schwachstellen im Entwicklungsprozess und/oder der Kommunikation etc. und die Übernahme von Verantwortung/Initiative zur Verbesserung
- Offenheit, Neugier und der Wille sich weitrrzuentwickeln und dazuzulernen
- Gelassenheit und Stresstoleranz, Toleranz und ein Auge für den Rest des Team, wenn es mal Druck gibt
- [...]
Viele der oben genannten Punkte sind sicherlich positiv mit Projekterfahrung korreliert - mehr aber auch nicht. Insbesondere bei sehr senioren Entwicklern können auch mal Motivation und Neugier nachlassen und im extremfall sogar der Anschluss an moderne Entwicklungsprozesse/Technologien verloren gehen.
Dazu kommt, dass insgesamt natürlich nicht jeder Entwickler alles davon abdecken muss sondern es reicht, dass das Team dies abdeckt.
Insgesamt wäre ich mit der Klassifizierung in "Senior" und "Junior" aber mehr noch mit der Einteilung in "Projektrisiko" und "Projektnutzen" sehr zurückhaltend.
Ein demütiger intelligenter, kommunikationsstarker Junior, der sich einarbeitet, motiviert ist und nachfragt ist u.U. weniger ein "Projektrisiko" als ein von sich überzeugter, sturer erfahrener Kollege, der nicht erkennt, dass Teile seiner Erfahrung/Lösungsmuster aus einem oder mehreren Projekten nicht auf die neue Umgebung übertragbar sind, der endlose Diskussionen über nicht essentielle Designaspekte anzettelt (a la "Leerzeichen" versus "Tabulatoren"), seine Kollegen demotiviert und bei der Teilung von Wissen mauert ...
Was die Baseline angeht: Im Optimalfall fühlen sich zu je 50% das Team und der "neue" Mitarbeiter dafür verantwortlich, diese so schnell wie möglich zu erreichen.
Bei uns wird dabei gar nicht unterschieden - ist aber auch eine recht kleine und merkwürdig organisierte Firma.
Ich finde es aber nicht schlimm, ich finde, untereinander sollten die Kollegen sich ihren "Status" selber erarbeiten oder beweisen können.
Und finanziell sollte eine Firma dann auch bereit sein, gute Leistungen auch besser zu bezahlen - am besten von sich aus.
Was ich zu dem Thema am besten in Erinnerung habe:
Ein alter C++-Entwickler, hat über 20 Jahre in dem Job gearbeitet.
Kam aus einem Elektrotechnik-Studium, hat dann in der Firma ein Projekt übernommen und seit dem nichts anderes gemacht.
Das Projekt war/ist ziemlich groß, bewegt viel Geld, ist allerdings auch ein heilloses Chaos, das vor jedem Update für sehr viele Probleme gesorgt hat.
Außerdem war es technologisch locker 10-20 Jahre veraltet und weil es so unbeherrschbar wurde, wurden viele Funktionen in viele C#-Programme (.NET 2.0, selten auch 4.5) ausgelagert, die XML-Dateien entgegen genommen und mit XML-Dateien geantwortet haben.
Ihm wurde immer sehr viel Erfahrung nachgesagt, in dem einen Projekt mag das auch stimmen, ich bin aber der Meinung, dass die 20 Jahre nur wenig wert sind.
Ich will ihm den katastrophalen Zustand des Projektes (gab's schon vor ihm) nicht zuschreiben, aber er hat die 20 Jahre eben nur diese eine Art zu Arbeiten kennen gelernt, die heute so viele Probleme verursacht. Bei neuen C++- oder sogar C#-Projekten hätte er mMn. den Stand eines Juniors.
Er war allerdings der Typ Mensch, der sich ganz einschätzen kann und hat selber zugegeben, dass er eigentlich nur dieses Projekt kannte, das war ganz angenehm.
Ein anderer Kollege, der das selbe Projekt noch länger begleitet hat, dabei aber nicht aktiv mitentwickelt, sondern nur zwischen Tür und Angel Architektur- und Design-Entscheidungen getroffen hat, der war von seiner Erfahrung überzeugt und das - da waren wir uns eigentlich alle einig - war ein wirkliches Problem.
Und von der Sorte gab es noch mehr in der Firma, z.B. einer, der mir mit einer unerschütterlichen Zuversicht erklärt hat, warum ein Switch mir 30 im Code völlig unabhängigen Cases mit je über 1000 Zeilen (es ging um Dokumenten-Druck) besser sei, als z.B. ein geeignetes Pattern und je Dokument eine in sich abgeschlossene Klasse. Auch er hat nie etwas anderes kennen gelernt, als dieses eine Projekt, in dem solche riesigen chaotischen Dateien normal waren.
Das heißt nicht, dass die alle dumm sind - sind sie nicht - aber sie haben zu lange immer das gleiche gesehen und glauben, dass das so gut ist.
Für mich hängt Erfahrung weniger mit der Zeit, sondern mit der Anzahl verschiedener Projekte zusammen.
Wer viele Projekte kennengelernt, ihren Aufbau und die Folgen daraus gesehen hat, hat mMn. langfristig sehr viel mehr davon.
Und natürlich aktuelles KnowHow und aktuelle Technologien, aber darauf wird ja scheinbar nur sehr wenig Wert gelegt, wie ich bei einem aktuellen Kunden sehr eindrucksvoll bewundern "darf".
grad zum letzten Part: in einer Ausbildung oder einem Bachelorstudium ist das, was man lernt, nicht eine Programmiersprache, oder mehrere, sondern "wie lerne ich eine neue Sprache?", "wie lerne ich neue Methodiken?", "wie erarbeite ich mir eine sinnvolle Architektur, die ich selbst in 10+ Jahren spontan wieder aufrufen und daran weiterarbeiten kann?" und so weiter.
und das ist es, was gute Entwickler (alle Angestellten in der IT eigentlich) ausmacht: Sich selbst weiterentwickeln und die richtigen Technologien gewinnbringend einsetzen.
@@Todbrecher Das klingt nach einem Erfahrungsbericht?
Dann hast/hattest Du großes Glück mit deiner Ausbildung.
Bei mir war es eher: Hier Aufgabe XY, wenn Du Fragen hast, dann frag. Das galt aber nur für mich so, weil ich vorher schon programmieren konnte, die anderen Azubis saßen teilweise im Support ...
@@Palladin007 das sind die gesammelten Erfahrungen, die ich selbst und durch Bekannte in der IT erlebt habe, in den letzten rund 8 Jahren.
für das "Wie lerne ich" ist die Uni bzw die BErufsschule zuständig, gerade in den IT-Fächern bleibt eh keine Zeit, großartig Tools und Sprachen zu erlernen.
ich hatte mit Sicherheit nicht großes Glück, sondern du mit deiner Ausbildungsfirma oder eben Abteilung pech. in der IT ist "mach mal, wenn du nich weiter kommst frag mich" tatsächlich der sinnvollste Weg, um das "Wie lerne ich" in der Praxis zu üben. im Beruf später muss man das dann ja schon können, und dann gibts keinen mehr, der dir was vorkaut.
In meiner Firma gibt's keine offizielle Trennung zwischen Senior und Junior. Ich selbst sehe mich definitiv mit 27 nicht als Junior. Für mich halt Senior und Junior nicht zwingend was mit Technologie sondern eher was mit tiefergehendem Wissen zu tun. Wie z.B kenn der Dev, Designpattern, schreibt er Nachhaltige Software, kennt er sich mit Caching, Autorisierung, Authentifizierung etc. aus.
Wenn man tiefergehendes breites Wissen in solchen Bereichen hat ist man für mich jedenfalls Senior.
Noch ein Zeichen ist bist du als Entwickler eher der, der andere um Hilfe fragt oder kommen eher andere zu dir
Hey Nicolai,
sehr interessant, die Diskussion mit dem "anderen Helfen oder suchst Du hilfe" hatte ich heute in einem Kundenworkshop, finde ich einen sehr interessanten Ansatz :)
Gruß David
Es wäre interessant, wenn Du ein Video für Entwickler machst, die Senioren sind aber keine Erfahrung im IT Bereich haben, aber sie sammeln wollen bzw. die Kenntnisse erwerben wollen. Gibt es für die überhaupt eine Chance in der Branche? Wenn ja wo?
Nein. Gibts nicht. Ageism beherrscht diese Branche.
Ich finde, eine solche Zweiteilung greift zu kurz und demütigt gar erfahrendere Entwickler, die aber noch keine Seniorität erreicht haben. Junior ist ein Einsteiger, ein Rookie. Das sollte man auch wirklich nur für solche verwenden, um allen im Team zu sagen, schaut mal auf den drauf, mentort ihn. Niemand mit mehr als zwei bis drei Jahren Praxiserfahrung nach seiner welch auch immer gearteten Ausbildung sollte noch als Junior bezeichnet werden.
Für mich ergibt da eher die Einteilung Junior, Regular und Senior Sinn. Der Regular ist genau das, jemand, der im laufenden Projekt nicht die Base-Line zum Senior überschritten hat, das kann ggf. auch wechseln, ist aber ein passenderes Framing. Der Senior ist dann aber wirklich schon ein alter Hase, das schließt eben nicht nur die Implementierungsskills ein, sondern eben auch den Umfang der selbstständigen Arbeit und Erarbeitung von neuen Themen, als auch Softskills in Sachen Team-Mentoring und Vorbildfunktion, als auch die Bereitschaft zur Übernahme von Verantwortungen über die reine Entwicklung hinaus mit ein.
interessant, danke!
Sehr gerne!
Gruß David
Wer entscheidet dann über die eingesetzten Technologien, wenn ein neues Projekt startet?
Wenn die Gold-Entwickler entscheiden dürfen, dann wird es keinen Fortschritt geben.
Warum sollte ich mir das antun, dass ich mich für neue Dinge entscheide, wenn ich dann zurück gestuft werde. Die neuen, die mit neuen Ideen kommen werden dann wohl ausgebremst.
Was mir in deinem Video fehlt sind Technologie unabhängige skills, wie z.b. Umgang mit Konflikten im Team oder effektive Einarbeitung in unbekannte Domänen. Hat es einen Grund warum du so etwas nicht mit auf nimmst?
Ich fragte einen Seniorentwickler (30j alt) ab wann man sich Senior nennen darf? Antwort: Ab dem Zeitpunkt wenn man sich Senior fühlt.
Die Antwort ist sooo gut :D Frauen bleiben also immer Junior-Entwickler...
Gruß David
@@DavidTielke damit untergräbst du jetzt alle Frauen die genau das Gegenteil von deiner Aussage sind! Meine Freundin würde dir die Ohren langziehen.
Denk also beim nächsten mal dran 😉
Content war wieder super 👍
@@robotrabbit5817 Ich denk das war eher darauf bezogen, dass Frauen sich im Gegenzug zu Männern nachweislich wesentlich schlechter einschätzen.
Noch ein Aspekt, es gibt Unternehmen, die von den Amis die Hierarchie kopiert haben mit Junior, Middle, Senor und Principal developer, diese Modell ist statisch und kann die dynamische Natur der Entwicklungsbranche nicht gegenhalten, deshalb ist die Idee mit dem herabstufen oder aufsteigen lassen fair und zeitgemäß, zumal die Leute auch wenn sie auf einer Stelle sind meistens in Komfortzonen residieren und Herausforderungen eher nicht wollen... :)
Wer soll diese Einstufungen vornehmen? Das Team?
Das klappt meist eher selten, meist sind es Team- oder Entwicklungsleiter :)
Gruß David
derjenige der in der Lage ist das Projekt umfassend zu verstehen
nicht vorhanden... aufteilen
Es ist schwierig zu sehen. Ein „Senior“ hat halt schon viel Erlebt und kann auf Situationen reagieren, wie es ein „Junior“ nicht kann.
Auch wenn dieser nur kurz in einem Projekt ist.
Ich habe es erlebt, das es viele „Programmierer“ (Ich schreibe bewusst) die lange dabei sind, das System in und auswendig kennen und dennoch, keine Entwickler sind, weil sie einfach nur den Code um Fragmente Erweitern und damit für eine Entropie die ihres gleichen sucht, erzeugen.
Es gibt Seniors, die das Falsche vermitteln, weil sie es seit Jahren und Jahrzehnten so gewohnt sind so zu arbeiten und es nicht ändern wollen.
Deswegen würde ich diese Unterscheidung generell nicht machen wollen.
Ein gutes Team ergänzt sich und steht nicht im Konkurrenzkampf.
Auch Seniors können von den Jungen lernen.
Wobei es anders rum mehr anzutreffen ist.
Es gibt „Juniors“ die haben die neuen Sprachfeatures drauf und sind in der Programmiersprache sehr sehr gut.
Was teilweise auch klar ist, lernen sie auch nicht immer die alten Sprachfeatures.
Der Mehrwert ist einzig ein Team was sich ergänzt.
Wenn man sich nicht im Code auskennt ist "Code um Fragmente Erweitern und damit für eine Entropie die ihres gleichen sucht, erzeugen" ja vielleicht die eigene Entropie des Nichtverstehens? Was viele Juniors leider ueberhaupt nicht verstehen ist die Kosten-Nutzen analyse von Software Design
@@llothar68 Das ist natürlich ein Argument. Aber ich denke nicht, dass Junior Entwickler die Kosten-Nutzenrechnung nicht verstehen.
Das ist eine Sache der Intepretation.
Kosten Nutzen, für mal eben schnell schnell ist enorm hoch. Beim ersten Hinschauen.
Auf der Langen Bank, kann so eine kleine schnell, schnell Änderung fatale Folgen auf die Kosten und den Nutzen haben. Weil diese Änderung ein Nachspiel hat, wo alle anderen Änderungen drauf basieren.
Macht man es vernünftig, dauert es eben mal nicht schnell schnell, sondern etwas länger. Wird aber so im Code umgesetzt, ohne die Entropie bewusst zu erhöhen.
(man wird nie alle Fälle finden)
Dadurch kann der Aufwand in der Zukunft minimiert werden.
Nichts ist schlimmer als ein Programmcode, wenn man sich nicht an Regeln hält.
Wenn man keine Regeln hat, wird jeder Programmierer so programmieren wie er will.
Bis hin, das nur derjenige, der den Code erstellt hat, diesen sauber lesen kann.
Wenn man Glück hat. Viele verstehen ihren eigenen Code schon 6 Monate später nicht mehr.
Wenn es saubere Strukturen gibt, und gängige Praktiken eingehalten werden, wird jeder Entwickler, der diesen Code sieht schneller lesen und verstehen können.
In dem Buch Entwurfsmuster von Kopf bis Fuß, fand ich den Vergleich recht passend:
Der eine bestellt in der Imbisbude Pommes rot/weiß
Der andere Pommes Schranke
Wieder ein anderer Pommes mit Ketschup und Mayo.
Alle meinen das Selbe, reden aber was völlig unterschiedliches.
Diese einfache und simple Beispiel zeigt, wie wichtig seine sauber definierte Gundlage ist.
Ja jeder kann es machen wie er will. Leider.
Ich selbst bin Senior Developer. Wobei mir persönlich der Titel primär nicht wichtig ist. Qualität lässt sich nicht zwangsläufig an Titeln messen.
In der Realität sind die Titel mehr Marketingrelevant, weil die Arbeitswelt eben darauf konditioniert ist Personen zu klassifizieren und levelbasiert Gahaltsranges und andere Vergünstigungen daran zu koppeln.
Und ob nun jemand in einem Unternehmen befördert wird hängt in erster Linie nicht von seinen Fähigkeiten, egal ob Soft oder Hardskills ab sondern vom Nasenfaktor und/oder dem jeweiligen Vorgesetzten, denn Beförderungskriterien in Unternehmen sind meist sehr interpretierbar bzw. Wenn 99% der Beförderungskriterien erfüllt sind, wird eine Nicht-Beförderung mit dem fehlenden 1% begründet oder damit, dass dann das Verhältnis nicht mehr stimmt.
Für mich gibt es gut oder schlecht. Und wie im realen Leben macht es die Mischung. Ein 'erfahrener' Entwickler, ich z.B. hab im Frontend bis vor zwei Jahren noch mit Swing entwickelt, kann z.B von einem jüngeren z.B. in Angular/Typescript lernen während der jüngere/unerfahrene von mir z.B. in punkto Herangehensweise, Methodik profitieren kann.
Man kann es auch einfach, wie im consulting üblich, nach Verantwortung einstufen... assistenz-umsetzung-delegation-repräsentation
Das sehe ich etwas anders, denn aus mehreren Gründen, ist so ein erfahrungsbasiertes Modell in der Praxis besser. Natürlich kann man einen C++ Entwickler mit 25 Jahren Berufserfahrung nicht in einem Java-Projekt als Senior Entwickler anpreisen, genausowenig wie man einen Ohrenarzt einfach mal als Zahnarzt einsetzen kann. Dennoch ist die Erfahrung im jeweiligen Bereich aber nun einmal da und das muss sich natürlich auch im Gehalt ebenso wie in Verantwortung, Pflichten und Rechten widerspiegeln. Dass ein Senior wieder zu einem Junior zurückgestuft wird, habe ich noch nie erlebt und das würde vermutlich auch in den allermeisten Fällen zu einer Kündigung führen oder noch schlimmer zu interner Sabotage. Ein "degradierter" Entwickler verliert ja nicht automatisch seine Fähigkeiten und kann viel Schaden anrichten, ganz ohne dass man ihm Vorsatz nachweisen könnte.
Mit Gold/Silber dürfte es sich ähnlich verhalten, wenn man nicht klar eine solche "Baseline" daran knüpft, also etwa Gold Technologie X / Silber Techologie Y. Aber wer würde denn fortlaufend überprüfen können, wer welche Baseline erfüllt oder nicht erfüllt? Wenn jemand ein Doktortitel hat, wird der ja auch nicht wieder aberkannt, weil der Träger nach 20 Jahren anderer Tätigenkeiten in seinem ursprünglichen Bereich kaum noch auf dem Niveau eines Studenten ist. Im Übrigen dürfte Silber/Gold ein Vokabular sein, mit dem Kunden nichts anfangen können. Wenn ein Projekt ausgeschrieben wird, will man i.d.R. Senior Entwickler darin haben. Nur Senioren sind aber i.d.R. nicht machbar und nur Junioren werden vom Kunden nicht akzeptiert, also trifft man sich in der Mitte. Hat man keine Senioren für die Zielplattform kann man u.U. etwas schummeln, wenn man gute Junioren hat, denen man dann Senioren aus "verwandten" Bereichen zur Seite stellt. Denn zum einen kommt es meist nicht gut an, 20 jährige Mitarbeiter als teure Senioren zu präsentieren und zum anderen ist Erfahrung ja nicht nur für eine konkrete Technologie relevant. So könnte etwa der erfahrene C++ Entwickler trotzdem schon Schwächen im Archtekturkonzept erkennen, die der Java-Junior nicht gesehen hat, obwohl das Projekt mit Java realisiert werden soll.
Senior vs. Junior bedeutet im Übrigen nicht, dass Seniorentwickler automatisch immer besseren Code schreiben, auch wenn das meistens so sein wird. Ein Grund kann dabei beispielsweise Betriebsblindheit sein, etwa weil der Senior wegen fehlendem Austausch mit Kollegen sich ein fehlerhaftes Vorgehen angeeignet hat oder elegante neuere Alternative einfach nicht kennt. Der Bereich Software und Tools ist heute überdies so komplex, dass es praktisch unmöglich ist, überall auf dem Laufenden zu bleiben, insbesondere, wenn noch Arbeit "nebenbei" erledigt werden muss. So entsteht bei Junioren der Eindruck, dass der Senior sein Geld eigentlich nicht wert ist, weil er nicht einmal dies oder jenes kann. Dazu kommt noch, dass nicht jeder neue Trend bzw. neues Framework automatisch besser ist. Einen bewährten und funktionierden Ansatz aufzugeben, will wohl überlegt sein.
Lange Rede, kurzer Sinn, Senior / Junior an Erfahrung zu knüpften halte ich durchaus für einen validen Ansatz, aber immer unter der Maßgabe, junge Talente nicht zu ignorieren und mögliche Betriebsblindheit von Senioren nicht auszuschließen.
Zu deiner letzten Frage im Bezug auf "Senior-Entwickler der nichts drauf hatte": Ja, das habe ich leider ziemlich heftig erlebt. Wir haben mehrere Teams, die in verschiedenen Software-Projekten arbeiten. Für einen Großauftrag wurden notdürftig verschiedene Leute aus verschiedenen Teams abgestellt. Es dauerte nicht lang, da hatte unser gemischtes Team bereits eine Deployment-Chain errichtet, die Architektur geplant und erste Tests für TDD implementiert. 2 Monate später stieß dann die angekündigte Verstärkung hinzu. (2 Senior Entwickler aus dem C++ Bereich). Wir mussten die beiden erstmal in GIT einlernen, da sie nur SVN kannten... Gitlab CI/CD war folglich Raketenwissenschaft... Wir haben den beiden keinen Vorwurf gemacht, konnten die erste Meilenstein Deadline allerdings nicht einhalten... Die beiden haben über 15 Jahre in ihrer Tech-Bubble arbeitet. Ich hab mir daher angewohnt, viele Infos aus der Ferne zu einzuholen ... Ich hab zum Beispiel noch nie mit SCRUM gearbeitet (nur Kanban), aber ich weiß, was das ist. (Durch deine Videos als Einstieg und danach weiter vertieft) ... Es ist nicht verkehrt solche Konzepte zu kennen und irgendwie auch unsere Aufgabe als Entwickler, stets ein offenes Ohr zu haben. Man muss ja nicht direkt Experte sein, es nur im besten Fall schon mal gehört haben und einordnen können. Ich hab z.B. auch noch nie etwas mit Blockchain entwickelt, versteh aber das Prinzip. Sollte jetzt irgendwann mal etwas in die Richtung kommen, dann hab ich keine Angst mehr :D
So. Genug aus der Praxis. Ich muss weiter coden. Wünsch dir was. LG
1:25 ich wünschte das wär wirklich so
Problem was ich sehe ist eher folgendes: Seniors sind so tief in der Domäne und Technik, dass nur sie ihren Code verstehen 😂
Der Code funktioniert und ist performant, aber Clean ist er nicht unbedingt und wirkt für andere Entwickler, die nicht so tief mit den Details vertraut sind, wie schwarze Magie.
Da fehlt einfach KISS. Immer die einfachste Lösung.
Wenn du etwas nicht brauchst, benutzte es nicht. Baue keine generische Lösungen für nichtvorhande Anforderungen.
ich bin jetzt nun ja im Bereich Devops angesiedelt, da ist das grundsätzlich nicht soo prägant bisher (ich bin zum Beispiel einfach nur "Devops Engineer", was anderes gibt es bei uns nicht).
Das Prinzip Silver und Gold löst exakt mein Problem mit Junior und Senior, und da bin ich auch genau deiner Meinung, warum ich Jr. und Sr. ncht so gut gewählt finde.
Warum nur Schwarz / Weiß? Es gibt doch eigentlich Junior Entwickler, Entwickler, Senior Entwickler. Also zumindest bei uns in der Firma. Nach 2 Jahren ungefähr ist man normaler Entwickler und dann steigt man nie zum Senior auf :D
Zumindest hadert es da noch bei uns...
Nachtrag: Würde man mich in irgendeiner Weise herunterstufen, würde ich direkt den Arbeitgeber wechseln. Dann lieber gar nicht erst aufsteigen. Dann würde ich allerdings ebenfalls wechseln. Sollte ich vielleicht mal...
In meinem Team sind einige Senior Entwickler eher Programmierer. Wie soll ich die runterstufen, wenn die Betroffenen Entwickler es anders sehen.
Hey,
hast du einen Team oder Entwicklungsleiter? Habt ihr eine transparente Baseline?
Gruß David
@@DavidTielke leider nicht
Wir haben doch einen, habe es grad erfahren. Aber wie soll der das bewerten wird schwer
Nur weil jemand etwas lange gemacht hat , heisst es nicht das er/sie es gut gemacht hat
Grundsätzlich gebe ich dir Recht, aber meiner Meinung nach, ist dieses Leistungsprinzip auch sehr toxisch und spiegelt nicht die gesamte Wirklichkeit. Ein 20-jähriger Single-Entwickler hat nun mal nicht die selben Lebenshaltungskosten, wie ein 35-jähriger Familienvater mit 2 Kindern. Vor allem hat er nicht die gleiche Zeit, sich in neue Technologien neu einzuarbeiten. Nach deiner Logik müsste jeder talentierte 20-jährige mehr verdienen, als ein 35-jähriger, der vielleicht bisschen abgehängt wurde? Ist das fair - kann man sicherlich gut darüber streiten. Aber meiner Meinung nach ist das genau der Hauptgrund, wieso so extrem viele Entwickler mit 40 Burnout haben. Das Berufsbild ist geistig extrem fordernd und ein 40-jähriger hat oft nicht die geistige Aufnahmefähigkeit wie ein frischer Uniabgänger.
Wollen wir dann Richter und Kassierer auch nach Kunden bezahlen? Oder Polizisten nach Knöllchen? Weiß nicht, ob das so ein toller Trend ist, den du hier aufzeigst. In dieser Welt will ich nicht leben - aber das muss jeder für sich wissen!
Moin,
da hast du etwas ganz falsch verstanden - ich habe bei der Kritik extra noch gesagt, dass es KEIN Gehaltsmodell ist - folglich sollte nicht der Junior- Seniorstatus über das Gehalt entscheiden, sondern andere Dinge und die liegen außerhalb des Scopes dieses Videos. Die Unterteilung Junior / Senior oder wie in meinem Fall Silver/Gold ist immo einig und alleine dazu da, die Entwickler in "Leistungsklassen" einzustufen um die Softwarequalität zu steigern und hat rein gar nichts mit der Bezahlung zu tun. Von daher stimme ich die bei deinen Aussagen was die Bezahlung angeht total zu!
Gruß David
Ich bin Vater von 3 Kinder, in der Zeit hatte ich auch nicht die Zeit. Jetzt wo meine Kinder ihre eigene Wege gehen, habe ich mehr Zeit für mein Beruf und habe als Senior Entwickler vieles dazu gelernt, weil es mir auch Spaß macht. Bin in meinem Team der Techleader, kann sehr gut bei Entscheidungen mitsprechen oder kann Proaktiv Verbesserungen vorschlagen. Die Junior Entwickler sind auf dem neuesten Entwicklung Stack aber es fehlt ihnen die Erfahrungen in allen Gebieten.
Ich denke, dass Erfahrung eine riesen große Rolle spielt. Man bekommt mit der Zeit ein Gefühl für die Technologie und fühlt sich nicht ganz so verloren. Zeit ist da wirklich relativ. Hatte schon Momente, wo ein Studententeam aus 4 Leuten im Praxissemester für eine Aufgabe knapp 5 Monate gebraucht haben und zwei Vollzeit-Entwickler das Ding nochmal in 2 Wochen neu entwickeln mussten, weil deren Ansatz kompletter Bullshit war. Keiner hat die dafür verurteilt, aber wirtschaftlich war das ein Totalausfall...
Es gibt aber auch Entwickler, die gar keine Lust haben sich weiter zu bilden (das kann man auch in der Arbeitszeit) und 20 Jahre Schema F fahren und dann am Ende gar nicht mehr klar kommen, wenn man zum Beispiel in einem anderen Projekt nen Buildserver mit Docker nutzt.
Alles schon erlebt. Ich glaub das hat auch viel mit der inneren Einstellung zu tun. Ob jetzt ein 20 Jähriger wirklich die kinderlose Zeit nutzt, oder lieber Battlefield spielt ist doch gar nicht gesagt :D
Da es aus meiner Sicht um Expertise geht, könnte man sich gut am Dreyfus-Modell (Stufen der Kompetenzbildung) orientieren.
Silver, Gold, Platin und Pro/Am … wie im Motorsport.
KA ob das da auch so ist... :) aber gut zu wissen!
Gruß David
@@DavidTielke Die Softwareentwicklung und deren Entwickler haben schon gewisse Ähnlichkeiten zum Sport und Fahrerklassen.
Wettbewerb, Perfektionismus, Fehler, ganz viel Teamwork, unvorhersehbare Ereignisse usw. Jede Runde eine neue Herausforderung.
Hey Roman,
stimmt wobei die zum Glück nicht so auf einzelne Personen ausgerichtet ist..
;)
Gruß David
Junior = muss betreut werden. Mid = muss nicht betreut werden. Senior = kann betreuen.
Senior = muss bald wieder betreut werden... ;)
@@DavidTielke 😂
Like und Abo :)
Ich finde den Typen irgendwie unsympathisch
Liegt vielleicht an dem Gehaltsvideo, aber wirklich authentisch wirkt das alles nicht
Ich find den auch total unsympathisch... Der geht echt gar nicht!
@@DavidTielke der soll mal mehr Shorts machen, das regt die ganzen Nerds wohl ziemlich auf, dabei ist die Reichweite immens
Denke das packt der von der Intelligenz her nicht...
Ich bin seit 6 Jahren in einer Firma als Developer tätig und wäre dort niemals zum Senior ernannt worden. (gibt es bei uns irgendwie nicht ...). Jetzt hatte ich gestern ein Interview und ich wurde direkt als Senior kategorisiert. Sieht natürlich im Lebenslauf nicer aus, erhöht allerdings auch den Druck ... :D
ich war von anfang an als "Programmierer" eingestellt, plötzlich war ich dann Full Stack Senior Developer (war plötzlich der Titel des Jahresgesprächsformulars)