Das PROBLEM bei älteren Softwareentwicklern
HTML-код
- Опубликовано: 15 сен 2024
- In diesem Video beleuchten wir die entscheidende Rolle älterer Softwareentwickler in der Technologiebranche. Wäh
rend sich die IT-Welt rasant weiterentwickelt, stehen erfahrene Entwickler vor einzigartigen Herausforderungen, insbesondere beim Erlernen neuer Technologien und Methoden. Dieses Video bietet tiefe Einblicke in die Dynamik von Softwareteams, in denen Erfahrung auf Innovation trifft.
▬ Über diesen Kanal ▬▬▬▬▬▬▬▬▬▬▬▬
Seit vielen Jahren arbeite ich als Consultant, Coach und Trainer für professionelle Softwareentwicklung mit den Schwerpunkten Softwarequalität, Softwarearchitektur sowie Prozessmanagement. Auf meinem Kanal möchte ich Euch mein Wissen und meine langjährige Erfahrung in diesen Bereichen vermitteln - natürlich kostenlos. Dabei versuche ich stets Euch das Wissen so zu vermitteln, dass Ihr damit direkt in der Praxis loslegen könnt und das ganze immer mit guten Portion Humor. Lernen soll ja schließlich Spaß machen :)
▬ Empfohlene Videos ▬▬▬▬▬▬▬▬▬▬▬▬
Wie viel Softwarequalität Ihr braucht - • Architekturen - Von Mo...
Warum Software unwartbar wird - • Warum Software unwartb...
Architektur - Modularisierung - • Architektur - Modulari...
Was ist Architektur - • Was ist Architektur?
Warum Architektur - • Warum Architektur für ...
▬ Wichtige Links ▬▬▬▬▬▬▬▬▬▬▬▬
Abonniere meinen Kanal: / @davidtielke
Alle Videos: / @davidtielke
▬ Social Media ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
► Twitter: / davidtielke
► Xing: www.xing.com/p...
► LinkedIn: / david-tielke-06140912b
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Als aelterer Softwareentwickler faellt mir auf, dass es manchen juengeren es schwer zu fallen scheint endlich auf den Punkt zu kommen.
als uralter Softwareentwickler stimme ich Dir da zu 100% zu
@@YTChannelAS 😁
Nach fast sechs Minuten noch nicht zur Sache gekommen. Und das bei meiner geringen Restlebenszeit. Und *neue* Technologien? Lernen kann man lernen. "Tun ältere Entwickler sich schwerer"? Nein - Quark. Im Gegenteil. Jüngere lesen jedes einzelne Zeichen - ältere sehen die Muster. Wie beim Lesen. Und die Jüngeren brauchen immer bis sie die Themen verstanden haben. Ich bin dann immer der Erklärbär der sie nachzieht. Ich bin 66 und gehe in neue unbekannte Projekte und bereite die auf damit jüngere Kollegen die das nicht so schnell schaffen Gelegenheit haben in diese Projekte zu kommen. Und ich will *GERADE* neue Themen. Immer nur Java und C# ist elend langweilig. Und fast die ganze Tiobe Top 50 lernt man auch nicht mal eben "kurz nach dem Studium".
Boah... da sagste was! Das zieht sich wie Kaugummi. Gefühlsmäßig hätte da jetzt 1 Slide gereicht, um das Thema zu transportieren, oder? "Alte lernen zu langsam und sind dabei auch noch zu teuer. Aber seid trotzdem nett zueinander!" Irgendwie hab ich ne Liste von Problemen erwartet, aber mehr hab ich jetzt hier nicht mitgenommen. Oder hab ich irgendwann geistig abgeschaltet? Nichtsdestotrotz vielen Dank für den Denkanstoß: werde ich im Kopf behalten.
der pragmatische programmierer ein hype von vorgestern lol
Kann ich so nicht bestätigen. In meiner Firma gab es immer schon ältere Entwickler. Die sind alle sehr gut. Einer ist jetzt 64 und immer noch geistig topfit. Da muss selbst ich als Jüngerer manchmal staunen. Er lernt auch ständig neues. Ich bin jetzt 39 und lerne nicht viel langsamer, als mit 20. Der Unterschied ist aber, dass ich nicht mehr die Zeit habe und auch nicht mehr die Lust habe. Mit 17 Jahren habe ich viele Nächte damit verbracht Webseiten zu programmieren und auf Sourceforge Open Source Programme mit zu entwickeln. Das will ich heute aber gar nicht mehr. Ich programmiere gerne, aber ich widme meine Zeit auch anderen Dingen. Als junger Mensch macht man sich keine Gedanken über Zeit. Ich habe damals auch tagelang an Autos geschraubt, mich mit Codierungen beschäftigt usw. Heute bringe ich das Auto zur Werkstatt und genieße den Tag am See.
Hey,
wie schon am Anfang gesagt, es trifft nicht auf alle zu (mit dem langsameren lernen).
Gruß David
Das kann ich bestätigen. Wenn ich sehe wie viele Programmiersprachen ich "verpasst" habe, und wie viele davon noch relevant sind zeigt dass es nicht so schlimm ist. Die Zeit dass man es einfach alles wirklich alles verstehen wollte ist bei mir etwas vorbei. Ich steige heute erst dann richtig ein wenn es tatsächlich benötigt wird, es gibt auch so immer genug zu tun.
" ......Einer ist jetzt 64 und immer noch geistig topfit ......" Hey, Gemeinheit :)
Mit 17 war ich Party machen und hab mein Leben genossen 🤣🤣🤣 Gut, da gabs auch noch kein Internet und auch noch keine wirklichen Rechner wie heute
Ich bin 64 und geistig topfit in meinem Bereich, besser als die meisten jüngeren. Natürlich nicht mehr so fit wie mit 25, aber das gleiche ich durch meine Erfahrung locker aus.
Ich bin auch älter und immer noch ziemlich ungeduldig, möchte zum Punkt kommen und was fertig stellen. Leider sind zumindest die ersten 8 Minuten des Videos ohne Inhalt.
Das "Problem" der älteren Softwareentwickler nennt sich "Erfahrung".
Wir wissen halt ziemlich genau, "aus dem Bauch heraus", ob etwas funktionieren wird oder nicht.
Wir überlegen us auch vorher:
- Ist unser Code wertbar
- Dokumentiert er sich selbst ?
- Ist er effizient ?
- modularisierbar ?
- Ist er PORTABEL ?
Wir haben eigentlich gar keine Lust, jedes neue Shamework mitzumachen.
Wenn "Eclipse" von den Verfassern beschrieben wird als System "for almost everything but nothing in particular", dann halte ich es mit Otto Waalkes' "Otto Kochstudio": "Und das ganze dann unter vorsichtigem Rühren in den Ausguß".
Aber Danke, VIELEN DANK, für Ihr Beispiel mit der CNC - Maschine:
Gerade an einer solchen Maschine sind erfahrene alte Männer gefragt, nennt sich "Experten". Das kommt vom lateinischen 'peritus', als "durch alles durchgegangen'. Sprich: Alles schon einmal erlebt. Der typische Programmier-Jungspund sieht nur die Blinkenlights und die tolle Graphikanimation. Aber er geht dann fröhlich mit einem Vierschneider in die Tiefe oder er kapiert nicht, daß sich die Geschwindigkeit an einer Fräserschneide je nach Radius einer Kreisbahn massiv ändert. Oder er berücksichtigt nicht, daß sich ein Werkstück erhitzt und nach dem Erkalten stimmen die Maße nicht.
Ein richtiger Softwareentwickler stellt sich erstmal an eine mechanische Fräsmaschine oder an eine Leitspindeldrehbank.
Unter Aufsicht, sonst sind die Finger weg.
Und was soll das Gerede von "In der IT muß man stets dazulernen" ? WIE BITTE ?
Also, ich kenne keine Branche, die so rückständig ist wie die "IT".
Sie sind "Microsoft Professional" und arbeiten mit steinaltem Zeugs aus den frühen 80er Jahren. Jaja, so alt ist VMS.
Microsoft hat irgendwann gemerkt, daß sie mit "Windows 95" nicht weiterkamen und kaufte das DEC-Entwicklungsteam unter Dave Cutler. Und so entstand "Windows NT = VMS++". Neu oder fortschrittlich war da nix außer dem Bluescreen. Das ganze Konzept war und ist steinalt. Und schlecht implementiert: Unter "NT4" wurde der common bufferpool des IP-Stacks vom scheduler "geswapt". Was haben wir gelacht. Überhaupt, so ein Schwachsinn, einen Pagingspace in ein Dateisystem hineinzurotzen. Oder, common Practice, die tablespaces einer Datenbank in einem Filesystem unterzubringen.
Alles alter, überkommener Käse. Aber mit Soundunterstützung bei der Installation.
Daß sich ein solcher Mist tatsächlich verbreitet hat, das danken wir unerfahrenen, unwissenden und unreflektierten "jungen IT-Liebhabern", die ihre Systeme nicht als 'Tool', sondern als 'Toy' begreifen.
Mittlerweile haben selbst die Jungspunde kapiert, daß sie die selbstgeschaffene resp. zusammengekaufte Komplexität nicht mehr überschauen und erfanden. -- TA --- TAAAAAAA --- die "WEBSOCKETS". Ich werf' mich weg. Als ich vor 20 Jahren den Webgamern erklärte, "ein ordentliches Sessionmanagement bekommt Ihr nicht mit einem Framework, sondern mit einer stehenden TCP-Verbindung", da war das Gelächter groß. Mittlerweile sind sie da, wo "wir" schon in den 80ern waren.
Nur daß der Browser bei uns noch "TN3270" hieß.
Probleme mit alten Softwareentwicklern ?
Also, ernsthaft: Ich sehe da mehr Probleme mit jungen Spielkindern und "Coaches", die meinen, jeden Trend mitzumachen, im Sinne von "Ganz agil vorbei am Ziel".
Aber es stimmt schon irgendwie: Mit MIR bekämen Sie im Projekt ganz massive Probleme.
Für mich als 21-Jähriger Softwareentwickler ist das eine wahnsinnige wertvolle Perspektive auf die Denk- und Arbeitsweise älterer Softwareentwickler. Ich habe davor noch nie so darüber nachgedacht, weil das so ein Thema ist, über das halt irgendwie kaum gesprochen wird. Wirklich, danke für das Video!
Hey,
sehr gerne, freut mich das es Dich zum denken angeregt hat.
Gruß David
Danke für den wichtigen Anstoß zum Nachdenken. Ich bin 56 und seit 1992 in der Softwareentwicklung tätig (gewesen, später mehr dazu). Ich war unabhängig von meinem Alter immer extrem motiviert, alles Neue aufzusaugen und auch praktisch anzuwenden. Mit Familie wurde das schon arg auf die Probe gestellt und erst als die Kinder selbstständig waren, konnte ich wieder Gas geben und hab aus meiner Perspektive und durch Bestätigung meiner beiden Söhne (beide SW-Entwickler) einen enormen Wissenserwerb hinbekommen (2011 iOS, android Apps entwickelt, 2018 komplett neu Webentwicklung mit vue.js, Java spring, Docker, kubernetes und und und). Ich war aber in ganz kleinen Teams unterwegs. Das hat zwar riesig Spaß gemacht, als Nebeneffekt habe ich aber gemerkt, dass es mich auch extrem angestrengt hat, dieses Niveau zu halten. Und ich glaube, da liegt das Problem. Trotz großer Motivation und auch Zeit hatte ich das Gefühl, ich komme nicht wirklich zu der von mir gewünschten Professionalität. Also hab ich mich freiwillig aus dieser Situation begeben und hab mich mit Anfang 50 komplett auf neues Terrain gewagt und hab mich bei einem namhaften SW-Dienstleister beworben und erfolgreich SW-Projekte geleitet. Mit meinem Wissen über neue Technologien hatte ich schnell die Anerkennung meiner vielen sehr jungen Teammitglieder und auf Grund meines Alters die nötige Gelassenheit auch kritische Projektsituationen gut zu meistern. Software hab ich natürlich nicht mehr entwickelt, aber ab und zu mal ein Script und eine automatisierte Auswertung hier hat mich auch weiterhin fit gehalten. Was will ich damit sagen? Jeder älter werdende Entwickler muss irgendwann schauen, dass er das macht, was er mit zunehmendem Alter auch besser kann. Es ist ein Irrglaube, mit den Jungen auf gleicher Ebene mitzuhalten. Man muss mehr Verantwortung übernehmen und dafür wird man dann auch berechtigt besser entlohnt. Ich kann jeden jungen Entwickler verstehen, der einen besser bezahlten, aber langsamer arbeitenden Kollegen als Problem empfindet. Oft kommt auch von Seiten des Älteren eine gewisse Sturheit oder auch Besserwisserei dazu, die das ganze noch weiter verschärft. Klar, es gibt immer Ausnahmen.
stimme ich in vielen Punkten zu. Aber wenn wir ganz ehrlich sind, dann ist der Marktwert von jungen Entwicklern mit ausreichend Erfahrung einfach höher, so wie es auch bei Profisportlern oder Berufen mit schönen Frauen ist. Bei Neueinstellungen ergibt sich das oft automatisch durch den Arbeitsmarkt, aber wenn ältere Kollegen insbesondere durch hierarchische Macht dagegen ankämpfen führt das bewusst oder unterbewusst zu den genannten Konflikten.
Dass ein Entwickler mehr als sein Teamleiter verdient ist eher unüblich (Stichwort Gehaltsgefüge), obwohl es eigentlich keinen Grund gibt warum das generell so sein muss. Das alleine ist ein Denkfehler der nicht nur in der IT für viele Konflikte sorgt, ob bewusst oder unbewusst.
Dazu kommt natürlich der Konflikt, dass junge Entwickler gerne "den neuesten Scheiß" benutzen wollen während alte Entwickler lieber bei "bewährte Technologien" bleiben (unterbewusst sicher auch weil lernen schwerer wird) und die Wahrheit, die irgendwo in der Mitte liegt muss zwangsläufig regelmäßig ausgefochten werden.
@@ghostkin6352es ist ein vielschichtiges Thema, was auch durch all die Kommentare deutlich wird. Wie so oft, es gibt es weder schwarz noch weiß, aber allein, mal drüber nachzudenken und zu reflektieren, ist ein guter Ansatz.
Also allgemein muss ich sagen du bist bis heute die coolste Mutti/SWE/Leiterin die ich so in Kommentaren lesen konnte. Sehr schoenes Kommentar!
Man muss aber auch sagen heutzutage, muss man auch nicht auf jeden neuen Zug aufspringen. Vor allem viele neue Entwickler hab ich das Gefuehl lernen eine Sache weil sie im Trend ist. Und das ist auch nicht das Wahre. Man darf und sollte auch wie ich finde sich die Zeit nehmen, sich in etwas zu vertiefen.
Ich programmiere nun seit etwas ueber einem Jahr und habe mich in der Zeit viel mit Python, Linux und Open Source bekannt gemacht. Vor wenigen Monaten habe ich angefangen noch Rust zu lernen und ich studiere nebenbei. Und ich war sauer auf mich, weil ich es nicht unter einem Hut bekommen habe, Rust zu lernen. Aber ich musste mir dann auch erstmal bewusst werden, was ich alles gelernt habe in der Zeit und das erstmal Sacken muss. Man sollte finde ich wenn man was neues lernt, wirklich sich die Zeit nehmen und sich darein vertiefen und es auch verstehen.
Ich feiere solche Frauen in der IT 🙌🏼👏🏻 Da haben Sie total Recht Frau @kiwibu 🤝 Ältere Kollegen müssen einfach lernen den Schritt zu wagen und in die Führungsposition gehen! Das wollen einfach die meisten SWE nicht, weil Sie ihr „Handwerk“ so sehr lieben. Dabei kann man so wichtige und tolle Architektonische Entscheidungen treffen und ein Team führen!
@@rebarius Persönliche Weiterentwicklung ja, aber ob es nun unbedingt eine Führungsposition sein muss, wage ich zu bezeifeln. Oft eignen sich Softwareentwickler nicht für eine Führungsposition, da ihnen durch den authistischen Basischarakter gewisse soziale Aspekte nicht zueigen sind, die aber für eine Führungsposition notwendig sind.
Ich bin Physiker und 56 Jahre alt. Ich programmiere für meine Python-Kollegen die mathemaitsch aufwändigen Algorithmen in C. Dadurch brauche ich mich nicht in neue Technologien einzuarbeiten, die ich gar nicht versthen möchte, weil sie eh in 3 Jahren wieder wechseln, und meine Python-Kollegen müssen sich nicht mit Mathematik, physikalischen Zusammenhängen oder Algorithmen rumschlagen, die sie eh nicht verstehen würden. Klappt super.
Das sind die Dinge die die Welt zusammenhalten. Je älter ich werde desto karger und mehr bare bones programmiere ich. Und da die Nachfrage nach Leuten die noch irgendwie verstehen was da genau abgeht immer größer wird und das scheinbar niemand mehr kann beschwere ich mich da nicht.
Das klappt nur so lange, bis Du eines Tages nicht mehr da bist. Tipp: schau Dir mal Rust an, in meinen Augen ein würdiger C-Ersatz. Grüße
Diese Aussage ist genau einer der Gründe, warum ich mich aktuell auf C fokussiere. Leider gibt es in unserem High-Tech-Unternehmen andere Sichtweisen und es wird auf die "Schnelle" mal etwas in Python probiert und erst einmal auf dem eigenen Firmenlaptop ausprobiert und dann eher unkritisch in reale Prozesse integriert. Mit z.T. negativen Folgen.
Was vielfach fehlt [ob jung oder alt] ist das Verständnis für technische Vorgänge in Kombination mit der Umsetzung in Sprachen. Entweder habe ich den SW'ler oder der Ingenieur, aber beides zusammen eher selten.
Ja, aber Mojo ist schneller als C weil Register SIMD etc ? Wenn Ziel Linux dann :-)
Dazu ein paar Gedanken:
- Zu der Zeit, also wir "Älteren" jung waren, war die Softwareentwicklung noch deutlich anders. Da dachte man, ich lerne jetzt 1, 2 Sprachen, ein Framework und so, ab und zu mal ein Update, und das geht so bis zur Rente. Inzwischen gibt es nicht nur viel Neues, sondern das Neue kommt auch immer schneller. Wenn man da einige Jahre "verschlafen" hat, wird es schwierig, den Anschluss wieder herzustellen.
- Du sagst, früher hattest du mehr Zeit, aber heute musst du den Rasen mähen und die Windeln wechseln. Mit anderen Worten: Wer jung ist, wendet mehr unbezahlte Freizeit auf, um am Ball zu bleiben. Kann man machen. Irgendwann merkt man halt, dass das Leben noch ein paar anderen Dinge zu bieten hat, und der Job ist noch nicht einmal die allerhöchste Priorität (derer gibt es nämlich nur zwei: Familie und Gesundheit).
- Und, ergänzend zum vorherigen Punkt: Viele Firmen, eigentlich die meisten, machen einen richtig, richtig miesen Job dabei, ihre Leute fortzubilden. Findet einfach nicht statt. Und dann wundert man sich.
"Wenn man da einige Jahre "verschlafen" hat, wird es schwierig, den Anschluss wieder herzustellen."
sehe ich komplett anders.
dieses "argument" ist ja beinahe schon eine floskel, die aber überhaupt nicht zutrifft.
was musst du denn aufholen?
man kann zum einen sowieso nicht alles wissen.
außerdem brauch man nicht dinge wissen die man verpasst hat, wenn sie nicht mehr relevant sind. es gibt also einiges das man überspringen kann, wenn man sich irgendwo einarbeitet.
und die grundlagen ändern sich sowieso nie. lediglich der syntax. und das ist nicht wirklich schwer.
und dann sind die meisten neuen frameworks und sprachen meistens ziemlich unnötig. es gibt ausnahmen, ja. aber warum soll ich zb. jetzt "go", "zig", "swift", "matlab" oder sonst was lernen und nutzen - wenn ich bereits alle problemstellungen in einer anderen sprache lösen kann?
meistens gibt es keinen vorteil - vielleicht findest du ja jetzt ein beispiel bei dem ich dir recht gebe aber ich finde 100 andere bei denen du mir recht geben wirst.
ich habe auch schon einige male neue dinge gelernt und nutze sie hier und da aber oft auch nicht weil es einfach unnötig ist.
90% der klassischen anwendungen und schnittstellen in der IT kann man allein schon mit python lösen. 🤣
für webentwicklung reichen auch die klassischen sprachen.
hat keinen vorteil das selbe problem mit 14 unterschiedlichen frameworks lösen zu können. da bleib ich bei vanilla js, bin auf- und abwärtskompatibel und habe ein leichteres leben.
@@thiirtysixdas Problem sind Plattformen mit proprietäre Technologien und Schnittstellen anbieten, die aber nicht von allen sprachen angesprochen werden können. Z.b. Browser mit JS, iOS mit Swift/ObjectiveC
Das mit dem "verschlafen" sehe ich nicht. Ob ich jetzt etwas Neues lernen muss weil ich was "verschlafen" habe oder weil ich erst am Anfang meiner Laufbahn stehe - ist da ein so großer Unterschied? Abgesehen davon, dass man als älterer Programmierer mehr Erfahrung hat, auf der man aufbauen kann.
Vor knapp 15 Jahren - da war ich 42 - habe ich in einem Projekt gearbeitet, bei dem es letztlich nur darum ging, Screenshots von Bildschirmen mittels Python und OCR auszuwerten und mit den XML-Ausgangsdaten, aus denen die Bildschirme generiert wurden, zu vergleichen. Wir waren zu dritt. Der eine war ca. fünf Jahre jünger als ich, der andere zehn. Beide waren studierte Softwareentwickler. Ich selber bin Quereinsteiger, ich habe in den 90ern mein Hobby zum Beruf gemacht. In dem Projekt hatte ich versucht, die zwei davon zu überzeugen, einigen Code mit Funktionaler Programmierung anzugehen. Es waren ja weder Benutzerinteraktion noch API-Calls erforderlich, also kein State, sondern fixe Ausgangsdaten. Das, was sich Funktionale Programmierer wünschen. Aber nein, es musste unbedingt objekt-orientiert gelöst werden. Der Code wurde damit geschätzt viermal so lang wie er hätte sein können. Wir waren permanent unter Zeitdruck, weil dieser Code ja geschrieben werden musste. Immerhin an einer Stelle, für die ich alleine zuständig war, konnte ich ein bisschen Abstrakte Algebra anwenden, weil ich gesehen hatte, dass ein bestimmtes Problem eine abgebraische Struktur hat, in dem Fall ein vollständiger Verband. Kurz gesagt, wenn man Mengen von Rechtecken in einer Ebene hat deren Seiten alle parallel zu den Koordinatenachsen sind, kann man _meet_ und _join_ Operatoren definieren, und die dann dazu verwenden, über jede Menge von transitiv überlappenden Rechtecken das kleinste Recheck, die sog. _Bounding Box_ (ähnlich einer konvexen Hülle), zu bilden, das sie alle umschließt. Wenn man dann noch sieht, dass man überlappende Rechtecke mengentheoretisch als verbundene Komponenten interpretieren kann (siehe "connected components algorithm"), dann nimmt man einfach den kleinsten/größten x/y Wert jeder Komponente (Menge transitiv überlappender Rechtecke) und hat gesuchte Rechteck. Mein Kollege hat das aber nicht verstanden, weswegen er eine dreifach geschachtelte for-Schleife gebaut hat, um das zu bestimmen, was natürlich nicht funktionieren konnte, weil das letztlich ein rekursives Problem ist (wegen der Transitivität) und man im Voraus gar nicht wissen kann, wieviele Verschachtelungsebenen man braucht. Außerdem beinhaltete sein Code eine Zeile die ca. 360 Zeichen lang war. Ich habe bis heute nicht verstanden, wie man sowas programmieren kann, insbesondere wenn man doch ein Software-Ingenieurs-Studium durchlaufen hat. Ich fand das jedenfalls extrem belastend, weil ich die ganze Zeit gezwungen war, unter meinen technischen Möglichkeiten zu programmieren. Es hat sich angefühlt wie mit zusammengebundenen Beinen Fußball zu spielen. Und meine Ideen waren ja nicht mal besonders kompliziert. Es waren nur zwei sehr kurze Funktionen für die _join_ und _meet_ Operatoren und eine Funktion um die verbundenen Komponenten zu bestimmen. Letztere brauchte ich nur zu googeln und hab sie dann in Python nachgebaut. Das Ganze hat einen Nachmittag gedauert.
Um es klar zu sagen: Ich halte mich nicht für ein Genie. In der Schule war ich sogar ziemlich schlecht in Mathematik. Aber Mengenlehre und abstrakte Algebra halte ich für grundlegendes Arbeitszeug beim Programmieren, und beides ist wirklich einfach zu verstehen. Die meisten Programmierer, die ich kennegelernt habe, haben aber absolut keine Ahnung davon gehabt und nichtmal verstanden, warum das nützlich ist. Der normale Arbeitsmodus scheint zu sein, möglichst schnell möglichst viel Code zu produzieren und auf keinen Fall darüber nachzudenken, ob es nicht eine mathematische Struktur gibt, mit der man ein Problem möglicherweise mit deutlich weniger Code lösen kann. Weniger Code bedeutet auch weniger Bugs, und falls es doch welche gibt, muss man deutlich weniger Code analysieren.
Außerdem: OOP ist völlig überbewertet und kaum ein Programmierer versteht, was OOP _in the wild_ tatsächlich ist: Dynamic Dispatch über einem einzelnen Parameter. Schon bei zwei Parametern muss man sich mit Double Dispatch (zB. Visitor Pattern) herumärgern. Und wie Adele Goldberg gesagt hat: "In Smalltalk everything happens somewhere else". Dasselbe gilt für alle modernen OO-Sprachen. Grausig.
@@pillmuncher67 danke sehr, du hast im grunde das gesagt, was ich gesagt habe. nur viel schöner 😇
Hey,
auch hier merke ich an, das ich das Video etwas zusammenschneiden musste, weil es komplett ausgeufert ist (man hätte da locker 60 Minuten und mehr zu machen können):
- Früher dachte man nicht das die IT sich so entwickelt: bin ich komplett bei Dir, habe ich aber so aus dem Video rausgenommen, weil ich mich dann entschieden habe, nicht nach Gründen für die Lernprobleme zu suchen, sondern über das Problem der fehlenden Sensibilität zu sprechen. Es war auch noch ein Teil drin, dass früher die Kollegen nicht so ein fundiertes Grundlagenstudium bzw Ausbildungen hatten wie heute, aber auch das hätte nicht so sehr auf das Thema eingezahlt.
- Früher mehr Zeit: Ja klar, vieles davon ist unbezahlt. Ich glaube das die Motivation in jungen Jahren eine andere ist und man es deshalb (weil man es auch noch kann), gerne in kauf nimmt. Aber auch das habe ich rausgenommen, weil sonst viele sich wieder aufgeregt hätten, weil man auch im alter noch Motiviert ist.
- Viele Firmen machen einen miesen Weiterbildungsjob: _ABSOLUT_, stimme ich Dir total zu - aber auch hier ist die Frage: Warum? Ich denke auch hier hat es etwas mit Sensibilisierung für das Thema zu tun, vielen Unternehmen ist das hier besprochene Problem einfach nicht klar.
Gruß David
Die Lernfähigkeit im Alter lässt nicht nach! Das kann ich als 66-jähriger Softwareentwickler und Dozent festhalten. Mit dem Alter kann man neues Wissen besser mit dem schon vorhandenen Wissen verknüpfen und so recht schnell lernen, auch wenn das Hirn nicht mehr so schnell ist wie vorher. Wer immer wieder Neues gelernt hat, wird so ca. gleich schnell wie die Jungen sein. Was sicherlich abnimmt, ist die Energie, die man für die Arbeit aufbringen kann. Ich werde gegenüber früher schneller müde und brauche mehr Zeit, um mich zu erholen. Nächte durchmachen oder Arbeitszeiten von über 10 Stunden am Stück liegen nicht mehr drin. Ja, da habe ich definitiv nachgelassen.
Der Technologiewandel ist auch für Junge ein Problem.... Wer sich einmal in ein Framework eingeschossen hat, möchte es nicht wieder loslassen. Man befindet sich in einer Komfortzone und brauch einen starken Schubs, um sie zu verlassen. Das sehe ich auch in der Schule ständig. Die Lernenden stöhnen, wenn wieder eine andere Programmiersprache oder ein anderes Framework eingesetzt werden soll. Warum? Sie wollen am "alten" festhalten, das kennen sie und das halten sie für gut. Das Neue ist doch nur unnötig, man könnte den Auftrag sicher mit der andern Sprache und dem andern Framework auch irgendwie hinbekommen. Das sehe ich aber nicht nur bei meinen Lernenden, sondern auch bei meinen Kollegen. Sie arbeiten lieber mit nur einer Sprache/Framework (z. B. mit TypeScript). Ich hingegen setzte je nach Modul unterschiedliche Sprachen (auch Java, Python, C# usw.) und dazu passende Frameworks ein. Das Produkt bestimmt die Hilfsmittel, das wäre eigentlich die Regel. Heute will man eher mit "modernen" und "zeitgemässen" Tools arbeiten und so auf seinem Wissen stehen bleiben.
Probleme in Teams sind komplex und nicht nur auf Altersklassen oder Technologiewandel begrenzt. Da spielen viele zwischenmenschliche Faktoren mit. Wer ein performantes Team aufbauen will, kennt diese Herausforderungen und weiss, dass dies nicht einfach ist. Dazu gibt es viel Fachliteratur ...
Noch eine weitere Provokation von meiner Seite: Dank KI werden die meisten Softwareentwickler bald arbeitslos, da die KI den Code genauso gut, dafür aber viel schneller herstellen kann. KI-generierter Code wird immer besser, bald ist es so weit.
Ja, ich bin alt und werde bald definitiv in den Ruhestand treten. Inzwischen ziehe ich den Kopf ein und hoffe, diese Zeilen lösen keinen grossen Shitstorm aus.
Ich finde schon, dass die Lernfähig etwas abnimmt, mit Sicherheit aber (wie David sagt) die Zeit, die man dafür privat aufwenden kann und will.
Aber die Vielfalt der Frameworks haben zugenommen und damit auch die Komplexität. Und da stimme ich Dir zu, das ist auch ein Problem der jungen Entwickler. Viele können nur etwas Java aus dem Studium und nun ein JavaScript-Framework wie Vue aber Angular, aber mehr ist häufig nicht drin.
Ich denke, für ältere ist oder kann es schwierig sein, einen vollständigen Technologiewechsel zu vollziehen, also Cobol zu .Net/Java oder WinForms/WPF zu Angular/Vue/React. Hier ist der Arbeitgeber gefordert, mit guten Schulungen und (wichtig!) ganz viel Praxisprojekten zu unterstützen. Die beste Theorie nützt nichts, wenn man a) kein Projekt dazu hat und b) kein Team, dass einen mitnimmt.
Die Gehaltsunterschiede sind natürlich ein Problem, aber a) werden häufig die jungen Entwickler mit höheren Gehältern eingestellt als die älteren (Fachkräftemangel) und b) ist das Wissen zu einer Technologie im Gegensatz zu Softwaredesign & Co eher unwichtig. Hier spielt die Erfahrung eine sehr große Rolle.
Wen man ehrlich ist lässt die Leistung des Gehirns nach und man lernt einfach nicht mehr so schnell. Man profitiert aber im Alter von seinem bisherigen Wissen und Erfahrungen und kann damit einiges ausgleichen, das ist richtig
Danke für die Worte. Ich bin auch sehr dicht an den 40 dran und war eher verwundert von dem was David Tielke da sagte. Ich habe bei mir selbst eher den Eindruck schneller zu lernen und zu verstehen, weil ich einfach einen sehr guten Überblick im Laufe der Zeit über alles bekommen konnte. Ich befasse mich allerdings auch sehr viel mit verschiedenen Themenfeldern. Ich stecke also wahrscheinlich mehr Zeit in den Beruf als die meisten 40-jährigen.
Mein Problem mit älteren Entwicklern ist auch gar nicht mal unbedingt, dass sie langsamer lernen oder dergleichen, sondern dass ich eben auch oft den Eindruck habe, dass sie nicht so richtig motiviert sind noch mitzuziehen, sondern das ganze neue Zeug als Unsinn abtun. Wenn diese Kollegen, die vielleicht nicht wollen oder nicht können, dann aber mehr Gehalt kriegen, nur weil es die älteren Kollegen sind... wieso sollte ich mich dann überhaupt anstrengen? Das Gehalt sollte doch idealerweise den Mehrwert widerspiegeln, den jemand mit einbringt oder nicht? Darauf habe ich ein wenig in dem Video gewartet... dass etwas gesagt wird in Richtung "Oft wird übersehen, dass die älteren Kollegen aber auch viele Dinge mitbringen, die sich nicht gerade auf den Code auswirken. Nämlich folgende..." - aber da kam nichts in der Richtung.
Zum Thema "Lernfähigkeit" möchte ich nichts sagen, da ich als junger Kerl gelangweilt in Meetings saß, und als Bald-Rentner noch immer gelangweilt in Meetings sitze. Unterschied: damals habe ich mich beschwert, dass es so lange dauert, heute habe ich ein Handy und lese Zeitung.
Was so ist: Junge Leute setzen Aufgaben "schneller" um als ich. Und da liegt mitunter Faktor 2 oder noch mehr dazwischen. Wirtschaftlich gesehen ist das enorm.
Was aber auch so ist: Junge Leute haben oft (erschreckend) wenig Erfahrung. Z.B. das man Kundendaten nicht in mehreren Systemen _undabhängig voneinander_ speichert. So haben wir es in meinem letzten Startup geschafft, mit 200 Personen binnen 2 Jahren 17 "CRM-Systeme" zu bauen. Geld haben wir natürlich nicht verdient, dafür lustige Nachrichten von Kunden bekommen warum er denn das gleiche Produkt noch einmal kaufen soll - wir sollten den ersten Kauf doch erst einmal liefern. Aber die Entwickler fanden es cool, wenn man in allen möglichen Services einen Kunden anlegen konnte, der "streng nach Microservice-Doktrin", sich um seine Daten aber nicht um die Daten anderer Services kümmert. "Prozesse" haben die Jungen auch nicht gekannt, so dass wir wegen der 17 CRM-Systeme den Kunden für ein Produkt tatsächlich vier Logins mitgegeben haben. Ach ja, wir reden hier über B2C, nicht über B2B mit Rollenmodellen :)
Obwohl ich nicht ansatzweise versucht hatte mit den Jungen zu konkurrieren sondern mich primär auf die Rolle des Architekten konzentriert habe konnte ich leider nicht viel richten. Das Durchschnittsalter war 28 und es hatte fast jeder die Meinung vertreten, dass man keine Architekten, Analysten, Designer, und Tester braucht weil Softwareentwickler das alles sowieso viel besser können.
Man kann das Lernen einfach runter brechen. Es ist der Spaßfaktor. Wenn einem das Framework nicht gefällt, dann ist auch das lernen in diesem Bereich schwieriger.
Mathematik war ich in der Schule auch nur durchschnittlich. Später unterdurchschnittlich! Das was hängen geblieben ist, war alles auf einen Nenner runter zu kürzen.
Was gebraucht wurde für Elektronik / Elektrotechnik hat gereicht. Da war lernen überhaupt kein Problem. Als RUclips aufkam und mir da Einblicke in das Geldsystem zu ermöglichen, war auch kein Problem damit klar zu kommen.
Kurzum: Je höher der Spaßfaktor um so besser und schneller lernt man auch. Eigentlich sollte das auch mit 80 Jahren honoriert werden.
1993 hat mein Nachbar mit 82 Jahren die Prüfung zum Amateurfunk ablegen wollen. Es haben nur paar Punkte gefehlt. Leider durchgefallen. Hätte man trotzdem ein Auge zudrücken können.
Wenn man über Jahrzehnte erlebt, wie die Hersteller der Programmiersprachen (z.B. Microsoft) alle Jahre neue Methoden herausbringen und das vor 5 Jahre gelernte als obsolet deklarieren hat man irgendwann einfach keine Lust mehr, diesen Zirkus mitzumachen. Es braucht schon viel Glauben, um das alles als Fortschritt zu betrachten. Es ging immer nur darum, mehr Einfluss von der Peripherie (Anwender/Entwickler) ins Zentrum (den Großfirmen) zu verlagern. Meinen Pakt mit Mephisto habe ich asap beendet.
dem stimme ich absolut zu - es geht um Kommerz und Markteinfluß und dies treibt die Gier der Großkonzerne - es geht nicht mehr um Fortschritt wie in den Anfangsjahren
Frameworks kommen und gehen. Ihre Aufgaben ähneln sich oft und die Logik dahinter ist auch fast immer das gleiche. Solange da nichts kommt was wirklich grundlegend anders ist, z.b. false==1 mache ich mir keine Sorgen. Von jüngeren Kollegen werde ich respektiert, genauso wie ich sie respektiere. Es hat jeder seine Erfahrungen, wenn auch unterschiedlich viele. Die wenigen Fälle, in denen mich jemand vorführen wollte, waren stets völlig inkompetente Dummschwätzer, die früher oder später wieder weg waren. Solange das so bleibt mache ich mir keine Sorgen.
Hey,
freut mich :)
Gruß David
Kann ich nur unterschreiben. "... Kommen und gehen..." Genau. Und da ähnelt sich auch vieles. Im Prinzip lernst du das Grundlegende einer neuen Technologie an einem WE als alter Hase. Geht mir jedenfalls so.
Genauso ist es. Es gibt intelligente und weniger intelligente Entwickler. Die intelligenten sind rar und sind immer technologisch auf dem neuesten Stand weil sie gar nicht erwarten können, wann die Firmen endlich neue Technologien nutzen. Nicht die Entwickler, sondern die Firmen hängen oft 10 Jahre zurück
Das ist auch meine Wahrnehmung - das meiste was mir als der "Hot-New-Shit" verkauft wird war schnell wieder out, oder etwas das ich schon kannte (unter anderem Namen).
Beispiel, Async und Node (ist jetzt nicht mehr neu, aber gut). Das ist die Event Loop von Windows 3.11. Also eher ur-alt.
@@6a616e Alte Dinge mit neuen Namen. Das letzte wirklich neue in der Programmierung war funktionale Programmierung. Aber sonst sind es immer die gleichen Ideen nur mit einem neuen Namen.
Nun ja, als mittlerweile 65 jähriger Softwareentwickler teile ich Deine Sicht nicht. In den letzten 40 Jahren hat sich in der Informatik so gut wie nichts verändert. Ich nehme meine Vorlesungsnotizen von 1989 und da ist noch immer alles gleich. Gekommen sind neue Begriffe für von teilweise uralten Konzepten. Grosse Unterschiede gibt es z.B. bei funktionalen Sprachen zu OOP. Der Rest ist vernachlässigbar. Wer in der IT nur Herstellerwissen als Basis kennt, der ist am falschen Ort. Das Konzept gilt in jedem Beruf. Es gibt Grundlagen und es gibt Praxis. Praxis nennt man auch Erfahrungen. Wer Leistung nach Anzahl Codezeilen misst, hat eh ganz andere Probleme. Und Frameworks etc. sind nur eines: Werkzeuge und die kommen und gehen.
Wahnsinn! Das gleiche gilt im Rechnungswesen! Da haben sich vermutlich seit den 70er Jahren auch keine Grundlagen geändert, denn die diversen Kostenrechnungsmethoden gab es damals auch alle schon. Wenn sich die Software ändert, bleiben die Kernparameter dennoch immer die gleichen. Nur die Abfragetools werden immer unübersichtlicher, und sind oftmals gar nicht mehr voll integriert. Die allermeisten Nutzer kennen nur eine Software und werden somit relativ schnell zu Fachidioten. Im Rechnungswesen kommt noch das Problem dazu, dass es kaum allgemeingültige Verfahrensabläufe gibt, und jedes Unternehmen in seinem eigenen Saft schmoren kann, das aber wiederum für das Nonplusultra hält. Ich bin Berater für zusammengebrochene Buchhaltungen und Kostenrechnungen, z.B. für Übernahmen, hohe Fluktuation. Oftmals darf ich in die Prozesse gar nicht eingreifen, obwohl es ohne weiteres möglich wäre, weil sich zu viele Beteiligte dabei auf den Schlips getreten fühlen würden. Aber es wird ganz gut bezahlt.
"In den letzten 40 Jahren hat sich in der Informatik so gut wie nichts verändert."
Im Prinzip ja.
Aber es ist alles in Libs. Und die muss man beherrschen. Dann upgraden.
Und Pipelines statt Makefiles.
@@Asgaia Mitarbeiter haben die Angewohnheit, regelrechte Datenlandschaften zu generieren, und machen immer wieder dieselben Kopien der gleichen Bewegungsdaten, weil sie nie Datenhygiene gelernt haben. Mittlerweile springen Datenschutzbeauftragte auf den Zug auf, und haben Vorschriften entwickelt, nach denen Daten regelmäßig wirklich gelöscht werden müssen, damit überhaupt noch jemand durchblickt. Spätestens beim Ausscheiden von Mitarbeitern wird das zum Problem, weil sich kaum einer traut, zu entscheiden, ob diese Daten gelöscht werden können oder nicht.
@@AsgaiaDas liegt bei dir. Meine Erfahrung ist, dass nur schlechte Entwickler für alles Frameworks benutzen.
Ich kann überhaupt nicht bestätigen, dass die Älteren schlechter im Ergebnis sind. Meine Erfahrung ist eher, dass Ältere auf Gründlichkeit und Robustheit setzen und nicht so „featuregeil“ sind… Sie leiden nicht so an Featuritis. Ihr Code läuft und läuft und läuft. Weil man muss erstmal zehntausend Bugs produziert haben, um Bugs vermeiden zu können.
Ich bin jetzt auch Ü45 und muss feststellen, dass unglaublich viel Software für die Mülltonne produziert wird. Software, die man nur unter Zwang nutzen würde. Meine Strategie ist genau die des Schreiners, der NICHT auf die CNC-Fräse umsteigt, sondern den klassischen Hobel weiter verwendet und hochwertige Möbel auf Kundenwunsch erstellt oder die Beschläge erneuert. Kerneltreiber für Unix/Linux/Mikroprozessoren oder auch Software für die Unix-shell. Die Strategie kann auch funktionieren. Man muss nicht jeden Trend mitmachen. Ich renoviere quasi Antiquitäten und eine alte Kommode aus MassivHolz überlebt so eine Ikea Kommode aus PressHolz locker (bildlich gesprochen).
Geistige Leistungsfähigkeit bei einem gesunden Menschen ist von ab dem erwachsen werden bis 70 etwa gleich. Die Motivationsfähigkeit nimmt ab, dass führt zu längeren Zeiten beim lernen, sofern man nicht die passende Motivation hat (Stand Hirnforschung).
Das kann ich nur bestätigen
Kann ich auch Bestätigen. Habe in ein Aufbaustudium gelernt. Die Aussage je älter je langsam gelernt wird ist umgangssprachlich entstanden. Forschungen belegen dass es um Motivation geht. Vor einigen Jahren, haben wir in einen Altersheim einen Kurs gehalten um Bewohner beizubringen im Internet zu Surfen. Wie schnell die gelernt haben, wird mir keiner Glauben! Da können sich manche jungen eine Scheibe davon abschneiden.
Ich denke schon, dass das Kurzzeitgedächtnis nachlässt.
Aber ja, Motivation ist alles. Das gilt ja auch schon für Schüler. Was unterscheidet gute und schlechte Schüler? Nicht so sehr der IQ, sondern ob sie "Bock" haben.
Kann ich nur zustimmen. Ich habe mal in grauer Vorzeit meinen Fachinformatiker gemacht und dann 20 Jahre komplett was anderes gearbeitet und arbeite mich jetzt wieder in die Informatik ein. Was mich fast erschlägt ist die Masse an neuen Tools aber ich habe keineswegs den Eindruck, dass ich irgendwie langsamer lerne.
Danke für's beruhigen🙂
Nicht die Lernfähigkeit nimmt ab, sondern die Motivation. Ich bin Chefarchitekt eBusiness in einem DAX-Konzern, 58 Jahre alt und laut meinen Chefs der "große Exot", weil ich mit meinem Wissen auf dem Level meiner erheblich jüngeren Mitarbeiter stehe (und seit 2 Jahren in der Freizeit ein recht komplexes Open Source-Framework für IoT hochziehe, was bald fertig ist). Gleichaltrige Kollegen beschäftigen sich mit dem Vorruhestand, und das auch in den USA und in China. Das Problem ist, dass viele Leute die Arbeit machen, um Geld zu verdienen, aber nicht, weil sie etwas bewegen wollen. Würde man den 50jährigen in der IT 2 Mio. Euro überweisen, würden 80% sofort kündigen. Und das lässt sich vermutlich auf viele andere Berufe verallgemeinern.
Ist ein wichtiges Thema, was du ansprichst. Ich denke, dass du als Selbstständiger Software-Entwickler aber nicht so sehr davon betroffen bist, weil du Theoretisch einfacher Themengebiete wechseln kannst um weiterhin auf dem aktuellen Stand zu bleiben. Wenn du als Angestellter zu lange in der selben Firma verweilst und die nicht ihre Software aktualisiert, dann ist es viel schwieriger etwas aufzuholen.
Hey,
doch davon bin ich sogar sehr stark betroffen. Ich Arbeite in vielen Bereichen: Prozesse, Anforderungen, Architektur, Entwicklung, Test, DevOps, Support... Die Themen suche ich mir nicht aus, sondern muss das machen was in den Projekten ansteht. Früher war meine Welt das .NET Framework: heute kenne ich noch nicht mal die Neuerungen von C# 9 - 12, müsste die aber nachholen. Gleiches gilt für DevOps Technologien wie Docker und Kubernetes, da habe ich auch lange nichts gemacht.
Das es schwer wird wenn die Firma nach langer Zeit so einen technologiesprung macht, war genau das was ich hier gemeint habe.
Gruß David
@@DavidTielke Ich denke Du erwartest ein bisschen zu viel von Dir selbst. Wenn Du C# 9 -12 brauchst, wirst Du Dir das schon recht schnell aneignen. Als Selbständiger hat man natürlich ein bestimmtes Spezialgebiet, das man beackert, aber wenn man da nicht alles ständig verwendet, dann fällt man natürlich zurück. Aber die Jungen sind dann auch nicht in allem voraus. Vielleicht in C#, aber dann auch nicht gleichzeitig in Vue.js, Angular oder React oder Datenbanken oder der Cloud. Aber als Selbständige oder Ältere erwarten wir von uns in allen Bereichen weiter zu sein. Das ist aber nicht realistisch.
Bin bei 3:40 und frage mich, ob "das Problem" irgendwann nochmal benannt wird ^^
So, wir sind jetzt bei 3:58 und du sprichst seit Sekunde 1 über ein Problem, aber hast BIS JETZT nicht gesagt, was denn nun das Problem ist
Dann schalt am besten schnell ab
@@DavidTielke also ich war kurz davor... ;-) Das war jetzt aber nicht bilderbuchmäßig aus dem "Feedback annehmen" Kurs
Das fiel mir auch grade auf. Aber viel mehr Probleme fielen mir auch nicht ein, die ich mit älteren Kollegen verbinden würde.
Im Prinzip kommt er erst nach 14 Minuten so laaaangsam auf den Punkt. Kürzer wäre mehr gewesen, trotz des interessanten Themas.
@@o21211671 Hey, das wäre auch Dein gutes Recht :) Ich habe schon viele solche Videos gemacht, wo sich nachher immer wieder einzelne Leute angegriffen gefühlt haben. Um das zu verhindern, gibt es einen (zugegeben) recht langen Disclaimer am Anfang. Ich verstehe jeden der nicht die Zeit hat, sich das anzuhören - deshalb war das durchaus ernst gemeint, weil wenn 4 Minuten Erklärung zu einem durchaus sensiblen Thema zu viel ist, sollte man seine Zeit lieber anderweitig investieren. Ich freue mich über jeden konstruktiven Kommentar hier sehr, egal ob positiv oder negativ. Aber diese Art von Kommentaren ergibt halt wenig Sinn.
Gruß David
Durch Zufall auf den Kanal gestossen und ein paar Videos esehen die letzte Zeit. Ich habe nichts mit Programmierung am Hut obwohl wir viel Software machen. Deine Videos sind klar am Thema & verständlich. Letzteres ist eine Gabe vom Schöpfer oder Eltern :) welche du wertvoll einsetzt. Weiter!
Hey,
freut mich das Dir der Kanal und die Videos gefallen :)
Gruß David
Verzeih mir, aber weil du so weit ausholst bei der „Problembenennung“ hab ich schon komplett weggeschaltet und war nicht mehr dabei.
So fällt es mir jedenfalls sehr schwer und es ist verdammt mühesam dir zuzuhören und den Faden nicht zu verlieren.
Es „turnt“ mich eher ab und ich bin eher genervt, weil das Kernproblem nicht sofort beim Namen genannt wird und dann darauf eingegangen wird 😅.
Sorry, ist nur meine Sicht zum Video. Muss nicht für alle gelten.
Danke für das Video David 💛! Super wichtiges Thema. Ich habe jetzt in meinem Unternehmen knapp zwei Jahre dafür gekämpft, dass wir acht Weiterbildungsstunden mit freier Themenwahl pro Monat während unserer Arbeitszeit erhalten. Gerade ältere Kollegen werden hoffentlich besonders davon profitieren, da ihre Freizeit nun nicht mehr mit der Weiterbildungszeit kollidiert.
Hey,
sehr gut gemacht, 1 Tag pro Monat klingt nach einem guten Anfang :)
Gruß David
Ich bin jetzt auch Mitte 40 und halte einfach strikt an RTFM fest, wenn es um neue Technologien geht. API Docs lesen statt Autocomplete, wenn möglich Source Code lesen anstatt sich blind auf das Framework zu verlassen. Den Fokus gänzlich darauf setzen, die Grundlegende Designphilosophie und die Workflows der neuen Technologie zu erfassen, bevor man auch nur eine Zeile Code schreibt. Vielleicht bin ich damit anfangs in der Einarbeitung "langsamer" als jemand, der einen anderen Ansatz hat, aber nach ein paar Wochen macht mir keiner mehr so schnell noch was vor.
Der große Vorteil, wenn man sich erst einmal ausführlich einliest ist auch, dass der Kopf die Informationen dann nebenbei beim Hecke schneiden, Windeln wechseln usw. verarbeiten kann 🙂
Ich bin allerdings auch erst mit 30 in die professionelle Softwareentwicklung quer eingestiegen und kann daher schlecht einschätzen, ob mir das Lernen, als ich jünger war leichter oder schwerer gefallen wäre. Vorher als reiner Hobby Coder war ich ja nie gezwungen mich irgendwo einzuarbeiten, sondern konnte einfach nach "Gutdünken" vor mich hin programmieren.
Vielen Dank für dieses wirklich gute Video!
Ich bin nun kein klassischer Software-Entwickler, sondern arbeite in einer Stadtverwaltung in der IT und entwickle dort auch immer mal wieder kleiner Software-Lösungen. Ich werde in ein paar Wochen 52 und muss ehrlich sagen, dass ich kaum noch mit den neuen Technologien zurecht komme, wenn es um Entwicklung geht. Ich habe mit 12 Jahren angefangen zu programmieren auf einem Sinclair ZX8, der grade einmal ca. 20 BASIC-Befehle und nochmal etwa 20 Funktionen hatte. Der Arbeitsspeicher war grade einmal 1 kB (nicht MB oder GB, oder gar TB!). Später bekam ich dann eine Speichererweiterung auf 16 kB. Das sind Größenordnungen, in denen Programmierer heute gar nicht mehr denken.
Dann bekam ich einen C64, der ganze 64 kB Speicher hatte. Und auch der wurde in BASIC programmiert. Es gab ein par Befehle mehr, als beim ZX81, die ich dann meinem Repertpire hinzufügte und munter ging es weiter mit dem Spaghetti-Code.
Dann kam 1991 der erste PC. Da ich schon fast 8 Jahre in Basic programmiert hatte, machte ich natürlich so weiter. Irgendwann bin ich zu Visual Basic gewechselt und dann zu VBA. Mit der Verbreitung des Internet im Laufe der 90er jahre habe ich dann noch HTML, CSS, Javacript und PHP gelernt und vor ein paar Jahren ist dann noch Python und Arduino dazu. Aber am wohlsten fühle ich mich noch immer in BASIC, weil das einfach für immer gelernt ist.
Objektorientiertes Programmieren zum Beispiel macht mir noch immer große Probleme, weil ich es einfach gewohnt bin in Prozeduren zu denken. Ich hoffe, dass ich mit meinem Wissen noch bis zum Ruhestand druchkomme, denn neues Wissen aufzubauen, ist tatsächlich inzwischen eine Herausforderung.
Daher danke, dass du für Verständnis wirbst! Und wie du es auch schon gesagt hast, die, die heute jung sind, kommen in 25-30 Jahren in die gleiche Lage.
1. Wenn Du es nicht brauchst, warum solltest Du dann auf dem neuesten Stand sein? Wenn Du Deine Aufgaben im Prinzip mit kleinen Progrämmchen lösen kannst, warum solltest Du eine JavaScript-Framework lernen?
2. Herausforderung bedeutet übrigens nicht, dass etwas unmöglich ist.
3. "am wohlsten fühle ich mich noch immer" und "weil ich es einfach gewohnt bin" ist bei Dir anders als bei mir. Ich fühle mich am wohlsten, wenn ich eine neue Sache ausprobieren kann und ich bin es gewohnt mich immer weiter herauszufordern. Ich würde mir z.B. mal wünschen mit Graph-Datenbanken zu arbeiten oder Cassandra muss aber in der Regel mit relationalen Datenbanken vorlieb nehmen und die habe ich glaube ich schon so ziemlich ausgereizt..
@@jayeff6712 Ich mache auch gerne neue Sachen. Aber wenn es drauf ankommt möglichst schnell ein Ergebnis zu haben, dann klappt das eben am besten, mit Werkzeugen, die man kennt. Neues ausprobieren mache ich dann lieber im privaten Bereich, wo es ruhig dauern kann und es auch nicht schlimm ist, wenn es gar nichts wird.
Langwieriges und sich inhaltlich wiederholendes Video - das hätte man auch problemlos in 5 Minuten packen können.
Ich denke eine große Fehlerquelle liegt daran, dass viele häufig ein Framework lernen, statt dahinter liegende Konzepte.
Klar lernt man im Alter langsamer und Frameworks können binnen 2 Jahre obsolete sein. Aber wenn man durch seine Berufserfahrung viele Konzepte und Methodiken gelernt hat, ist man den Jungspunden einiges voraus.
Es ist schön und gut wenn du Docker gelernt hast. Viel besser wäre es zu verstehen wie containerd, OverlayFS und Namespaces funktionieren. Dann kann sich ein Framework ändern wie es will, die Grundmaterie bleibt die gleiche.
So ist es. Dann hat man nämlich auch nicht das Problem nur 15% mit auf die neue Platform zu transportieren ... die meisten Sachen die so rauskommen werden nur mit schöneren Begriffe und mehr Klickybunty umhüllt. Selten das da wirklich strukturelle Innovationen dranhängen. Fleißiges auswendig lernen funktioniert in der Softwareentwicklung nur horizontal.
Hey,
ja absolut, die Konzepte sind das was bleibt. Aber am Beispiel Desktop / Web sieht man aber schon, das hier ein großer Teil der Konzepte anders ist. Diese Transition z.b. ist einer der schwierigsten die ich in Beratungen und Trainings mit Teilnehmern durchlaufen muss.
Gruß David
@DavidTielke
@DavidTielke Genau das ist der Punkt, die Konzepte bleiben wesentlich länger als die Frameworks und Sprachweiterentwicklungen. Im Alter lernt man anders als in jungen Jahren, man lernt eher qualitativ, weniger quantitativ. Was du im Video beschreibst, dass du in jungen Jahren an einem Wochenende komplett neue Systeme gelernt und anwenden konntest, liegt aber auch daran, dass die Anforderungen früher auch oft einfacher waren. Ich habe z.B. Fortran als meine 1. Programmiersprache gelernt und hatte die Möglichkeit in einem Projekt mitzuarbeiten um mein erstes Geld zu verdienen. Mein Problem war aber, dass das Projekt in Cobol war und ich aber noch nie was in Cobol gemacht hatte. Mein Freund, mit dem ich mich zusammen für dieses Projekt bewarb, meinte nur: "Kauf dir ein Buch, in einer Woche kannst das". Das machte ich auch und ich wickelte meinen Teil im Projekt zur vollsten Zufriedenheit des Kunden ab.
Was die Weiterbildung im Alter betrifft, die meisten meiner früheren Kollegen haben kaum was für die Weiterbildung investiert, vor allem nicht, wenn die Firma auch nichts investiert hat. Der Grund war aber auch, dass die SW Entwicklung nur mehr der Job war und nicht das große Interesse an der Technologie. Aber das gilt natürlich auch für jüngere Kollegen, ich hatte keine Probleme mit jüngeren Kollegen, wenn sie genauso interessiert waren wie ich. Jedoch mit allen Kollegen, die nur ihren Job machten, egal wie alt sie waren.
Und nun zum letzten Punkt, den du im Video leider nicht erwähnt hast, den ich aber den wichtigsten Punkt für SW Entwickler halte. Es ist die Neugier auf Weiterentwicklungen in unserer Branche. Ich hatte vor 20 Jahren die Chance ein Jahr lang reine Weiterentwicklung zu machen, einen Umstieg von DB- auf Web Entwicklung. In dieser Zeit habe ich auch mitbekommen, dass es User Groups gibt und diese User Groups auch Treffen im lokalen Bereich abhalten. Das war für mich die Gelegenheit mich mit vielen jungen Entwicklern außerhalb meiner Firma auszutauschen und neue Konzepte und Frameworks kennenzulernen. In der Zwischenzeit sind diese User Groups zu Meetups geworden, aber das Konzept ist dasselbe. In meiner Firma war ich dann bis zu meiner Pension mit 65 immer noch ganz vorne dabei und verstand diese Konzepte meistens genau so gut wie die 40 Jahre jüngeren Kollegen und konnte sie auch so schnell umsetzen.
Nach meiner Pension habe ich noch 6 Jahre weitergearbeitet, aber die Corona Lockdowns haben die Meetups ausgebremst, danach verfiel auch meine Motivation. Auch weil ich keine Vollzeit mehr arbeiten wollte, war ich auch nicht mehr so motiviert neueren Entwicklungen nachzugehen. Jetzt programmiere ich "nur" mehr für mein Smart Home und auch nur dann wenn ich Lust dazu habe. Aber ich denke, mit über 71 Jahren habe ich auch das Recht dazu ;)
Moin, gutes und wichtiges Thema! Eine etwas deutlichere Strukur im Video wäre schön. Zum Beispiel:
1."Langsameres Lernen mit zunehmendem Alter"
2."Weniger Zeit fürs Lernen außerhalb des Berufes mit zunehmendem Alter"
3."Kippende Stimmung - Durch Leistungsdruck und mangelndes Verständnis"
4."Effekte und Auswirkungen"
5."Lösungsansätze / Gedanken dazu das man selbst auch alt wird und daher eine Kultur des Verständnisses schaffen sollte die einem selbst eventuell auch mal zu gute kommen könnte."
Mir kam so etwa bei 4 Minunten auch der Gedanke "wann kommt der auf den Punkt" aber deine Gedanken am Ende des Videos scheinen mir sehr reflectiert und sozial besonders wichtig.
Hey,
der erste Kommentar zur wirklich schlechten Videostruktur der sachlich und konstruktiv ist, danke für Deine Mühe :)
Du hast vollkommen recht, weil ich versucht habe alles genau zu formulieren, keinem auf die Füße zu treten damit bloß keiner denkt es geht pauschal um alle alten Entwickler habe ich viel zu viel Zeit vergeudet, bis das tatsächliche Thema losgeht. Während der Videoaufnahme ist mir das gar nicht so sehr aufgefallen, sondern erst später in der Nachbearbeitung und da habe ich dann versucht zu retten, was noch zu retten war (ursprünglich war das Video 35 Minuten lang) - aber leider ist das meist sehr in der Postproduktion schwierig, ohne das man die eigentliche Aussage des Videos kaputtmacht. Neuaufnahme ging zwecks Wetter und Zeit nicht, deshalb habe ich versucht zu retten, was noch zu retten war :)
Die Struktur die Du vorgeschlagen hast, steht fast 1:1 inhaltlich auf meinem Spickzettel (+ die Geschichte mit dem Schreiner), aber leider ist sie inhaltlich total ausgeartet. Normalerweise habe ich Kapitel in meinen Videos, damit Zuschauer die für sie unwichtigen Dinge überspringen können, aber bei diesen Video wo es um persönliche Probleme mancher Entwickler geht, mache ich das nicht mehr. Weil 90% der Zuschauer überspringen den Teil, wo erklärt wird, wen man genau mit seinen Argumenten adressieren möchte und beschweren sich dann am Ende, warum man pauschal über eine ganze Gruppe so urteilt.
Wenn Du Dir die meisten Kommentare hier anschaust, siehst Du genau das Muster. Ich habe zu beginn gesagt wen ich meine (ältere Entwickler die ein spezielles Problem haben), dann was das Problem ist (langsames lernen aufgrund verschiedener Gründe) und ein gefährliches Resultat (das jüngere denken diese alten Entwickler sind schlecht), was dazu führt das diese Entwicklergruppe unfair behandelt wird. 90% der Kommentare hier, drehen sich aber nur darum, dass "nicht alle alten Entwickler schlecht sind", "jüngere auch viele Macken haben", "es nicht stimmt das man im alter schlechter lernt". Die eigentliche Message das jüngere Entwickler das Problem kennen sollen um in solchen Situationen mit den Kollegen fairer umzugehen, geht komplett unter.
Aber Lessons Learned für mich: das war so nichts, da muss ich dran arbeiten - das muss beim nächsten Mal deutlich besser werden.
Gruß David
Also das Gelabere am Anfang (drivel, caveats, drivel, ...) ist schon nervig. Gerade fuer Aeltere, die ... nicht ... mehr .... so ... lange ... leben. >:-}
Hallo David, ich kann Deinen Gedankengang gut nachvollziehen, weil er bei Dir in der Praxis definitiv genauso vorkommt. Ich würde das Spielfeld aber gerne noch etwas erweitern. Tatsächlich gibt es auch Unternehmen/Anwendungsbereiche etc. Wo wir es nicht 'nur' mit Projekten zu tun haben, die in einer aktuellen Technologie in wenigen Monaten/Jahren umgesetzt werden. Ich komme aus einer Branche, wo eine SW-Lösung über mehrere Jahrzehnte einem Lebenszyklus unterliegt (ja, sogar ohne dass ein Monolith herausgekommen ist *zwinker*). Dabei beobachte ich an dieser Stelle, dass die älteren Entwickler gerade diejenigen sind, die sich in dieser Software so gut orientieren können, dass diese auch für alle Fragen rund ums Produkt als die Experten gelten. Gerade bei der Formulierung von Anforderungen und der Definition, was gemacht werden soll, kann man auf dieses Wissen nicht verzichten. Wo wir wieder zusammenkommen, sind wir bei genau jenen Funktionen, die ganz klar sinnvollerweise mit den aktuellen Technologien erledigt werden müssen, die dann auch aus einem Team von alt und jung noch am besten zu bewerkstelligen sind. Ich finde, man sollte ganz klar in seiner Unternehmenskultur darauf achten, dass aus diesem 'miteinander' kein 'gegeneinander' wird. Jeder hat in dieser Struktur seine Stärken und Fähigkeiten, die wir nutzen sollten.
Danke für dieses wertvolle Video. Im Vergleich zu dir mit deinen jugendlichen 40+ bin ich schon ein Methusalem. Ich habe das Verhältnis zu älteren Kollegen früher oder zu jüngeren bis sehr viel jüngeren Kollegen jetzt immer als eine Art Generationenvertrag gesehen: Aus der Sicht des jetzigen Zeitpunkts: Man nimmt sich die Zeit, wenn junge Kollegen etwas fragen, erklärt geduldig, warum es geht, sitzt nicht auf seinem Wissen sondern teilt es, dokumentiert Dinge, damit sie beim nächsten Mal nachsehen können und vor allem interessiert sich für das, was sie machen und die Technologien, die sie einsetzen. Und versucht letztere auch dann schon, trotz Familie, Haus und Garten usw., zumindest ansatzweise zu lernen, wenn man sie selbst noch nicht konkret braucht, denn der Zeitpunkt kommt schneller als geplant. Auch darf man sich nicht zu schade sein, die Jungen zu fragen, ob sie mal in einer ruhigen Phase Zeit hätten, einem dies und jenes zu erklären. Bis jetzt bin ich damit ganz gut gefahren und hoffentlich passt das auch in dem knappen Jahrzehnt bis zum Erreichen des Pensionsalters.
Ich bin 52 Jahre und seit 2000 in der ENtwicklung. Das Thema ist sehr sensibl und hängt starkt mit der Persönlichkeit des Entwicklers ab. Mir kommt es zu gute, das ich in den letzten 25 Jahren 9 mal die Firma gewechselt habe (zwei direkte Pleiten, eine absehbare) und somit zur Weiterbildung gezwungen war. Mit jedem Wechsel muss man sich neu erfinden. Dies hält auf der einen Seite fitt, kostet aber zusehens mehr Energie und Kraft. In der (nun hoffentlich letzen) Firma habe ich zum ersten mal den Umstand, das ich nicht zu den ältesten gehöre.
Sehr interessantes Video, auch wenn es erst nach der Hälfte der Zeit erst endlich verrät, was Sache ist.
Ich bin Ende 50 und seit einiger Zeit dabei. Ich habe die Computergeschichte miterlebt, kann mich noch erinnern an Zeiten mit dem IBM XT, laaaange vor Google, Facebook und Co. Meine Kollegen, die mich seit Jahrzehnten begleiten und die neuen Kollegen, die immer wieder im Laufe der Zeit dazugekommen sind, sind eine interessante Mischung. Viele Chefs sind jünger als ich.
Ich sehe ein Problem, dass im Video nicht angesprochen wurde: Viele ältere Kollegen haben einfach keinen Bock mehr, jeder Sau, die durchs Dorf gejagt wird, hinterherzulaufen. Nicht Faulheit oder mangelnde Zeit ist das Problem in dem Fall, sondern mangelndes Interesse.
In dem Maß, in dem ich nicht-technik-affine Freunde haben, die einfach weder soziale Medien noch PCs verwenden wollen, in dem Maß habe ich Entwickler-Kollegen, die einfach nicht schon wieder was lernen wollen, was bald wieder alt ist oder nie groß wird (es gab auch einige Sackgassen!).
Neue Programmiersprache? - "Wieso denn, ich bin mit C und Visual Basic bisher IMMER klargekommen"
Cloud-Anwendungen? - "So ein Unsinn, man weiß nicht mal wo die Daten sind und außerdem wer kann da alles zugreifen?"
Windows 11 und Office365? - "Och nee, wieder alles anders und ich bin mit meinem Windows 7 noch super-happy!"
Agile Projekte? - "Hatt ich nie, will ich nicht, braucht kein Mensch, nicht mit mir".
Ich erwische mich da selber oft genug und selbstverständlich ist es auch für mich VIEL schwerer als vor zwanzig Jahren noch irgendwas ganz Neues zu lernen. Länger zu arbeiten wird wahrscheinlich für meinen Berufsstand gar nicht gehen, jedenfalls nicht mit den gleichen Aufgaben wie bisher.
Dieses sich-nicht-drauf-einlassen-WOLLEN ist das Riesenproblem! Für das Team, die Firma und auch die Gesellschaft im Allgemeinen.
Meine jüngeren Kollegen muss ich übrigens ausdrücklich loben. Sie sind sehr geduldig und die allermeiste Zeit respektvoll.
Ich finde Ihren Kommntar als Kontrast sehr gut! 👏👏👏 Ich 55) wurde als Senior auch mal in ein Embedded Projekt geholt, das völlig aus dem Ruder lief. Es war vollgestopft mit verschiedensten Technologien und hatte eine total verfilzte Architektur- wenn man überhaupt davon reden kann. Das Projekt bewegte sich schon seit knapp 2(!) Jahre kaum mehr von der Stelle und entsprechend wuchs der Druck auf die Teams. …die dann anfingen, sich gegenseitig die Schuld zuzuschieben. Sie waren, als ich anfing, komplett zerstritten- da lief keine vernünftige Kommunikation mehr. Meine erste Aufgabe als „Neutraler“ war, erst mal wieder vorsichtig die Kommunikationskanäle zu öffnen, Verständnis für jeden zu haben, aber auch dann für Verständnis für den Anderen zu werben. Das war extrem anstrengend und auch wenn ich es schaffte, dass die Leute wieder gemeinsam Planten und erfolgreich Sprints durchzogen, so habe ich das Unternehmen nach knapp einem Jahr wieder verlassen, weil ich meiner Leidenschaft- dem Planen und entwickeln von Code - nicht mehr nachgehen konnte. Der Pflegeaufwand der Teams war dauerhaft enorm. Wohlgemerkt war ich als Senior SW Entwickler eingestellt und nicht als Teamleiter. Und was mir auch auffällt bei den jungen SW Entwicklern - Der Hammer dieser Zeit heißt Python und jedes Problem wird mit ihm erschlagen. Ich bin Embedded Entwickler und es ist erschreckend, wie wenig technisches Wissen heutzutage über diese Chips herrscht! Gibt es kein „Framework“ für eine Aufgabe, dann wird rasch kommuniziert, dass der Chip nicht einsetzbar sei. Aber das ist ein anderes Thema…
@@hanspeterbestandig2054 Und das ist genau das Problem bei den jüngeren Kollegen. Sie rennen jedem Hype hinterher und nach ein paar Jahren hat man dann genau diese verfilzte Architektur. Wenn man dann als Älterer versucht diesen Wildwuchs etwas zu bremsen, gilt man schnell als rückständig und lernunwillig. Daß man in seiner Karriere bereits etliche dieser Schweinezyklen erlebt hat, wird nicht wahrgenommen. Und ehrlich gesagt, wirkliche Neuerungen gibt es in der IT sowieso kaum. Das was ich vor 30 Jahren an der Uni gelernt habe, sickert jetzt langsam in die Praxis ein.
Hey,
wie am Anfang gesagt, habe ich das Video 3 mal aufgenommen. Die fehlende Motivation bzw. das fehlende Interesse war im zweiten Video das Hauptargument (so wie Du es hier anführst), ich fand es dann aber beim schneiden des Videos zu arrogant und abwertend das so zu formulieren, deshalb habe ich mich auf "fehlende Zeit im Alter wegen anderer Interessen" geeinigt, das klang neutraler.
Gruß David
@@hanspeterbestandig2054 Danke für die Blumen ...🙂
Mein offizieller Job-Titel ist Firmware-Developer, aber mein Schicksal ist, dass ich mir vieles an "Sonderaufgaben" einfange. Von Code habe ich lange nichts mehr gesehen (abgesehen von dem von Produkten, die längst im Support sind). Das ist okay für mich, damit lebe ich ganz gut.
Zu jeder Zeit gab es einen "Hammer" und jedes Problem sah aus wie ein Nagel. Labview, Python, Perl, C, EXCEL mit VBA, Java, .... Eigentlich egal. Dass Probleme nicht mehr technisch gelöst werden, sondern "iterativ" ist auch ein Problem der "Prozesse". Ich vermisse es sehr, dass man sich zusammensetzt und gemeinsam ein technisches Gesamtlonzept ausarbeitet, einem Review unterwirft und freigibt BEVOR man anfängt zu programmieren. Ich habe den Eindruck, das passiert vielleicht im Kleinen (auf Feature Ebene) noch, aber nicht mehr für das ganze Produkt/Projekt.
Aber vielleicht bin ICH ja der Dinosaurier, der an den alten Kamellen festhält und nicht mehr flexibel genug ist für Kärtchen, DevOps, Sprints und Continuous Irgendwas?
Menno, über drei Minuten zugehört und ich weiß immer noch nicht, worum es eigentlich geht... "das Problem"
Ich glaube, dass wir unsere Jugend VIEL zu sehr idealisieren. Ich habe festgestellt: Wir hatten mit 20 keine Verantwortung. Wir hatten mit 20 keine Familie. Wir mussten uns nicht um tausend andere Sachen kümmern. Wir konnten uns einfach die Zeit nehmen, uns auf ein Thema zu konzentrieren. Mit zunehmendem Alter und zunehmender Verantwortung hat man diese Zeit nicht mehr.
Von daher sage ich allen: Einfach mal relaxed bleiben 😊😊
(edit: ich hätte mal das Video zu ende schauen sollen - lol :D)
Sehr gutes Thema! Zwei Dinge dazu:
Die älteren sind nachsichtiger, weil sie ja die junge Phase bereits erlebt haben, die Jungen aber nicht das Ältersein. Daher fällt es naturgemäß den jungen Leuten schwer, sich in ältere hineinzuversetzen. Zudem glaubt ein junger Mensch, das er NIE so wird.
Zweitens:
Ich bezweifle, dass jüngere per se "besser" sind. Sie lernen zwar schneller Technologien, doch müssen wir Älteren immer nachsichtig mit den Jungen sein, weil sie halt lange brauchen, um die Berufserfahrung zu bekommen, Technologien richtig einzusetzen. Will sagen, die Älteren nehmen auch ständig Rücksicht auf die Jungen/Azubis. Insofern beruht es auf Gegenseitigkeit.
Ich frage mich ob ich mit Anfang 40 noch zu jung bin oder zu starrsinnig das Problem bei mir zu sehen oder evtl ist embedded-Entwicklung weniger volatil.
Ich habe jedenfalls bisher das Gefühl dass ich vorallem dort langsamer bin, wo ich mit mit meiner wachsenden Erfahrung mehr Gedanken zu den Neuerungen mache. Leider ist nicht alles Neue auch immer besser.
Die ganz jungen Kollegen bringen tolle Ideen ein, die erfahrenere Kollegen mit ihrer langsameren Art auf Umsetzbarkeit prüfen können... bevor alles zuspät ist. Ich finde das eine tolle Kombination. Hoffentlich bleibt das so.
Im Embedded-Bereich sind die Technologiezyklen deutlich länger. Und der Desktop-Bereich könnte auch einiges von der Embedded-Entwicklung lernen. Zum Beispiel, dass man nicht auf jede neue Sau aufspringen muss, die gerade mal wieder durchs Dorf getrieben wird. Klar, die Anwender wollen neue Features und immer noch mehr Klickibunti. Aber man kann Algorithmik auch so implementieren, dass das, was man einmal vernünftig baut, für die nächsten 20, 30 Jahre tauglich ist. Setzt natürlich eine gewisse Weitsicht bei der Konzeption voraus.
@@danielrodding8522 Heutzutage gibt es schon extrem leistungsfähige und sparsame 32 bit Mikrocontroller im Embedded Bereich. Mich wundert es absolut nicht, wenn man die Aufgabenstellung mit so einem Mikrocontroller, Hochsprachen und vielleicht noch einem kleinen OS und Framework erschlagen will. Die Dinger haben teils mehr Leistung als so mancher alte 32 Bit x86 Prozessor und der wurde mal für den Desktop eingesetzt.
@@OpenGL4ever Naja, glücklicherweise muss man heute kein eigenes OS mehr bauen. Habe ich auch mal gemacht, in den seligen 1990ern. In der Anlage, die damals für Telekom die Prepaid-Telefonkarten "hergestellt" hat, lief mal ein ein Betriebssystem, was ich für die "Personalisierungseinheiten" gebaut habe. Hitachi RISC-Prozessor damals. Aber auch das was schon ganz weitgehend in C geschrieben, nur so 'n paar Dinge wie Context-Switching, Exception-Handling, Interrupt-Dispatcher etc. waren damals Assemblercode. In jüngeren Jahren gab es im Kleinstcompuerbereich tatsächlich eher so Dinge wie "Touch-GUI für Rasperry Pi Zero, und das in einem zentral orchestrierten Cluster" usw. Da hat man schon richtig Power zur Verfügung und kommt auf vernünftige Prozessierungszeiten - wenn man denn einigermaßen maschinennah programmiert.
In grösseren Firmen ist es häufig aber auch umgekehrt. Neue Technologie werden vermieden oder sogar abgelehnt. Unter anderem weil es tonnenweise "Legacy"-SW gibt. Da ist es dann sehr schwierig, neue Technologie einzuführen. In einem jungen Unternehmen, wo versucht wird, immer auf dem neuesten Trend zu surfen, haben es dann natürlich ältere Entwickler eher schwer. Bewährtes mit dem neuesten Schrei zu ersetzen ist vielleicht auch eine schlechte Angewohnheit der jungen Entwickler. Das alles ist viel zu anstrengend, sollte entspannter sein. Erfahrene Entwickler (finde ich ein besserer Begriff als ältere ) könnten jungen Entwicklern hier helfen entspannter zu sein und umgekehrt könnten die Jungen Technologie-Agent werden und die Freude an neuer Technologie am Leben erhalten.
Sehr interessant! Gerne auch ein solches Video, das die Probleme bei Anfängern (Alter egal) in der Softwareentwicklung beleuchtet!
Hey,
danke, freut mich das es Dir gefällt. Ja, wäre ein spannendes Thema aber das Problem ist, dass es (egal wie formuliert) sehr oberlehrerhaft rüberkommen würde und ich denke das es dann nicht so gut ankommen würde :)
Gruß David
8:39 was mich am meisten daran stört, ist der punkt, dass es eigentlich darum geht, dass wir probleme lösen.
es sollte nicht so eine große rolle spielen WIE das problem gelöst wird, sondern das es gelöst wird.
was an meiner arbeit am meisten unsinn ist, ist immer wieder neue technologien für seit jahren immer selbe probleme einzusetzen.
das ergibt keinen sinn. das ist verschwendete energie. ich weiß, ich rede wahrscheinlich wie ein 60 jähriger obwohl ich erst halb so alt bin.
aber das ist mein größtes problem an der softwareentwicklung.
ich bin doch für eine aufgabe eingestellt. sag mir was das problem ist und lass es mich dir einfach abnehmen und lösen.
aber nein, einem wird genau gesagt wie es gemacht werden soll, mit welcher sprache und wie der programmablauf sein soll.
das behindert mich aber extrem weil ich dafür dann deutlich länger brauche.
es finden mehr meetings statt, längere meetings, viele diskussionen.
und wenn ich es dann bei einzelnen projekten selber bestimmen oder entscheiden kann, geht es viel schneller, günstiger und einfacher.
ich finde die aller meisten frameworks und CMS systeme und technologien relativ nutzlos.
darum begrüße ich auch sehr den mind-change der so ein bisschen umgeht im hinblick zu vanilla-coding. das wurde auch im letzten video von "the native web" angesprochen.
Wenn man sich das Thema etwas anders betrachte kommt man auf den Punkt: Manche Menschen lernen langsammer und manche schneller :-) unabhängig vom Alter. Es gibt Kollegen die jung sind aber im Kopf alt und gleichzeitig gibt es Kollegen die sehr alt sind von Jahren aber im Kopf noch ein junger Hüpfer. Außerdem kann ein Entwickler der "Alt" ist auf eine Erfahrung zurückgreifen die Gold wert ist: Der Junge steht vor einer neuen Projektsituation und ist aufgeregt und der "Alte" grinst nur und sagt "das ist jetzt das dritte mal das ich das erlebe". Außerdem neue Technoloiien sind meistens nur "Kopien" von alten :-) Die Konzepte bleiben gleich, nur die Farbe ist anders :-) Aber ja auch ich habe erlebt das Alten gegenüber sehr unfair agiert worden ist (auch mit internen Sprüchen usw).
Hey,
das mit dem schneller langsamer lernen hab ich ja auch angesprochen, sehe ich genau so wie Du. Was das mit dem "Kopien von alten" angeht, stimme ich dir nicht ganz zu. Je nachdem von welcher Technologie auf welche gewechselt wird, ist das etwas mehr (z.b. Desktop auf Web).
Gruß David
@@DavidTielke Aber Http gibt es schon seit 1997 und tcp/ip seit den 80ern. Also wer das Prinzip von Sockets versteht, versteht z.B. auch sofort WebSockets. Lisp gibt es seit den 60ern wer das beherrscht, lernt z.B. Clojure innerhalb weniger Stunden oder versteht sofort die Prinzipien funktionaler Programmierung, die jetzt wieder Hype sind und elementarer Bestandteil für Frameworks wie z.B. Redux sind. Vim gibt es seit Anfang der 90er, wer das beherrscht, lernt NeoVim in Minuten und ist Produktiver als jeder INtelliJ, Visual Studio oder Eclipse Guru
I.d.R macht sich mit 40 oder 50 noch kein kognitiver Verfall bemerkbar. Falls doch sollte man schnellstens einen Neurologen aufsuchen
Genau. Alter Wein in neuen Schläuchen, und alle paar Jahre wird eine neue Sau durchs Dorf getrieben. Allerdings sind die Arbeitsmethoden in der kaufmännischen Verwaltung oft viel komplexer als nötig. Ich erlebe als kaufmännischer Berater sehr oft, dass Softwaremigrationen unvollständig bis falsch umgesetzt wurden, und sich Unternehmen damit teilweise über zehn Jahre und darüber hinaus rumschlagen müssen. Aber nach ein paar Jahren, wenn die Alten weg sind, kennen es die jungen Sachbearbeiterinnen nicht mehr anders, und können nie zwischen Soll- und Istzustand unterscheiden. Denen kann man unmöglich mehr beibringen, wie es eigentlich hätte sein müssen, wenn es richtig customized worden wäre.
Ich denke, und dieser Prozess hat bei mir zum Glück relativ früh eingesetzt, dass man ein guter Entwickler sein kann, ohne alle Tools, alle Frameworks und Programmiersprachen zu können. Und ich gehe bei jedem Gespräch, dass ich beruflich in diesem Zusammenhang führe, ganz offen damit um, welche Fähigkeiten ich besitze und was ich halt noch nicht gemacht habe. Was ich bei einem Job benötige, eigne ich mir an.
Zudem ist es heutzutage vielleicht auch nur wichtig zu wissen, was alles möglich ist.
Danke für das erhellende Video.
Eigentlich ist es egal, um welche Branche es sich handelt. Das Problem ist überall ähnlich. Ich bin 60 Jahre alt und blicke auf über 40 Jahre Arbeitsleben zurück, in den Generationen der ab ca. 1950 Geborenen haben so viele Veränderungen jeglicher Art stattgefunden wie nie zuvor in einem Arbeitsleben.
Zuvor konnte man tatsächlich mit einer Ausbildung seinen Lebensunterhalt lebenslang mehr oder weniger problemlos bestreiten. Auch wurde uns das vor so langer Zeit von den Ausbildnern so gelehrt. Die wussten ja auch nicht, welche gewaltigen Fortschritte und unvorstellbaren Herausforderungen in der damaligen Zukunft und heutigen Gegenwart zu erwarten waren.
Ich kannte von früher noch viele Leute, die von der Ausbildung bis zur Pension im selben Betrieb gearbeitet hatte. Nicht dass dies nur positiv war. Aber wenn jemand das wollte, so konnte er ein solch konstanter Leben verwirklichen. Sowas ist heute undenkbar.
Heute kann ich sagen, dass es über die Jahre einfach erschöpfend ist, soviel Wissenszyklen durchzumachen. Darum landen heute viele (nicht nur Alte) im Burnout oder schlimmerem, weil es für viele irgendwann nicht mehr zu stemmen ist, was alles verlangt wird. Der Mensch ist heute zum betrieblichen Verbrauchsmaterial geworden. Das spiegelt sich schon im heute verwendeten Begriff "Human Resources", der den Begriff Personaldienste abgelöst hat. Resources sind doch Verbrauchsmaterialien?
Etwas gegenseitiges Verständnis - ja gegenseitiges - könnte helfen, unsere ungewöhnliche Zeit im Arbeitsleben würdig zu überstehen. Wir Alten können uns Erinnern an die Jugend, aber es gibt für die Jungen keine Möglichkeit, sich an eine Zukunft zu erinnern. Hier gibt es bestenfalls die vage, mehr oder weniger phantasievolle Vorstellung wie es sein könnte. Darum ergibt sich hiermit vielleicht der wünschenswerten Ansatz, dass jeder den Anderen so behandelt, wie er selbst behandelt werden möchte.
Mit zunehmendem Alter merkt man allerdings auch, dass man nicht jedem Hype hinterherlaufen muss. Viele Dinge lassen sich nämlich auch sehr schnell "mit bewährten Mitteln" erledigen. Das sehe ich in meiner Firma oft genug. Wenn ich sehe, welchen Aufwand es erfordert, diverse neue Programmiersprachen oder Frameworks in unsere Testumgebungen zu integrieren, weil irgendwer mal wieder ne neue Sau durchs Dorf getrieben hat, dann könnte man sich einiges von dem Aufwand sparen. Vor allem haben "gut abgehangene" Lösungen auch den Vorteil, dass viele Funktionen/Integrationen schon vorhanden sind, die der neueste Shit noch gar nicht hat.
Erinnert mich an die Zeit um die Jahrtausendwende, wo Java frisch war und quasi täglich irgendeine Jubelmeldung über die neuesten Features auf Heise rausgehauen wurde. Einerseits von Beginn an als Allheilmittel für alles angepriesen, wurde man damals irgendwann müde, wenn man ständig neue Meldungen der Art "Java kann jetzt 2+2 unfallfrei addieren" gelesen hat. Okay, ich will jetzt nicht ins Java-Bashing einsteigen, mittlerweile ist der Kram ja durchaus tauglich. Aber das war so ein Paradebeispiel dafür, dass man nicht immer sofort auf jeden neuen Zug aufspringen sollte.
@@danielrodding8522 also ich kenne Java jetzt schon seit 1.3 und habe mich immer darüber gewundert, was Leute erzählten, was angeblich nicht ginge.. und abgesehen von Hardwarenaher Programmierung habe ich schon damals nicht viel vermisst.
Aber das ist alles viel schnellebiger geworden: In der Webwelt wird gefühlt alle drei Tage ein neues Framework durchs Dorf getrieben und jedes behauptet von sich leichtgewichtiger zu sein, aber mit jedem Feature wird es größer und am Ende ist der Unterschied der gut abgehangenen Frameworks nicht mehr wesentlich, ob du nun ExtJS, Angular, React, etc. nimmst.. in den Regionen landet alles, was mir lange genug einen Hype generieren kann. Und mit den Sprachen ist es oft ähnlich.. sie fangen alle klein und fokussiert an, behaupten, sie wären einfacher, dann kommt hier ne heute Syntax dazu, da ein neues Paket und an Ende steht da wieder ein riesen Ökosystem, das das Rad zum 29.male neu erfunden hat.
@@brixomatic Naja, meine ersten Berührungspunkte mit Java hatte ich aus reiner Anwendersicht, und das war ein seinerzeit sehr progressiver Online-Broker, der kurz vor der Jahrtausendwende ein Brokerage-Applet auf seiner Website angeboten hat. Und das sollte nach der damals scheppernd lauten Trommelei für die Portabilität von dieser Technologie ja auf jedem Rechner und in allen Browsern laufen. Ergebnis war, dass man sich aussuchen konnte, welche Bugs man haben wollte: mal waren die Beschriftungen der Buttons zu klein oder zu groß, mal konnte man nix klicken, mal kam einfach nur ein leeres Fenster, und manchmal funktonierte es tatsächlich. Bis man genötigt wurde, irgendwelche Java-Upates einzuspielen, damit es dann auch immer noch am seidenenen Faden hängend so halbwegs lief. Und die Werbung für diesen ganzen Mist (also auch für das angeblich hochportable Java und das Applet-Konzept) lief natürlich weiter... Selbstredend war das alles noch dazu noch lahm und ressourcenfressend.
Nee, ich ich komme aus der C-Welt, habe später auf C++ umgesattelt, wobei ich C++ im wesentlichen im Stile "Klassenumverpackung für C" benutze. Da weiß ich wenigstens, was ich habe, und bekomme auch definierte Performance und effiziente Speichernutzung.
Und was diese ganzen Web-Frameworks angeht: da nervt es einfach nur noch. Selbst ursprünglich mal recht kleine Pakete wie "Bootstrap" sind ja mehrfach grundlegend umgeschmissen worden, selbstverständlich ohne Rückwärtskompatibilität. Das nervt einfach nur noch, weil man dann teils halbe Softwareprojekte umschreiben darf, nur um irgendwelche Updates durchführen zu können, die man wiederum machen muss, weil aufgrund irgendeiner externen Dependency erforderlich. Als Softwaredienstleister lässt es sich den Kunden auch nicht erklären, warum man plötzlich paar tausend Euro berechnen muss, obwohl zum Kunden hin überhaupt kein messbarer Mehrwert entsteht.
Hier ist daher der Ansatz tatsächlich gewesen, möglichst viel auf Basis eines eigenen Frameworks mit möglichst wenig externen Dependencies zu entwickeln. Ja, zugegeben, noch ein Framework mehr. Aber da habe ich quasi mein eigenes Ökosystem, und da ist für die in jüngeren Jahren bearbeiteten Projekte alles in schlanker Form drin, was eben so gebraucht wird. Ist halt für Freelancer, die hier mitarbeiten, teils zu Beginn erst ein Kulturschock, weil eben völlig abseits der üblichen Hypes. Aber wenn die einmal tief geschluckt und sich da ein wenig reingefunden haben, sind sie durchaus glücklich damit. Und die Software, die hier an die Kunden rausgeht bzw. rausgegangen ist, läuft teilweise seit mehr als 20 Jahren, ohne dass größere Eingriffe in Bestands-Codestrecken erforderlich gewesen wären.
Auch Web-Projekte aus jüngeren Jahren sind backendseitig auf eigener Codebasis ohne externe Dependencies realisiert. Da nehme ich direkt ab HTTP-Listener die Requests mit eigenen Codestrecken ab, prozessiere Templates über kleine eigene Skriptsprache (im wesentlichen vergleichbar mit dem, was Apache Tomcat auch macht), für den typischen Anwendungsfall "kleine Datenmangen in DB, viel lesen und wenig schreiben" gibt es eine kleine eigene DB-Engine (die allerdings bedarfsweise mit anderen DB-Engines zwecks Synchronisation gekoppelt werden kann), und so weiter... Zugegeben, ist nicht der Standardweg, wie man arbeitet. Aber die Projekte hier sind auch nicht gerade der typische Standardkram. Viel Inhouse-Anwendungen, teils auch so komische Dinge wie "Kunde will Cluster mit 3000 Einheiten mit GUI in near-realtime bespaßen", oder "es kommen 10 Mio. Datensatzlieferungen pro Tag per HTTP rein, und die sollen auf 1 CPU prozessiert werden", und so weiter. Da hat man einfach keine Lust, seine Zeit mit irgendwelchen fremden Monster-Frameworks zu verschwenden, sondern baut sich seine Infrastruktur eben lieber selbst. Und aus Performancegründen ist übrigens diese C/C++-Welt, bzw. eben "C in C++-Klassenumverpackung", der präferierte Ansatz. Damit bekommt man kleine und performante Anwendungen gebaut. In der Open-Source-Community scheinen "klein" und "performant" inzwischen Fremdworte zu sein...
Interessanter Beitrag. Eine Anregung von mir für ältere SW Entwickler: versucht nicht unbedingt mitzuhalten sondern bringt besser Eure Erfahrungen im Umgang mit Problemstellungen ein. Also nicht kodieren, sondern entwickeln, vordenken, Fallbeschreibungen, Analyse der Aufgabe usw, denn da seit Ihr älteren Entwickler den jüngeren Kollegen meilenweit voraus. Mit anderen Worten: flexibel bleiben und andere Aufgaben suchen und in Angriff nehmen, die Erfahrungen werden gebraucht.
Sehr schöner Beitrag, im Grunde bringst Du es auf den Punkt. Ein Aspekt allerdings, der mir bereits öfters im Umgang mit älteren Kollegen begegnet ist, bleibt ein wenig auf der Strecke. Ich bin wie Du seit über 20 Jahren in der Softwareentwicklung tätig und mittlerweile gehöre ich auch nicht mehr zur jungen Generation der Entwickler. Ein Problem, das mir oft bei der Zusammenarbeit von älteren und jüngeren Entwicklern aufgefallen ist. Die älteren haben oft eine "ich bin älter und weiß es daher besser" Attitüde. Dazu kommt bei vielen noch eine, wie ich meine, Scham, gegenüber einem jungen Kollegen zuzugeben, dass man etwas nicht kann oder nicht verstanden hat. In der Informatik allgemein hat man es oft mit sehr konservativen Menschen zu tun, die oft glauben, ihre vor Jahren erlernte Lösung für ein Problem sei die universell beste. Ich sage zu den Jungen in meinen Teams immer "hört auf die alten" und zu den alten sage ich immer "hört den Jungen sehr genau zu, oft haben diese interessante Ansätze welche vieles Effizienter machen".
Jüngere haben derzeit vor allem Teilzeit, Home Office und WorkLifeBalance im Kopf. Wenns eng wird springen halt derzeit meist die Älteren ein.
Wenn Entwickler nicht gut im Alter sind, waren sie meist auch in jüngeren Jahren nicht gut.
Glaubt man WIRKLICH, dass das so ist? Ich bin damit sehr vorsichtig, den Leuten diesen Stempel aufzudrücken.
Sind es doch eher die Medien, die Illustrierten, die Magazine, die Reportagen im TV, die uns diesen Eindruck wohl eher vermitteln 'wollen'.
Da 'Bild' des Freelancers oder des Home-Office-Kollegen, der seine Arbeit vom Strand aus macht oder entspannt dabei im Park sitzt, kommt da sehr gelegen, um uns zu suggerieren, die halbe Welt wäre so.
Interessant. Da ich aus einer Schreinerfamilie komme, aber den Weg des ITlers eingeschlagen habe.
Die Erfahrungen aus dem Schreinerbetrieb kann ich nicht teilen. Eher waren es die Älteren, die durch Messebesuche Luft geschnuppert haben und Automatisierung vorran getrieben haben. Die alten Herren konnten sehr gut einschätzen, ob sich eine Anschaffung lohnt. Jüngere hatten mit den "neuen Technologien" eher Probleme, weil sie sich die Grundlagen nicht aneignen wollten. Kostenloses WiFi im Betrieb war für die wichtiger. Auch wollten die lieber auf Montage und Überstunden kloppen, anstatt in der Bude CNC-Maschinen einzurichten, wobei sich nicht nur in diesem Bereich extrem viel getan hat.
In der IT mache ich die Erfahrung (auch in Konzernen mit >400k MA), dass Jung & Alt meist auf dem Hype-Train mitfahren wollen. Schnell wird mal etwas eingeführt, ohne die Konsequenzen abschätzen zu können. Hauptsache auf der Powerpoint-Folie sieht das gut aus.
Projektmanager brauchen heute meist gar kein Fachwissen in der IT, sondern einfach nur einen Scrum-Schein im Koffer haben. Diese "studierten" Menschen können meist nicht abstrakt denken und rollen jede Lösung von Null auf, ohne auf bewährte Lösungen zu setzen bzw. an Schnittstellen in Umsysteme zu denken. Denen erzählt irgendein externer Berater, dass irgendwas einfach nicht geht. Auf solche Leute hört das Management. Diese ziehen nach 2.5 Jahren weiter und selber darf man dann noch retten, was noch geht bzw. das ganze am Laufen halten. Unterschriften von externen Beratern sind quasi der Freifahrtsschein für Murks.
Ich lebe gut davon. Damit man mich halten kann, verlange ich 120% Bezahlung bei 60% Arbeit. Mir wäre es aber lieber, wenn man nicht erst zu mir kommt, wenn das Kind in den Brunnen gefallen ist oder das Management es wichtiger findet, dass jeder mehrere 2SLGBTQ+-Kurse besucht hat. Letzteres scheint heutzutage, vor allen anderen Themen, das allerwichtigste in grösseren Unternehmen zu sein.
Vielen Dank, lieber David! Ein wichtiges Thema. Ich bin DEV und zähle 56 Lenze und fühle mich nach wie vor am wohlsten in der Desktop-Programmierung. Mittlerweile habe ich 8 Sprachen im Inventar, wovon ich die meisten jedoch nicht wirklich im Arbeitsalltag nutze, sondern immer mal wieder das eine oder andere Projekt privat programmiere, um das Gelernte nicht verloren gehen zu lassen. Ich kann aus eigener Erfahrung sagen, dass das Lernen von "neuen Sprachen" leichter und schneller von der Hand geht als früher. Wobei ich aber einräumen muss, dass ich früher NIEMALS eine Sprache in wenigen Wochen oder gar an einem Wochenende "gelernt" hätte - ich war da deutlich begriffstutziger als intelligente Personen wie Du und andere. Wovon ich heute zehre, ist der Umstand, dass sooo unterschiedlich die Sprachen gar nicht sind, und man sich bei Sprachuniversalien in jeder Sprache relativ einfach zurechtfinden kann (schwierig wirds dann bei nativen Funktionen oder speziellen Bibliotheken, aber auch Frameworks mit speziellen Features). Meist kann man mit der Lektüre (und Praxistraining) von schmalen Tutorials (Goalkicker oder Tutorialspoint) relativ schnell eine Grundlage erarbeiten (auf diese Weise habe ich schnell in TypeScript, Powershell und Groovy hinein gefunden). Und je älter ich werde, desto mehr macht mir das Hinzulernen Spaß. Das würde aber sicherlich anders aussehen, wenn ich als Freelancer oder Selbständiger arbeiten müsste - mit all dem Anforderungsdruck und dem Konkurrenzkampf. Denn in dieser einen Hinsicht kann ich Dir voll und ganz zustimmen: es fällt im Alter deutlich schwerer, sich an neue Gegebenheiten anzupassen - und sei es nur an ein neues personelles Umfeld.
Programmiersprachen sind höchst unterschiedlich, nur die meisten Mainstream-Sprachen orientieren sich immer wieder an altbekanntem, meistens C.
@@amigalemming Einen großen Unterschied sehe ich nur zwischen imperativ und funktional. Ansonsten ist es eigentlich nur Syntax. Ich beziehe mich jetzt natürlich auf Sprachen die überhaupt sinnvoll verwendet werden können und nicht auf Spaß-Programmiersprachen, die praktisch unlesbar sind.
@@jayeff6712 Es gibt noch einige Sprachparadigmen mehr, die sinnvoll eingesetzt werden können. Constraint-Programmierung einschließlich logische Programmierung zum Beispiel.
@@amigalemming Ja, aber damit gehen wir jetzt noch weiter von den Sprachen weg und mehr in Richtung der zu lösenden Probleme. Mir würde jetzt keine ernstzunehmende Programmiersprache einfallen, die alles ganz anders macht als C und wo ich das Gefühl haben würde nochmal ganz von vorne anfangen zu müssen.
Hm so schlimm find ich neue Frameworks usw. nicht, ich finde das abstrakte Denken und Problemlösung ist die wichtigste Fähigkeit.
Wenn Du mit der Abstraktionsebene und der Algorithmik kein Problem hast, aber gefühlt jede Woche irgendein anderes "Framework" oder "Tool" lernen sollst, dann nervt es einfach nur noch. Immer wieder mit irgendeiner neuen, konfusen Syntax rumschlagen, neue Arten unleserlicher Fehlermeldungen dechiffrieren müssen usw. Und das mit dem Gefühl dabei, dass einen das bezogen auf das eigentlich zu lösende Problem rein gar nicht weiterbringt. Da sind die Jüngeren tatsächlich motivierter. Dafür produzieren die häufiger Spaghetticode und denken bezogen auf das zu lösende Problem nicht geradlinig genug...
Deswegen interessieren mich Ideen und Konzepte. Die sind relativ zeitlos und lassen sich ja auf die verschiedensten Programmiersprachen und Frameworks anwenden. Und viele Dinge wiederholen sich ja. Programmiersprache XY hat jetzt Feature Z, und das Feature landet in "deiner" Programmiersprache. Oder Programmiersprache XY hat ein Feature das keine andere Programmiersprache hat, dann wird das ganze drumherum nachgezogen von anderen Programmiersprachen. Aber es gibt durchaus größere "disruptivere" Änderungen. Man denke da gerade an KI. Da haben die jüngeren tatsächlich einen Vorteil, weil sie damit groß werden. Ich denke da ist für "Senioren" eher "Architektur" ihre Nische. Dafür muss man aber gut genug abstrahieren können.
Hey,
da hast Du recht, bei Programmiersprachen ist das meist noch etwas einfacher, bei dem kompletten erlernen von neuen Technologien und Plattformen aber nicht.
Gruß David
Jo, so geht es mir genauso. Deswegen ziehen mich auch SW-Architekturen, mathematische Modelle und Konzepte jeglicher Art magisch an, die kann man auf jede erdenklich Sprache anwenden, oft sogar auch auf eine funktionale Programmiersprache. Momentan beschäftige ich mich z.B. mit Bildbearbeitung. Klar mit C# zusammen mit WPF und .MAUI gibt es jeweils starke Bibliotheken, mit denen man Manipulationen an Bildern performant und einfach umsetzen kann, doch mich interessieren eher die abstrakten mathematische Modelle, die dahinter stecken.
Zum Thema kann ich den Artikel "Langsam, aber sicher: Gehirnforschung über das Lernen Erwachsener" von Manfred Spitzer empfehlen. Ich zitiere: "Ältere Menschen lernen zwar langsamer als junge, dafür haben sie jedoch bereits sehr viel gelernt und können dieses Wissen dazu einsetzen, neues Wissen besser zu integrieren. Je mehr man schon weiß, desto besser kann man neue Inhalte mit bereits vorhandenem Wissen in Verbindung bringen. Da Lernen zu einem nicht geringen Teil im Schaffen solcher internen Verbindungen besteht, haben ältere Menschen beim Lernen sogar einen Vorteil! Wissen kann helfen, neues Wissen zu strukturieren, einzuordnen und zu verankern!
Letztlich ist es wie bei einem ANN: alles beginnt mit einer niedrigen Lernrate, die mit der Zeit immer mehr abnimmt. ;)
Mit Interesse habe ich (61) dieses Video geschaut. Aus meiner Sicht kann ich die Aussagen gut bestätigen. Subjektiv sehe ich bei Älteren
a) Projekterfahrung +++
b) Sprachen, Frameworks, IDE - -
c) Gelassenheit ++
d) Geschwindigkeit --
e) theoretisches Basiswissen (Informatik): ungefähr gleich
Ein fähiger Teamleiter wird jedoch die Unterschiede zu seinem Vorteil nutzen können. Ich war letztes Jahr für einen problematischen Kunden tätig. Durch a) und c) war ich in der Lage, gute Überzeugungsarbeit zu leisten, fundierte Grundlagen zusammenzustellen, viel aus Erfahrung zu reden, usw.. In Zusammenarbeit mit jüngeren Kollegen für b) und d) kam ein fabelhaftes Ergebnis zustande. Deshalb die Empfehlung an Teamleiter: bildet eure Teams mit einem gesunden Mix aus Jüngeren und Älteren.
@David zur Beruhigung: im Alter 50 und auch 60 steigt a) und b,c) nehmen möglicherweise ab. Aber gefühlt hebt das eine das andere auf. Ich fühl mich genauso fit wie früher, nur eben anders. :)
Man kann als älterer, erfahrener Entwickler aber auch Sachen schneller verstehen, da die meisten Sachen halt nicht völlig neue Konzepte oft bringen, sondern oft altes in neuen Tüchern. Außerdem lernen jüngeren oftmals nur recht oberflächlich, ohne die Hintergründe zu kennen, damit sie schnell damit arbeiten können. Wenn ein älterer mal eine Woche länger braucht um etwas zu verinnerlichen, sehe ich da kein großes Problem, denn oft wird es dann auch besser verstanden. Aber gut, ich kenne jetzt auch nicht so viele wie Du wahrscheinlich ;) Letztlich ist Erfahrung schon sehr viel wert, da Sachen vorweggenommen werden können (aus Erfahrung), die die Jüngeren erst noch selbst austesten müssen. Man sollte versuchen die Stärken von beiden zu nutzen und die Schwächen so auszugleichen.
Nur kleine Randnotiz zum Thema Bezahlung "jung vs. alt": Als ich mich vor 20+ Jahren selbständig gemacht hatte, waren meine monatlichen Belastungen deutlichst geringer als sie es heute sind. Damit meine ich nicht nur die derzeitigen Preiserhöhungen (und Mitnahmeeffekte... 🙃), sondern die kontinuierliche Steigerung der monatlichen Fixkosten über die gesamte Zeit, bzgl. Renten/Krankenkasse/Versicherungen, Wohnen, Familie und Verbindlichkeiten aller Art. Daher muss ich, je älter ich werde, notgedrungen auch immer mehr Geld einnehmen, um annähernd auf Stand zu bleiben. Beispiel Krankenkasse: Ich hatte ganz am Anfang mal 220,-/Monat bezahlt -- mittlerweile rund 700,- -- muss also jährlich rund 6.000,- Euro *mehr* umsetzen, allein für diesen einen Posten. Ich nehme an, dass andere eine ähnliche Progression erfahren. Das sollte man auch im Hinterkopf haben, wenn man die ungleiche Bezahlung von Jung und Alt betrachtet.
Definitiv ein reales Problem. Es gibt noch einen Aspekt, den du dabei außer Acht gelassen hast meiner Meinung nach. Ich habe zum Beispiel oft erlebt, dass diese älteren Kollegen ihr eigenes Problem gar nicht sehen wollten. Ob es jetzt aus Trotz ist oder sie sich über die Jahre nicht damit anfreunden konnten, dass sie eben älter werden und die Technologie immer jünger... wer weiß. Große Reibungspunkte entstehen oft dann, wenn ältere Kollegen von ihrem hohen Ross der Betreibszugehörigkeit herunter sprechen zu jüngeren Kollegen. Auch das sorgt oft für Reibungen, weil sich natürlich jüngere Kollegen dabei verschaukelt vorkommen. Es ist manchmal auch einfach ein Problem, das von zwei Richtungen aus kommen kann.
Hey,
vielen Dank! Im Video ging es ja primär um den in meinen Augen unfairen Umgang von jung gegen alt. Was solche Eigenarten im Alter angeht, da könnte man ein ganzes Video zu machen, genau wie über die jüngeren Kollegen :)
Gruß David
@@Ric-yl6eg Du kannst es jetzt gerne unter jeden Kommentar schreiben, der nicht Deiner Meinung entspricht, aber Dein Hauptkommentar zeigt Deine Einstellung eigentlich schon :)
Gruß David
Schönes Video David und gut angesprochen. Wichtig ist es aber grundlegend untereinander immer einen respektvollen Umgang zu pflegen. Auch in einer Crunch-Time.
Hey,
sehr gerne, vielen Dank!
Gruß David
In der IT entwickelt sich relativ wenig weiter. Wir knabbern heute noch an Technologieentscheidung, die vor Jahrzehnten gefällt wurden. Wirklich innovative Entwicklungen jedoch bleiben unbeachtet links liegen, weil die Leute keine Sprünge mögen, sondern immer nur kleine Schritte vom Bekannten weg.
Welche innovative Entwicklungen würdest du denn vorschlagen?
@@OpenGL4ever Formale Verifikation und maschinelle Beweise beispielsweise. Werden bislang ja nur in Nischen eingesetzt, in der Prozessorentwicklung etwa, aber der Großteil der Softwareentwicklung bleibt davon völlig unberührt. Fehler und Sicherheitslücken gelten nurmehr als lästiges Ärgernis, das man leider nicht verhindern könne.
@@amigalemming Hat man das nicht bei Ada95 versucht irgendwie unterzubringen und benutzt man das nicht in der Luftfahrtbranche?
@@OpenGL4ever Die Luftfahrt hat vor inzwischen Jahrzehnten beschlossen, von Ada auf C umzusteigen, weil es ja für C mehr Programmierwerkzeuge gibt. Man nimmt sich halt vor, die gefährlichen Dinge in C zu unterlassen. Siehe beispielsweise MISRA-C.
@@amigalemming Danke für den Hinweis zu MISRA-C. Ich bin jetzt aber nicht der Meinung, dass da gar nichts passieren würde, denn es gibt inzwischen auch Rust das zunehmend anstatt C verwendet wird und das ist schon deutlich sicherer.
Die MISRA-C Regeln sind natürlich schon sinnvoll und man könnte sie sicherlich für einen viel größeren Teil der Projekte einsetzen. Dennoch gibt es auch Ausnahmen, z.B. kann MISRA-C auch Leistung kosten. Wenn ich mir mal so ein paar Beispiele in der WP ansehe, dann bspw. dieses hier:
if (b!=0) a/=b;
um eine Division durch Null zu verhindern. Das ist in den meisten Fällen durchaus sinnvoll, aber es gibt auch sicher Fälle, wo b niemals 0 wird und dann kostet so ein Code wie oben Leistung, insbesondere wenn er durch eine Schleife mehrmals durchläuft. Hier kommt es also auch auf die Vorbedingung an. Klar, hier wäre dann ein mathematischer Beweis, dass b niemals 0 werden kann sinnvoll.
Bei den Doppelslash // Kommentaren frage ich mich aber, warum die in MISRA-C nicht erlaubt sind?
Aus meiner Sicht sind die // viel sicherer als die Kommentarblöcke mit dem Slash und Sternoperator. Denn das Kommentar endet bei denen praktisch immer am Zeilenende und es geht definitiv nicht darüber hinaus.
Nach der Ausbildung kennt ein Entwickler vielleicht eine Umgebung und gewisses Handwerkszeug, ihm ist auch bewusst, dass er danach nicht einfach "fertig" ist, sondern auf einer endlosen Reise der Weiterentwicklung, neues ausprobieren und das Erlernte weiter verbessern. Während dem Weg begegnet man diversen Frameworks/Technologien, Wechsel finden statt und ein Anwachs an Erfahrungen.
Als älterer Entwickler kennt man natürlicherweise mehr Technologien als die jüngeren, und kann dadurch den Wirkungsgrad zwischen den Technologien besser vergleichen. Der ältere erkennt genau, ob ein Framework zur gegebenen Zielsetzung passt, einem mehr Möglichkeiten gibt, oder einen darin einschränkt. Wenn dann etwas "neues" vordiktiert wird, nur weil es neuer ist (und nicht besser), entsteht dadurch eine Lernblockade. Manches wird einem unter der Illusion verkauft, damit produktiver zu sein, was Paradox ist, da es länger dauert, weil man das Ding noch nicht gelernt hat, oder stößt auf Hindernisse weil das neue noch nicht ganz ausgereift ist. Aber hey es ist 2024, da macht man das nicht mehr.
Es lässt sich herauslesen, dass ich zu den älteren gehöre, bin stets offen für Fortschritt, das Erlernen klappt noch sehr gut, sofern ein Mehrwert im zu Erlernenden erkennbar ist.
Zum Umgang mit jüngeren, es ist keine Schande zuzugeben, dass man selbst nicht perfekt ist, und dass sich alle auf dem Pfad ewigen Lernens befinden.
Hey ich find das echt n wichtiges Thema und ich find du trittst niemanden auf den Schlips mit deiner Formulierung.
Ich glaube es ist auch echt n Unterschied in welcher Domäne und in welchem Bereich man genau arbeitet.
Momentan arbeite ich in der Desktopentwicklung mit Fullstack Java, vorher Web mit LAMP Stack.
Ich merk wirklich, dass der Desktopbereich irgendwie entscheunigter als der Web Bereich ist, zumindest was Office Software angeht.
Und grad wenn man (so wie ich) ausschließlich mit älteren Kollegen arbeitet, dann ist es eher andersherum.
Dann haben eher junge Leute Schwierigkeiten die "neuen" (alten) Sachen zu lernen.
Gelundenes Video mal wieder ! :)
Danke für dein Video, das ist definitiv ein Thema für das sich eine Sensibilisierung lohnt.
Ich bin froh, dass die Zusammenarbeit zwischen älteren und jüngeren Softwareentwicklern (zu denen ich mich noch zähle) in meiner aktuellen Firma gut klappen. Das Problem bei uns ist eher der Grad der Seniorität (gemessen am Job-Level in der Firma, nicht an den wirklichen Jahren oder allgemein an diverser Projekterfahrung) und dass es da Leute gibt, die aufgrund ihres höheren Levels gern einfach ihre Ansichten durchdrücken möchten. Das klappt weil viele weniger seniorigere Kollegen/Kolleginnen da rein aus Respekt vor dem höheren Level nichts sagen und Dinge unreflektiert akzeptieren. Auch hier betrifft es natürlich nur ein paar Leute und nicht alle, aber es fällt auf und zerstört zu einem gewissen Grad auch die Motivation sich im Projekt einzubringen.
Sehr gerne :)
Gruß David
Ich habe einen anderen Aspekt von Schnelligkeit. Ich habe ziemlich viele Menschensprachen gelernt, 13, wenn ich mich nicht verzählt habe. Aber... etwa die Hälfte habe ich zu 99,5% vergessen. Warum? Weil ich sie zu schnell gelernt habe. Etwas theoretisch zu wissen und ein Wissen fest verankert zu haben, sind zwei total verschiedene Dinge. Italienisch habe ich in etwa 6 Wochen gelernt, dann kam ein Schulaustausch, total immersion zwangsläufig, und was ich gelernt habe ist fast alles noch da. Spanisch: In einem Monat gelernt, in einem Monat vergessen. Ukrainisch: in drei Wochen gelernt, in zwei vergessen.
Mit Computersprachen geht es mir ähnlich: Swift und Kotlin: Zwei bis drei Wochen durch den Kurs gedüst. Die Struktur habe ich noch im Kopf, die ist ja bei vielen Sprachen ähnlich. Aber - ich weiß: wenn ich nicht nur wissen will, was das Besondere an einer Sprache ist, sondern damit arbeiten will, dann muss ich eben langsamer arbeiten. Wenn sich in irgendwelchen yt-Kommentaren hauptberufliche Frontend-Entwickler unterhalten, dass sie beim Thema einmitten immer noch googeln, steh ich alter Laie daneben und wundere mich, dass sie scheint's nichtmal diese basics können. Ich denke, dann lieber langsam und so gründlich, dass im Kopf auch was hängen bleibt. Ist im Moment langsam, aber über die Jahre schneller.
Das Thumbnail ist furchtbar... aber deswegen bin ich wohl hier 🙂. Unbenommen davon ein super Thema und Video, und mir gefällt, wie Du das ansprichst.
Ich lerne seit 30 Jahren immer wieder neue Technologien und habe kein Problem damit. Erst kürzlich kamen die Frameworks für die Mobilen dazu. Da ich selbständig bin, musste ich immer Neues lernen, egal ob in der Programmierung oder in anderen Bereichen meines Portfolios.
Allerdings arbeite ich z.Zt. auch nur in einem kleinen Team, alle auf der Welt verteilt, und bin kein klassischer Entwickler mit Studium wie meine internationalen Kollegen. Die sind m.E. deshalb sehr viel unflexibler, trotzdem sie etwas jünger sind.
Vielen Dank für das Video. Ich gehöre mit Mitte 40 wohl zu den "mittelalten" Entwicklern. Was ich aus eigener Erfahrung und auch in dem Unternehmen beobachten kann ist, dass - falls das Gehirn wirklich im Alter langsamer lernen sollte - dies zumindest durch die Erfahrung sehr gut kompensiert wird, wenn man denn die Motivation aufbringt sich weiterzubilden. Ich habe z.B. vor ein paar Wochen angefangen, eine für mich neue Programmiersprache zu lernen, um aus Spaß an der Freude an einem Open Source Projekt mitzuwirken. Durch die Erfahrung die ich habe verlief das lernen ziemlich nach dem Schema "Ah, das ist wie in C#, ok, das ist wie in C++, und das hier kommt von ganz woanders her. Wie ist Switch umgesetzt? Ahso, erst ab 3.10, heißt aber match/case"
Dadurch lerne ich vielleicht langsamer was die reine Auffassungsgabe angeht und die Zeit die ich dafür erübrigen kann - aber deutlich gezielter für das was ich benötige.
Hey Martin,
sehr gerne! Ja, bei Programmiersprachen kenne ich das Verfahren auch. Bei kompletten Technologiewechseln (Desktop/Cloud/Web etc.) ist es halt unverhältnismäßig schwerer aus meiner Erfahrung.
Gruß David
@@DavidTielke Ich habe mehrere Technologiewechsel mitgemacht. Ganz am Anfang stand für mich professionell ein SER2D - bei dem ich mein eigener Assembler war und den Assemblercode in Maschinencode umrechnete.
Für mich war das Schwierigste die scheinbare Vereinfachung durch Agile Programmierung. Zu dieser Zeit bearbeitete ich Dokumentation für Programme, die im Wasserfallmodell hergestellt wurden und solche, die "agil" erzeugt wurde. Die "agilen" Programme wurden leider nie wirklich fertig, sie entsprachen nicht den Kundenwünschen. Die anderen waren lange Zeit im Einsatz, zum Teil 20 Jahre mit Updates. Das lag nicht am Alter, sondern daran, dass agile Programmierung nicht für die Probleme geeignet war.
Übrigens: solche Wechsel, wie die von Dir angesprochenen, sind auch für Jüngere schwierig. Und auch für die Kunden.
Im Video entsteht der Anschein als ob man die älteren Kollegen aus Respekt mit "durchzieht". Aus Meiner Erfahrung haben jedoch auch ältere Kollegen, durch Ihre Erfahrung auch einen Beachtlichen Anteil am Gelingen von Projekten. Die älteren Kollegen springen nicht auf jede Technologie auf nur weil sie gut klingt. Ein Technologiewechsel muss auch entsprechende Vorteile bringen und die eingesetzte Technologie sollte auch eine langjährige Wartbarkeit gewährleisten. Hierbei sind die jüngeren Kollegen oftmals zu unbedarft. Oftmals sind die älteren Kollegen durch ihr Standing auch viel resistenter gegen Feature-Creep. Auch im Kommunikativen Bereich, vor allem gegenüber dem Kunden, können sie oftmals punkten.
Wow das fand ich total gut was du beschreibst. Kenne das zu genüge bin auch 50+. Mir fällt es auch bissel schwerer aber wenn Mann dran bleibt kann es gelingen mitzuhalten. Wir haben ein gemischtes Team und es klappt recht gut.
Hey,
absolut, denke schaffbar ist das für jeden aber in Summe ist es schon eine große Anstrengung.
Gruß David
Extern vs. Intern hast du auch solche Überheblichkeiten ...
Ja, mit dem Alter wird man träge und investiert nicht mehr jede freie Minute am Gerät.
Aus meiner Sicht wird Vieles auch komplexer und schnelllebiger. Ich hab mal länger am Mainframe gearbeitet, super stabiles Umfeld über Jahrzehnte. Heute in der Cloud, SaaS und AI-Welt ändert sich einiges alle paar Monate.
Oftmals sehe ich aber viele Konzepte wieder, nur halt neu verpackt.
Man(n) erkennt irgendwann, dass man nicht mehr alles begreifen kann, weil das gesamte IT-Universum zu groß ist. Vor 30 Jahren konnte man noch fast alles in Personalunion. Heute sind einzelne Frameworks schon so speziell, dass man sich darin lange einarbeiten muss.
Für das Design von Software und Systemen sowie die Steuerung sehe ich trotzdem Vorteile für "alte" Hasen. Warum nicht die eigentliche Programmierung den Jüngeren überlassen?
😄 Die Probleme welche die jüngeren Kollegen haben, wäre auch noch ein Thema:
"Junger Kollege trifft auf Programmiersysteme aus der _Steinzeit_ !"
Meine Erfahrung während und einige Zeit nach der Ausbildung war noch stark durch analoge Operationsverstärkertechnik, verbindungsprogrammierte Logik und pneumatische Analogrechner (kein Witz!) geprägt. Später kamen dann softwarebasierte Steuerungssysteme, bei denen die verfügbaren Funktionen und die zugehörigen Parameter mit Zahlencodes aufgerufen wurden.
Das ganze war systemintern nicht kommentierbar, sondern wurde extern auf Papier kommentiert. Mit diesem wenig selbsterklärenden Code hatten die jüngeren Kollegen heftige Probleme.
..und ich habe, nach mittlerweile 40 Jahren, immer noch die Zahlencodes der Funktionen im Kopf!🥸
Mein Vater hat auch pneumatische Schaltkreise hergestellt, in Dresden.
Danke für das Teilen dieser Erfahrung. Eine Bitte: bitte machen Sie in der Nachbearbeitung (Postproduction) eine Bildstabilisierung. 😵💫 Das hilft mir gegen Motion-Sickness 🙂
Hey,
sehr gerne!
Ich hatte eine neue Kamera das erste mal dabei und das Stativ war zu klein um im Schnee sicher stehen zu können, ist alles aus der Hand gefilmt - wird beim nächsten Mal besser, versprochen :)
Gruß David
das große Rätsel dieser Branche ist, wo sind alle älteren Kollegen geblieben. überall wo ich hinkomme sind die ältesten Entwickler um die 35. wie auch immer bin fast 60 und arbeite immer noch als Entwickler und es stimmt lernen neuer Technologien aus Büchern ist extrem schwierig und langsam. deshalb nur noch Videos oder neuerdings die Ki nutzen, um neues Sprachen oder Frameworks zu lernen. die KI erlaubt es auch mit den jüngeren Entwickler schritt zu halten, allerdings kommen im alter auch immer mehr gesundheitliche Einschränkungen aller Art hinzu. Man hat‘s nicht leicht.
Hey,
ich denke viele der älteren Kollegen suchen sich im alter Positionen in der Softwareentwicklung, bei der ihre Erfahrung sehr wichtig ist aber das erlernen von neuen Technologien nicht unbedingt: bsp. Product Owner, Architekt, Tester, Projektleiter,... Da gibt es einiges wo die gesammelte Erfahrung dem Team sehr nützlich sein kann.
Gruß David
Danke dass du dieses sensibles Thema angesprochen hast. Und deine Worte waren sehr Wertschätzend.
Vor allem das mit dem "alles wegschmeißen" sehe ich ganz anders: Sprachen und Frameworks kommen und gehen, aber die Beherrschung dieser Werkzeuge macht nur einen kleinen Teil von Softwareentwicklung aus.
Probleme erkennen, Lösungsansätze / Architekturen / Design Patterns zu finden, gern auch unorthodoxe. Komplexität bewältigen, Fehler erkennen, eigene Fehler anerkennen, Fehler nicht wiederholen, das Unerwartete erwarten und sich darauf vorbereiten, Code so zu schreiben, dass andere etwas damit anfangen können, niemals vor der Maschine kapitulieren und niemals schwieriges wegdelegieren, Hilfe anbieten und annehmen, immer neugierig sein, von anderen Codern lernen, statt nur aus Stack-Overflow zu kopieren.
Das sind die besonderen Skills, die einen guten von einem schlechten Entwickler unterscheiden. Das sind alles Skills, die jeden Technologiewechsel überdauern und da glaube ich einfach nicht, dass das Alter etwas daran ändert. Es ist eine Frage des Mindsets.
Alter Coder wie ich haben eher zusätzliche Vorteile - wir sind mehr als die junge Generation maschinennah geschult. Wer nur gelernt hat, Maschinen mit Framework Abstraktionen zu steuern, wird nie Lösungen finden, die über die Frameworks hinausgehen, wird bei Problemen nie wissen, ob sie in der Maschine, im Framework oder bei einem selbst liegen.
Zur Bezahlung möchte ich folgendes beisteuern: ja eine Diskrepanz zwischen Leistung und Alter/Bezahlung ist vielfach vorhanden, aber das sehe ich nur in der IT so wo die Anforderungen bzgl. Neuem besonders hoch sind, aber viele arbeiten eben nicht in der Branche IT sondern in irgendeiner Branche und dort im IT Bereich. Ob jetzt öffentlicher Dienst, Banken, Versicherungen überall wird nach Altersstufen/Dienstzugehörigkeit bezahlt, dort jetzt für die IT Abteilung ein anderes Gehaltsmodell zu verwenden wird nicht funktionieren, es würde dann kein Älterer mehr in der IT arbeiten
On the point, gilt wohl für die überwiegende Mehrheit aller Branchen. Schön beleuchtet. Ein gesundes Miteinander, ich denke das wünschen sich alle, weder Azubi noch ältere schneiden, viele firmen investieren in das Thema, überwiedend Gruppenarbeit. Der gesammte Gedankengang ist auf jeden Fall nachvollziehbar, weiter so!
Es ist eine sehr menschliche Geste diese Thematik in das Bewusstsein zu rücken und in einem Video klar auszusprechen. Hut ab! Ich kann euch SWEs aber zurufen, ihr seid nicht allein. In vielen Beruf gibt es altersbedingte Einschränkungen. Und in einem Kommentar wurde es schon gesagt, jeder ist gefordert sich seine Erfahrungen und besonderen Fähigkeiten bewusst zu werden und damit das Team zu stärken. Und jeder soll dem anderen Respekt zollen. Das Hierarchie-Gehabe unter Lehrlingen, Gesellen und Meistern ist mir mein Leben lang aufgestoßen. Und als Folge dessen denke ich würde es den Firmen, dem Arbeitsklima und damit den Projekten sicher gut, wenn man zu einer ausgeglichenen Bezahlungsstruktur findet.
Ich bin kein Softwareentwickler und stehe den spezifischen Problemen vermutlich ignorant gegenüber. Nach dem berühmten aber muss ich aber sagen: diese Anbetung jugendlicher schneller Auffassungsgabe ist nur noch nervtötend. Mit 50 ist man nicht blöde sondern etwas anders strukturiert. Die Integration neuer Techniken muss in einer älter werdenden Gesellschaft einfach anders angegangen werden.Die Änderung der Perspektive liegt da beim Teamentwickler. Das meine ich übrigens gar nicht so kritisch. Ein Profi ist ein Profi ist ein Profi, egal ob mit 30 oder mit 50. Oder eben nicht.
Ich bin zwar erst Mitte 40, aber die Jüngeren verstehen oft langsamer, weil sie keine Erfahrung dazu haben, wie sie Verständnis für eine Sache herleiten können
Ich bin inzwischen leider selbst ein "älterer Entwickler", aber der größere Schatz an Erfahrung gleicht Vieles auch wieder aus. Die technischen softwareseitigen Probleme und Stolperfallen in der "Kybernetik", wie mein Studienfach damals noch hieß, sind nicht unbedingt Andere geworden, nur weil sie inzwischen in anderen Programmiersprachen formuliert werden. Anders natürlich in der Hardware, wo meiner Ansicht nach deutlich mehr an grundlegend neuer Technologie entwickelt wurde. Die damaligen VLSI Entwürfe sind inzwischen einfach nur noch Makulatur, und spätestens bei den Quantencomputern muss man alles bislang Gelernte über Bord werfen. Aber zurück zur Erfahrung: Ich stelle fest, dass viele junge Entwickler zwar mit den neuesten Sprachen, Frameworks und Webtechnologien vertraut sind, es dafür aber an den Grundlagen mangelt - unterhalb von Layer 4 kommt oft nicht mehr viel. Hier hat man als älterer Entwickler oft die Möglichkeit, Fallstricke zu identifizieren oder bereits bei der Projektplanung auf mögliche Probleme hinzuweisen, die dem Team anderenfalls erst während der Entwicklung wieder vor die Füße gefallen wären. Der Blick "von oben" auf das Gesamtkonstrukt fällt mir heutzutage leichter als in jüngeren Jahren, wo ich mich eher noch an Detailproblemen festgebissen (und Zeit verbrannt) habe. Ich glaube, jede Phase im Berufsleben hat so ihre ganz eigenen Vor- und Nachteile.
FullAck. Bin 63 und > 40 Jahre IT. Was für die jungen Kollegen der heiße Scheiß ist, also das erste Framework das ihnen hilft ein Problem zu lösen, ist für mich vielleicht schon das 20te Framework aus diesem Bereich ... Da ist es oft nicht einfach motiviert zu bleiben.
Aber solange es trotzdem Spaß macht ...
Ich stimme Dir nicht zu: Lernen wird mit dem Alter NICHT schwieriger. Man bekommt nur mehr mit, was man alles nicht verstanden hat. Wenn man jünger ist, übersieht man die eigenen blinden Flecke und GLAUBT deshalb, man wäre schneller beim Lernen. Ich bin Mitte 50 und kann mir immer noch genauso schnell neue Dinge aneignen wie früher. Ich behaupte sogar, dass ich das mittlerweile schneller kann als früher. Und ich habe schon so einige technologische Entwicklungen miterlebt. Ich bin Kommunikationselektroniker und habe als Elektriker (mit so "dicken" Kabeln), Telefonbauer, Fahrer eines Satelitenlagers (am Leitrechner), in einem CNC-Maschinenbau-Unternehmen als Servicetechnikert und seit über 20 Jahren in einem Unternehmen für Sicherheitstechnik (Brand- und Einbruch-Meldeanlagen) gearbeitet. Ich habe die gesamte technologische Entwicklung von der Relais-Vermittlungstechnik bis zur heutigen Zeit mit gemacht. Ich habe vor ca. 15 Jahren eine eigene CNC-Fräse gebaut (ich habe die Platinen dafür selbst gelötet. Nicht bloß alles zusammen "gesteckt"). Ich betreibe einen kleinen Automatisierungsserver für mein Zuhause, entwickle dafür kleine Projekte (diverse Steuerungen für Licht, Musik, Klimatechnik, Wärmepumpe, PV-Anlage, Rollos, Gartentor etc.). Ich bin davon überzeugt, dass man nicht durch das Alter langsamer beim Lernen wird, sondern durch "Bequemlichkeit". Wenn man sich auch im "Alter" die jugendliche Neugierde und Begeisterungsfähigkeit erhält, lernt man genauso schnell (vielleicht sogar "nachhaltiger") wie ein junger Mensch. Man unterschätzt nur im Alter seine eigene Leistungsfähigkeit, weil man mehr einen Blick dafür hat, was man alles noch _nicht_ weiß. Es ist ein bisschen wie beim Dunning-Kuger-Effekt im oberen Wissensbereich: Je mehr Wissen man anhäuft, desto mehr sind einem die eigenen Unzulänglichkeiten bewusst. 🙂
13:25 oder auf Grund von Krankheiten oder Hormonprobleme kann man Probleme mit dem Lernen bekommen
Danke für das wertvolle video!
Ich bin
Naja, das Problem heute ist ja auch die Komplexität und die Vernetzung der Systeme untereinander. Eine Vereinheitlichung macht es wieder bequemer Dinge schneller zu erfassen.
Es ist nicht nur immer das Alter. Es ist der Spaßfaktor der es erlaubt, entweder schneller oder langsamer zu lernen. Je höher der Spaßfaktor ist, umso leichter und schneller kann man lernen.
Ich hatte in der Schulzeit immer mal Schwierigkeiten mit dem Auswendig lernen bekommen. Bei Naturkunde Fächern, wie Chemie, Biologie, Physik, Astronomie aber auch Werkunterricht habe ich keine Probleme mit gehabt.
Nach der Wendezeit 1989, im wahrsten Sinne des Wortes, musste ich auch viel dazu lernen. Das westdeutsche System war völlig anders und das mit dem Schuldgeldsystem eine schwierige Sache. Deswegen sind auch die Bauern, Handwerker und Industrieelle auf der Straße! Das ist aber ein anderes Thema.
Wir mussten schneller und effizienter lernen um zu begreifen, wie das System aufgebaut ist. Hinzu kommt ja auch die Digitalisierung, wo es immer wieder Überraschungen gibt und völlig neue Prozesse ins Leben gerufen wird.
Da sind auch die Lehrer in der Schule überfordert und können den Kindern absolut nichts bei bringen. Das fängt ja schon mit dem 1x1 an. In den 50er Jahren war das egal, ob man sagt das Eins und Eins gleich zwei ist oder man sagt Eins plus Eins gleich zwei.
Heute geht das nicht mehr! Eins und Eins ist gleich Eins. Denn in der digitalen Welt ist eine andere Voraussetzung des Rechnens erforderlich.
In den 80er Jahren war noch klassische Maschinensprache angesagt. Die Werkzeuge waren Assembler, Disassembler und Reassembler. Später wurde es einfacher und erst ab den 2000er Jahren wieder komplexer.
Das ist aber nicht nur in der Programmierung so, sondern betrifft ALLE Bereiche des Lebens. Hinzu kommen auch noch die Geisteswissenschaften die langsam Fahrt aufnehmen und dann bekommen wir eine völlig andere Sichtweise auf unser Leben. Da können wir nur Wachsam sein was noch auf einem so zu kommt.
Wieder mal ein sehr interessantes Thema! Vielen Dank auch allgemein für den ganzen Content - ich bin schon lange "dabei" und mir hat schon einiges sehr weitergeholfen 🙂👍
Ein Problem ist auch, dass nicht immer das geeigneste Framework fur ein Projekt gewahlt wird sondern einem Modetrend gefolgt wird.
Hier kann durchaus auch die Erfahrung von älteren Softwareentwicklern hilfreich sein, die bereits mit einem Framework erfolgreich gearbeitet haben oder auch Franeworks kommen und gehen gesehen haben. Hier gibt es schon Muster. Manchmal ist es sehr gzt gewesen nicht den neusten Scheiss zu nehmen sondern die etablierte Vorversion. Klassisches Beispiel sind die Windows Versionen. Fast ein alternierendes Muster. 😊
Hey,
ja klar, gibt sehr viele Situationen in den das Projekt und die jüngeren Kollegen von der Erfahrung der älteren profitieren können :) War auch Bestandteil des Videos, aber um es kürzer zu bekommen, habe ich den Teil weggelassen.
Gruß David
Ältere haben aber auch viel Erfahrung, das macht es wieder wett. Und ich denke es ist kein Altersproblem, es ist eine Einstellungssache. Will ich mich fortbilden oder nicht, will ich meine Glaubensgrundsätze auch mal über Board werfen oder nicht? In meiner letzten Firma gab es einen Geschäftsleiter (~50) und einen Mitarbeiter (~35) die auf Ihrem Know-How von vor 20 bzw. 10 Jahren stehen geblieben sind. Deswegen bin ich jetzt bei einer anderen Firma ;-).
Erfahrung sammeln allein macht einen nicht besser. Nur wenn man aus seinen Fehlern und den erfahrenen Dingen dazu lernt ;) Das ist auch das Problem mit den Titeln Junior oder Senior. Rein nach Berufserfahrung macht das nicht unbedingt Sinn. Denn manche Menschen lernen schneller und mehr. Genauso wie die Beurteilung im Job an den verbuchten Stunden oder der Wochenarbeitszeit Blödsinn ist. Denn Leistung ist ungleich Zeit.
Hey,
absolut das gehört noch einiges mehr zu :)
Gruß David
Am Anfang hast du etabliert das es diese drei Säulen der Softwareentwicklung gibt: Technologie, Architektur, Domänenwissen. Im Video gehst du jetzt aber nur auf die eine Säule der Technologie ein, welche, ohne Frage, eine wichtige ist. Von daher, gefällt mir das Bild der gegenseitigen Wissensverteilung. Denn z.B. Architektonischefehler, zu welchen jüngere Softwareentwickler eher neigen, können nicht durch die reine Techologie aufgefangen werden. Die Unternehmenskultur der Wissensverteilung, ist meiner Ansicht nach wichtig, damit Teams, unterschiedlicher Erfahrungslevel, erfolreich sein können.
Das stimmt, also 20Jährige hatte ich viel mehr Zeit und ich konnte auch länger wach bleiben, um viel zu lernen. Zwischendurch zockt man noch mal was.
Aber auch mit 45 und Schulkind und Haus und Auto (ohne Boot) kann ich durchaus viel lernen und ich bin im Betrieb diejenige, die immer Neues machen will, aber der ganze Apparat will nicht. Wie wie neue DB? OMG.
Daher halte ich dieses "ältere Menschen können nicht mehr so gut lernen" eher für eine selbsterfüllende Prophezeiung. Wer glaube, er/sie lernt schlechter, der/die lernt auch schlechter. Meiner Meinung nach ist das alles Typsache. Ich probiere alles aus, von .NET 8 bis JS/React bis Go bis Python und KI bis Microservices & Modular Monolith und DDD. Menschen sind einfach unterschiedlich und aus seiner Comfortzone kommt nicht jeder raus.
eine uralte Weisheit die für menschliches Miteinander für immer und ewig weitergelten wird ist "Was du nicht willst das man dir tue, das füg auch keinem anderen zu" irgendwann im Leben kommt jeder mal an diesen Punkt
Wenn ich es auf der Arbeit brauche, hat mir dafür auch Arbeitszeit eingeräumt zu werden. Dann stehe ich eben pro Woche 5-8 Stunden weniger zur Verfügung, damit ich danach dann helfen kann, neue Projekte zu erschließen.
Bin selber vom Entwickler zum Projektmanager gewechselt.
Macht mir mehr Spass, ist für mich weniger stressig und die Entwickler sind dankbar das man ihnen Respekt zollt.
Ich bewege mich mit meinen 57 eh lieber eh im Embedded System Bereich, Signalverarbeitung und HPC etc. Erst mal weil die fachlichen Domänen viel spannender sind als z.b. Buchhaltungs-Software oder der Web-Shop, und der Technologie-Stack ist langlebiger.
Vielen Dank für dieses interessante und wertvolle Video! Ich fand es sehr anregend.
Hey,
sehr gerne, freut mich das es Dir gefällt.
Gruß David
Ich habe viel mit alten gearbeitet, bin jetzt selber alt. Das Lernen verändert sich, aber ich glaube die meisten alten Coder waren schon schlecht als sie jung waren; oft auch wegen der damals viel, viel schlechteren Qualität des Lehr- und Referenzmaterials.
Hier mal mein Senf dazu. 1. Ich habe lange Software entwickelt und in der Freizeit mache ich das gelegentlich immer noch. 2. Ein guter Softwareentwickler entwickelt sich selbst und wird irgendwann Software-Architekt oder Projektleiter oder gar Product Owner und muss sich mit den Details nicht mehr herumschlagen. Damit bleiben im Alter solche Softwareentwickler, bei welchen es entweder Herzblut ist oder welche stehengeblieben sind. 3. Ich hatte das Problem mit meinem Vater, welcher aus meiner Sicht katastrophalen Code schrieb und bei welchem ich viele Programme (in COBOL btw.) auf den Kopf stellte und durch neue Architektur viele Fehler vermied. Er ist übrigens jetzt mitte 80 und kann das Programmieren immer noch nicht lassen. 4. Junge Entwickler können auch viel Mist bauen, weil sie sich nicht in die Aufgabe reindenken. Ich habe lange Indische Entwickler gesteuert und da muss man gelegentlich demonstrieren, dass man es immer noch drauf hat, wenn sie wieder mal meinen, etwas ginge nicht. Ich habe da gelegentlich denen den Fehler und die Codezeile genannt, welche sie anpassen müssen, wenn sie nicht spurten. Aber sobald der gegenseitige Respekt etabliert war, ging es mit gutem Tempo voran. 5. Die besten und beständigsten Programme sind die, welche man in einer Nacht und Nebel Aktion übers Knie gebrochen hat. Ich weiss nicht wieso, aber diese Programme hatten bei mir immer die längste Lebensdauer und waren nicht totzukriegen. 6. Ein guter Softwareentwickler liebt die Stetigkeit des Wandels und experimentiert mit Neuem und bildet sich dadurch weiter. Er muss nicht Kurse besuchen, sondern den Wandel leben und immer wieder etwas neues tüfteln. Das Problem sind Entwickler, welche stehenbleiben und denken, ich will jetzt das so machen, wie ich es immer gemacht habe. Dieser sollte aus der Entwicklung raus und vielleicht Wege nach Auf- und Ausstieg suchen. Ich hatte auch keine Lust mehr auf den Stress der Entwicklung und als PO und als Projektleiter verdient man dazu noch mehr. Grundsätzlich gilt, wer stehen bleibt, macht Rückschritte. Mein Vorbild ist immer noch ein Mechanikprofessor aus dem Studium, welcher 80 war und geistig topfit. Das bleibt man nur, wenn man sein Hirn immer wieder strapaziert. Btw. es ist auch keine dumme Idee, privat Musik zu machen. Das fördert die Flexibilität des Hirns ebenfalls. Schlussendlich: Wir werden alle älter und müssen unseren Weg finden. Vielen Dank für Deinen Beitrag und alles Gute ! Patrick
Ich bin mir bzgl. der "im Alter lernt man schlechter"-Geschichte nicht so ganz sicher. Ich merke bei mir auch, dass einige Themen einfach nicht in den Kopf gehen - aus guten Gründen. Mir fehlt bei diesen Themen der Bezug. Aktuell stehen ein paar Änderungen im Beruf an und ich muss mich unter anderem wieder mit Java und Python befassen. Also keine Dinge, von denen man erwarten würde, dass sie "schwer" wären. Aber ich tue mich unendlich schwer. Privat betrachte ich seit ca. einem halben Jahr Rust und Go und fliege da durch alle Themen - selbst Dinge, bei denen ich mir den Kopf einschlage, hänge ich mit großer Lust dran und probiere, bis es so funktioniert, wie ich es mir vorstelle. (Hallo Async unter Rust... wenn es Kritikpunkte gibt... hier hätte ich einen)
Mir fehlt bei den beruflichen Themen aber der Spaß, der Entdeckungsdrang und die Angst vor dem zukünftigem Projekt, wo man wieder einem ORM-Mapper hinterherdebuggt um N+1 Probleme zu lösen, weil einfach wild drauf losgestöpselt wird, weil "Framework regelt schon".
Das ist auch etwas, was ich bei einigen älteren Arbeitskollegen beobachte. Der Biss ist nicht mehr da - die Lust auf das Unbekannte. Sei es, weil die Projekte wirklich langweilig sind oder man genauso gut bei seinem cpp bleiben kann und der Umschwung auf andere Technologien nicht nachvollziehbar ist. Dann war es damals "normal" bei einem Arbeitgeber zu bleiben. Die Anforderung ist damit über _Jahrzehnte_ eindimensional gehalten. Wer nicht regelmäßig trainiert, setzt an. Das passiert auch im Kopf. Hier gehören die AG angehalten ihre Mitarbeiter - schon aus eigenem Interesse - regelmäßig dazu zu zwingen sich projektfremde Dinge anzusehen. Ja, das kostet etwas Geld, aber es kostet mehr, doofgehaltene Mitarbeiter später durchzuschleppen.
Für mich bleibt das Alter ein vorgeschobener Grund, die Kausalität sehe ich, aber bedingt durch kalte Begleitumstände.
Du willst zu viele Dinge gleichzeitig lernen. Konzentriere dich auf eine neue Programmiersprache und werde da Profi.
@@bassmaster187 Ich schreibe seit Jahren Code in Kotlin, Typescript und habe zuvor ein Jahrzehnt mit Java (Was glaubst du warum ich Angst vor dem neuen Projekt habe - ich kenne die Faulheit der Entwickler, die Rückständigkeit der Programmiersprache und die damit verbundene Nutzung von Frameworks, die keine Abhilfe schaffen) verbracht. Alles auf professioneller Ebene. Ich danke dir trotzdem für deinen Input, aber hier ist meiner: Sieh dich um, du musst keine neue Sprache in depth kennenlernen. Aber Abseits der langweiligen standard-c Welt befinden sich unzählige andere Paradigmen, die deinen Horizont erweitern und vor allem deinen Hunger auf Wissen aufrecht erhalten. Und wer keine andere Programmiersprache will - dann schau dir anderes Tooling an. Aber auch das muss entweder in der Freizeit passieren oder, und da bin ich großer Fan von, vom Arbeitgeber erzwungen. Imho der Unterschied zwischen einem guten Arbeitgeber und einem, der einen Codingmonkey braucht und kein Interesse an der persönlichen Weiterentwicklung des Mitarbeiters sieht.
Hey,
ja der Punkt Motivation ist ein großer Teil des Lernerfolgs - ich habe ihn nur mit der "Zeit im Alter" umschrieben, weil ich es zu provokant fand und sehr viele ältere Kollegen sich hier dann angegriffen gefühlt hätten.
Gruß David
Das ist eigentlich ein heftiges Thema. Vielen Dank für den Input. 👍
Es gibt auch noch den gegenteiligen Aspekt: viele Grundprinzipien ändern sich eigentlich nicht. Wartbarkeit, Zukunftssicherheit, Erweiterbarkeit, performance, das alles hängt nicht so sehr von neuen oder alten Technologien ab. Erfahrenere Devs sehen oft die Technologien und Frameworks, von denen du sprichst, als das an was sie sind: Tools. Die Tools ändern sich, das was an Ende dabei herauskommen soll, nämlich robuste Software, funktioniert aber eigentlich seit 40 Jahren mehr oder weniger gleich. Die jüngeren Kollegen sehen oft nur die aktuell neuste Technologie und machen diese gerne ein wenig zum Selbstzweck. Ich denke die Generationen ergänzen sich bestenfalls. "Probleme" sehr ich eher weniger, eher Kommunikationsschwierigkeiten, die unter Devs ziemlich verbreitet sind. Daran muss gearbeitet werden in der Welt der Software-Entwicklung.
Ich werden bald 50 und lebe seit 30 Jahren von IT... ich kann vieles gesagte sehr gut Nachvollziehen... ich sehe aber auch dass die Jüngeren oftmals aufgrund von Erfahrung sich in Dinge verrennen oder oft unsauber testen... Gemischte Teams sind einfach am besten und super ist wenn Themen wie dieses offen angesprochen werden... Dazu gehört Mut von allen.
Ich bin 53. Ja, man lernt mit zunehmendem Alter anders. Zu dem anders gehört auch das langsamere Lernen. Man vergisst schneller und man hat viel mehr um die Ohren als mit 20. Deswegen war früher auch alles besser. Was den meisten nicht bewusst ist: Wir haben in der Erwachsenenpädagogik ne Menge research über diese Unterschiede, denn man kann auch mit 80 noch sehr viel lernen, die Plastizität des Gehirns gibt es her. Man muss aber die Lernmethoden ändern, die Inhalte anders strukturieren, also die Didaktik anpassen. Man muss sich mehr Zeit nehmen und genauer fragen, was genau man eigentlich lernen muss. Man fängt mit 50 nicht mehr an, die Schleife als solche zu verstehen, man weiß halt, wie Schleifen funktionieren und was ein Zeiger ist. Diese Änderung des wie und was wird ignoriert, stattdessen versuchen die Leute, auch oberhalb der 30 (wo etwa der Wechsel der Struktur losgeht) noch mit 50 so zu lernen wie mit 20. Das scheitert. Schwör.
Man muss neben der Fachebene auch die soft skills, die Erfahrungsebene, die Persönlichkeitsebene einbeziehen. Man hat vieles im Urin und damit meine ich weniger den PSA Test oder die Line vom Vorabend. Es ist wirklich wichtig, dass man aus der Erfahrung heraus der Intuition folgen kann und damit viele Lösungen einfach parat hat.
Und man muss sich entwickeln. Auch das wird in den Bildungsbiografien ersichtlich. Ein guter Weg ist zum Beispiel: Starte als Hackschein, werde ein guter Programmierer, dann wechsle immer mehr zum Entwurf und der Architektur, ergänze Themen wie Teamverantwortung und betreue Budgets, gehe weiter über Testen und QM zu höheren Themen der Architektur, finde mehr Führungsthemen und Kundensupport, Fehlersuche hat viel mit Erfahrung zu tun, mache mehr Anforderungen, Projektkoordination, Task Forces für spezielle Probleme usw. Da haben auch die Unternehmen viel nachzuholen im richtigen Einsatz der Leute. Das ist natürlich nicht komplett zu dem Thema, aber so als Diksussionsanstoß in addition zu dem Thema des Videos. Danke für dieses sehr wichtige Video!
Grins :-) "Erwachsenenpädagogik" ist eigentlich ein Paradoxon. _Pädagogik_ beschäftigt sich mit Kindern und Jugendlichen, bei Erwachsenen heißt das Fachgebiet _Andragogik._