📱

Get Our Mobile App

Take your business learning on the go!

Download on the App StoreGet it on Google Play

How Programmers Flex On Each Other

Computer Science for Humans27:57

Transcription

Hallo und willkommen zu Informatik für Menschen. Heute werden wir auf ein Video reagieren, das ich angefangen habe zu schauen und das ich dann mit euch teilen wollte, weil es ziemlich gut ist. Wir werden darüber sprechen, wie Programmierer aufeinander flexen, und ich denke, das wird ziemlich gut. Dieses Video ist von Fireship mit einem winzigen kleinen Kanal. Ihr wisst schon, nur etwa vier Millionen Abonnenten. Äh, ich weiß nicht, wofür das M steht, aber ihr wisst schon, gebt ihnen dafür etwas Liebe. Fireship heißt "How Programmers Flex on each other". Und äh, um meinem Trend treu zu bleiben, nur am Puls der Zeit zu sein, ist dieses Video gerade mal 2 Jahre alt, aber es scheint cool zu sein. Es hat eine Menge Views, und äh, ja, wir werden es uns gemeinsam ansehen. Mal sehen, was dieser äh, dieser Typ zu sagen hat. Nebenbei bemerkt, ich werde nicht das Ganze anschauen. Ich werde es zu den interessanten Punkten schneiden, zu denen ich etwas zu sagen habe, denn wenn ihr das ganze Video sehen wollt, solltet ihr es einfach auf ihrem Kanal anschauen. Vor vielen Jahren, in einer Geschichte, die ich mir gerade ausgedacht habe, habe ich eine hoch skalierbare Infrastruktur entworfen, als ein Staff Engineer in mein Büro kam und sagte: "Hey Kumpel, das ist ein süßes VS Code-Theme, das du da hast." Oh, danke. Es ist Synthwave mit aktiviertem Power-Modus. Bevor ich mehr erklären konnte, unterbrach er mich. Ich habe es gerade bemerkt. Warte mal. Es hat sich automatisch ausgefüllt, dumm. Oh, danke. Es Okay, was ist das für ein Code? Warte mal. Sith Datum volles Jahr. Wenn das volle Jahr 1984 ist und der aktuelle Standort ein Dach ist und die Wetterbedingungen sintflutartiger Regen sind, dann warte auf die Nacht. Das ist so gut. Oh, das ist so gut. Saxophon-Solo = neues Saxophon-Solo.play. Das ist erstaunlich, Mann. Ich liebe das. Siehst du den Bug in Zeile 234, richtig? Ich sagte: "Nein, das ist unmöglich, Sir. Wir haben 100% Testabdeckung für diesen Code." Nun, ich werde ihn in Neoim auf meinem Arch-Desktop aufrufen und äh, ich werde Ihnen einen PR dafür schicken. 5 Minuten später erhalte ich eine Benachrichtigung in Slack, dass der PR eingegangen ist. Alle Tests werden bestanden, mit 469 Zeilen Code entfernt und nur einer Commit-Nachricht, die lautete: "Optimierter sub-optimaler Code". Es ist also wirklich lustig. Das ist mir tatsächlich fast identisch passiert. Wir waren allerdings nicht in Büros. Es war noch relativ kurz nach dem College, also war ich noch nicht lange im Berufsleben. Und äh, ich war noch relativ neu. Ich war brandneu im Team und ich glaube, sie hatten mich ungefähr eine Woche zuvor eingestellt und äh, ich wurde für etwas verantwortlich gemacht und habe meinen ersten Pull Request eingereicht und im Grunde habe ich viel gezögert. Ich habe im Grunde gesagt: "Hey Leute, das ist die Art von Dingen, die ich tun möchte. Was haltet ihr davon?" Und die Senior-Entwickler im Team haben mich dafür regelrecht zerfleischt. Äh, sie haben buchstäblich, ich habe einen sehr einfachen, sehr kurzen Pull Request geschickt, im Grunde gesagt: "Ist das die Art von Dingen, die ihr von mir wollt?" und sie haben ein Buch geschrieben, drei verschiedene Leute haben ein Buch geschrieben, das mich im Grunde für alles, was sie sich vorstellen konnten, was ich falsch gemacht hatte, beschimpft. Und äh, es war eine harte Erfahrung. Äh, das war kein schöner Arbeitsplatz. Aber äh, ja, es ist lustig, dass er das als erstes Beispiel nennt, denn das ist mir fast genau passiert, als ich noch neu war. Dann blickte ich aus dem Fenster und sah ihn in seinem Tesla wegfahren. In diesem Moment erkannte ich, dass er keinen Tesla hatte. Sein Chef aber schon. Ich wurde geflext. Wenn du ein Programmierer bist, der sich niedergeschlagen fühlt, ist eine der besten Möglichkeiten, sein Ego zu stärken, andere Entwickler zu flexen. Für Programmierer gibt es nur zwei Zustände: Hochstapler-Syndrom oder Überlegenheitskomplex. Ich wünschte, das wäre weniger wahr. Ehrlich gesagt, äh, ich habe das Gefühl, das ist das übliche Szenario. Es gibt einen Mittelweg, der keiner dieser bösen Türme ist, aber es ist definitiv harte Arbeit, dorthin zu gelangen. Es ist nicht einfach. Äh, es gibt keinen klaren Weg dorthin. Ja, das ist sehr wahr. Traurigerweise, Mann. Der Typ ist muskulös. Ich meine, ich möchte so aussehen, wenn ich code. Vielleicht mit meinem Hemd an, aber ihr wisst schon. Obwohl, er könnte auf Steroiden sein, weil er kahl ist. Ich weiß es nicht. Er ist vielleicht einfach kahl, aber ich weiß, dass Steroide oft kahl machen können. Zuerst haben wir den Komplexitäts-Flex. Ein Idiot bewundert Komplexität. Ein Genie bewundert Einfachheit. Das ist fantastisch. Und ich habe lange gebraucht, um das wirklich zu verstehen. Ich denke, dieses Konzept ist ein Grund, warum die äh, Clean Code, ich weiß nicht, Paradigma, Bewegung, was auch immer man es nennen will, an Gunst verliert, zumindest bei meiner Generation und jünger, denn Clean Code, ich hasse es, dass es so heißt, weil es ein Schlüsselwort ist, denn ich mag die Idee von sauberem Code, aber es ist ein Schlüsselwort. Also, ich denke, die Kernidee von Clean Code ist cool. Es geht im Grunde darum, Dinge so weit zu abstrahieren, dass man die Details nicht kennen muss, wie sie funktionieren. Man muss nur das Gesamtkonzept kennen, wie die Teile zusammenpassen sollen. Das Problem mit Clean Code ist jedoch, zumindest in der Praxis, dass meiner Meinung nach oft so viele Abstraktionsebenen entstehen und äh, Primagen spricht ständig darüber, dass man so viele Abstraktionsebenen hat, dass man irgendwie den Kontext dessen verliert, was tatsächlich im Code passiert. Ich denke also, es gibt einen Mittelweg. Wie offensichtlich ist etwas Abstraktion normalerweise gut, aber es gibt definitiv ein Gleichgewicht. Und ich weiß, für mich war Java meine erste Programmiersprache und als ich JavaScript lernte, lernte ich es äh klassenbasiert und objektorientiert und so weiter. Dasselbe mit Python. Objektorientierte Programmierung tendiert sehr stark zu Komplexität über Einfachheit, weil sie versucht, die Details des Problems zu abstrahieren. Nebenbei bemerkt, wenn ihr ein Video über Abstraktion wollt, lasst es mich wissen. Ich werfe es gerade als Fachbegriff ein. Lasst es mich also auf jeden Fall wissen, wenn ihr ein Video wollt, in dem ich das detaillierter bespreche und wir einfach durchgehen, was Abstraktion wirklich ist. Und ich werde vielleicht sowieso ein solches Video machen, aber besonders, wenn ihr es wollt. Aber ja, ich denke, das ist eine wirklich wahre Aussage. Es ist auch wichtig zu beachten, dass Einfachheit nicht dasselbe ist wie Prägnanz oder Kürze. Kürze, ich weiß nicht, wie man das sagt, aber Prägnanz, also nur eine Zeile Code, bedeutet nicht unbedingt, dass es einfach ist. Einfach kann bedeuten, dass es 20 Zeilen Code statt fünf sind. Aber aufgrund der Art und Weise, wie man die 20 Zeilen Code organisiert, ist es viel einfacher zu lesen. Der Zweck ist klarer und die Schritte, die man unternimmt, sind klarer. Und oft, wenn man die Schritte, die man unternimmt, klarer macht, kann man die Anzahl der benötigten Schritte tatsächlich reduzieren. Aber ja, ich mag das sehr. Denkt daran, wie dumm der Durchschnittsmensch ist, und dann stellt fest, dass die Hälfte von ihnen dümmer ist als das. Das ist ziemlich gut. Die Frage ist, auf welcher Seite davon bist du? Wisst ihr, denn jeder, der das gehört hat, dachte: "Oh ja, wow. Es gibt so viele mehr Leute, die dumm sind als ich." Aber es besteht eine 50%ige Chance, dass du auf der dummen Seite bist, mich eingeschlossen. Ihr wisst, was ich meine? Und ich denke, es ist auch erwähnenswert, dass dumm oder klug zu sein, normalerweise auf ein bestimmtes Thema beschränkt ist. Ich habe Freunde, die in bestimmten Dingen wirklich schlau und in bestimmten Dingen wirklich dumm sind. Und ich denke, ich bin in bestimmten Dingen ziemlich schlau und in bestimmten Dingen auch ziemlich dumm. Meine Frau kann das bezeugen. Aber ja, es ist interessant. Die ganze Idee von Intelligenz fasziniert mich sehr und ich denke, sie wird oft missverstanden. Ich glaube nicht, dass sie so genetisch bedingt ist, wie die Leute denken. Ich glaube nicht, dass Intelligenz etwas ist, womit man geboren wird. Ich glaube, es ist etwas, das man lernt. Und ich glaube, Dummheit ist eine Wahl, kein natürliches Nebenprodukt dessen, wer man ist. Lasst mich wissen, wenn ihr ein Video dazu sehen wollt, denn das ist ein tiefes Kaninchenloch. Aber ich habe das Gefühl, dass Intelligenz und das Thema Intelligenz für die Programmierung tatsächlich sehr relevant sind. Denn ich weiß nicht, wie es euch geht, aber für mich ist die erste Reaktion, wenn ich jemandem sage, dass ich Programmierer bin, neben "Kannst du meinen Drucker reparieren?" die: "Oh, du bist also ziemlich schlau, dann." Und ich sage: "Ich weiß nicht. Ich bin nur ein Typ." Wie, Programmierer zu sein bedeutet nicht, dass ich schlau bin. Ich kenne viele dumme Programmierer. Ich war viele, viele Male ein dummer Programmierer. Ich glaube, Dummheit ist eine Wahl. Dann denke ich, die Frage, die man sich stellen muss, ist: "Wähle ich gerade Dummheit?" Und wenn ja, solltest du aufhören. Die Antwort auf diese Frage ist nicht immer offensichtlich, deshalb braucht man Leute um sich herum, die einem helfen, die Wahrheit der Situation zu erkennen, wenn man Dummheit wählt. Aber das ist eine ganz andere Sache. Wenn ihr ein Video dazu wollt, lasst es mich wissen. Äh, ich mag Philosophie, also vielleicht wären Philosophievorträge lustig. Nimm etwas Einfaches wie eine perfekt funktionierende JavaScript-Funktion, füge dann TypeScript hinzu und predige dabei die Tugenden der End-to-End-Typsicherheit. Ich hasse TypeScript. Ich halte es für einen sehr fehlgeleiteten Versuch, Java weniger zu einem Ball aus Klebeband zu machen. Und ich denke, der Grund, warum es fehlgeleitet ist, ist, dass sie auf diese Weise ein Typsystem auf den riesigen Ball aus Klebeband, der JavaScript ist, kleben. Wenn ihr TypeScript liebt, sagt mir bitte warum in den Kommentaren. Und nur damit ihr es wisst, wenn ihr TypeScript mögt, ist das in Ordnung. Es ist mir egal. Fühlt euch frei, es zu mögen. Ich sage nicht, dass ihr dumm seid, weil ihr es mögt. Ich denke, die Idee, TypeScript überhaupt in JavaScript einzubauen, war, ich weiß nicht, ob kontraproduktiv das richtige Wort ist. Es hat definitiv seine Anwendungsfälle, aber ich habe einfach das Gefühl, dass es JavaScript eine Komplexitätsebene hinzufügt, mit der JavaScript die Infrastruktur nicht bewältigen kann. Ich denke, das ist eine gute Zusammenfassung. Aber fühlt euch frei, mir in den Kommentaren unten zu widersprechen. Ich mag es eigentlich sehr, wenn ihr mir widersprecht. Äh, es gibt mir tolle Gesprächsthemen und so weiter. Also ja, aber ja, ich mag TypeScript überhaupt nicht. Es wäre vielleicht besser, wenn es keine Java-Syntax verwenden würde, aber ich weiß, sie haben Java-Syntax verwendet, um Java-Leute einfacher zu JavaScript zu bringen, denn ich denke, das ist der ganze Zweck von TypeScript: Wenn du an objektorientierte Programmierung gewöhnt bist, hier ist eine Möglichkeit, JavaScript zu machen, und es ist immer noch objektorientierte Programmierung, außer dass es das nicht ist. Es ist immer noch normales JavaScript unter der Haube. Das Typsystem ist eine vollständige Fassade. Das ist es, was ich daran nicht mag, dass das Typsystem eine vollständige Fassade ist. All die JavaScript-Eigenheiten sind immer noch einfach da. Es beseitigt also keine der Nachteile von JavaScript. Es ist, als hättest du einen Ball aus Klebeband genommen, ihn bemalt, damit er wie ein Basketball aussieht, und dann damit Basketball gespielt. Aber es ist kein Basketball. Es ist ein Ball aus Klebeband. Hoffentlich ergibt die Analogie Sinn. Lasst mich noch einmal wissen, wenn ihr ein vollständiges Video zu diesem Thema wollt. Es ist ein sehr interessantes Thema. Abstrakte Fabrik, Singleton, Adapter, Dekorateur, Proxy. Das ist ein so gutes Beispiel dafür, was ich vorhin meinte, wie Clean Code Dinge übermäßig abstrahiert. Und ich weiß, das ist genau das, was er auch anstrebt, es ist das verwirrte Schlürfen. Das habe ich gerade gesehen. Das ist so gut. Aber ja, das ist das Problem mit Clean Code, man landet bei Dingen wie einer von dort, refaktorisiert es in eine abstrakte Fabrik, Singleton, Adapter, Dekorateur, Proxy, dass man damit endet, und es ist wie, oh mein Gott. Hier ist die Sache, die meiner Meinung nach Clean Code nicht wirklich berücksichtigt, das menschliche Element. Insbesondere in dem Fall, dass in einer Unternehmensumgebung, wo die meiste Programmierung stattfindet, man argumentieren kann, dass Start-ups getrennt von Unternehmen sind. Ich werde sie vorerst zusammenfassen, da ich denke, dass sie sehr ähnliche Umgebungen haben, nur unterschiedliche Genres. Sie sind wie verschiedene Dialekte derselben Sprache. Aber in einer Unternehmensumgebung, was meiner Meinung nach Clean Code nicht wirklich gut berücksichtigt, ist eine sehr häufige Sache, dass ein Team ein Produkt oder eine App oder was auch immer baut, und sie verwenden Clean Code, um all diese Abstraktionssachen zu machen. Die Leute, die es bauen, beginnen, eine gute Vorstellung von einer mentalen Karte zu haben, wo alles ist. Hier ist das Singleton. Hier ist die Fabrik. Hier ist der Dekorateur. Deshalb sind sie so. Aber dann kündigt jemand oder der Chef wechselt und er beschließt, dass er ein komplett neues Team will, oder das Projekt wird abgesagt und dann später neu gestartet, oder das ganze Ziel des Projekts verschiebt sich und jetzt hat man all diese Abstraktion und entweder verschiebt sich der Kontext und die Abstraktion ist nicht die richtige Art von Abstraktion für das Projekt, das man macht, was eher ein Problem mit dem Projektentwicklungslebenszyklus ist als mit dem Coding selbst. Häufiger wird man eine Situation haben, in der das Projekt, wenn man zu 80% fertig ist, von einem völlig anderen Team betreut wird. Und das passiert nicht immer, aber es passiert oft genug, dass ich wirklich denke, dass die Menge an Abstraktion es neuen Leuten wirklich schwer macht, eine mentale Karte zu erstellen, wo alles ist, weil man es in vier Dimensionen lernen muss. Es ist nicht nur so: "Okay, hier ist die Sache, die das tut, hier ist die Sache, die das tut." Es ist eher so: "Okay, wir haben ein System dafür, aber man muss eine Fabrik benutzen, um es zu machen, und man muss ein Singleton verwenden, um alle Fabriken zu verwalten, und dann, wisst ihr, so etwas, und es gerät wirklich leicht außer Kontrolle." Ich frage mich und lasst mich wissen, was ihr dazu denkt in den Kommentaren. Ich frage mich, wie viel von der Schwierigkeit und Komplexität von den Leuten kommt, die die Softwaremuster, die Entwurfsmuster implementieren, das Muster nicht gut verstehen und den Zweck des Musters. Wie sie können das Muster machen und sie können etwas sehen wie: "Oh, ich könnte das in eine Fabrik oder ein Singleton oder einen Proxy oder was auch immer er sonst noch gesagt hat, verwandeln." Es gibt eine Menge davon. Eine Zustandsmaschine ist ein weiteres Beispiel, obwohl das persönlich eines meiner Lieblinge ist. Und obwohl diese Situation vielleicht so aussieht, als könnte man eines dieser Muster verwenden, bedeutet das nicht, dass dieses Muster für das Projekt als Ganzes besser ist. Es ist eine Art, den Wald vor lauter Bäumen nicht zu sehen, wo man ein paar Bäume zusammen sieht und denkt: "Oh, das wäre ein toller Hain", was nur eine Baumgruppe ist, richtig? Oder ein Bestand, wenn man altmodisch und britisch ist. Eine Baumgruppe und man gruppiert sie und baut eine kleine Mauer darum und alles. Man denkt: "Cool." Und man vergisst, dass man gerade eine Mauer um etwas gebaut hat, das eigentlich Teil eines größeren Waldstücks ist und jetzt blockiert ist, und man muss all diese zusätzlichen Wege benutzen, um rein und raus zu kommen. Hoffentlich ergibt die Analogie Sinn. Lasst mich noch einmal wissen, wenn ihr ein vollständiges Video dazu wollt, oder wenn ihr mit irgendetwas nicht einverstanden seid, was ich sage, äh, irgendetwas davon oder wenn ihr zustimmt. Das mag ich auch. Es ist schön, ab und zu nette Kommentare zu bekommen. Aber ja, all das, um zu sagen, ich denke, das ist eines der größten Probleme mit der Clean Code-Bewegung, man landet bei Dingen wie diesem. Und oft liegt das daran, dass die Leute Clean Code-Prinzipien übermäßig anwenden, was meiner Meinung nach, wenn man Uncle Bob in einem eher debattenhaften Kontext sprechen hört. Wenn ich mich richtig erinnere, werde ich den Link unten einfügen. Er sprach mit Primagen, es war sehr, sehr interessant, weil sie sehr unterschiedliche Paradigmen für die Programmierung haben, aber wenn man ihn sprechen hört, denke ich, dass dieses Maß an Abstraktion und Komplexität tatsächlich ein Merkmal und kein Fehler für das System ist, weshalb ich die Clean Code-Bewegung immer weniger mag, je älter ich als Programmierer werde. Ich denke, es will einfach ein bisschen mehr Komplexität, als es meiner Meinung nach normalerweise angemessen ist. Lasst mich noch einmal in den Kommentaren wissen, wenn ihr anderer Meinung seid, und wenn niemand das versteht, sagt ihnen einfach, sie hätten noch nie Clean Code gesehen. Ja, genau. Ja. Und sie hätten das Gang of Four Buch lesen sollen, damit sie denken, du wärst eine Art Programmiergott. Das Aber wirklich, das ist es, was passiert. Was ist dieser CTO, der nicht programmieren kann? Ich bekomme eine Gehaltserhöhung für grobe Überentwicklung. Das stimmt aber. Ich habe das auch schon erlebt. Ich habe an Orten gearbeitet, wo es diesen einen Typen gab. Es war tatsächlich derselbe Job, den ich schon erwähnt hatte, aber es gab einen Typen, der zwei separate Tickets auf unserem Jira-Board hatte, denn wir haben Jira meiner Meinung nach ineffektiv genutzt. Aber es war ein Versuch der Organisation. Er hatte zwei verschiedene Commits auf seinem persönlichen Computer ausgecheckt. Beide waren geschäftskritisch für die Veröffentlichung, die in zwei Wochen anstand, und er war auf halbem Weg bei beiden, also konnte er sie nicht zu GitHub pushen, und er ging für zwei Wochen in den Urlaub, und er war der Typ, der Gehaltserhöhungen bekam, wisst ihr, so etwas passiert. Das ist real. Das Verrückte daran ist für mich, dass das real ist. Ein CTO, der nicht programmieren kann, wird so beeindruckt sein, dass du eine riesige Gehaltserhöhung bekommst. Und damit kommen wir zum Geld-Flex. Der Typ im Büro neben ihm hat jedoch einen besseren Job bei der Gehaltsverhandlung gemacht und verdient 225.000 Dollar im Jahr. Mann, 225.000 als Junior-Entwickler wären erstaunlich. Wie, wenn du in dieser Position bist, dann baue jetzt dein Sparkonto auf. Genieße es, solange du kannst, denn das passiert normalerweise nicht lange. Offensichtlich, das ist irgendwie der Punkt. Das ist ein Witz, aber im Ernst, als Junior-Entwickler, wenn du, ich würde sagen, wenn du im Konzern bist und mehr als 80.000 verdienst, denke ich, hast du es gut. Du bist in einer guten Position. Jetzt kenne ich deine Lebenshaltungskosten und so weiter nicht, und es gibt all diese Dinge, Geld ist kompliziert, oder? Aber die Leute denken, dass Programmieren als Beruf viel höher bezahlt wird, als es im Durchschnitt der Fall ist, weil sie sich Dinge wie Google und Netflix ansehen und denken, das sei die Norm. Und selbst bei Google und Netflix ist es wahrscheinlich nicht ganz so hoch, wie man erwarten würde, besonders wenn man die Lebenshaltungskosten in der Nähe ihrer Einrichtungen und so weiter berücksichtigt, aber ich kenne Programmierer, die 40.000 Dollar im Jahr verdienen und nicht super neu sind. Viel davon ist, dass sie einfach den Job, bei dem sie sind, nicht verlassen haben, aber trotzdem gibt es viele davon. Und ich würde sagen, irgendwo zwischen 60.000 und 90.000, diese Spanne ist eher normal, denke ich. Jetzt kenne ich keine Durchschnittswerte oder Standardabweichungen. Das basiert nur auf dem, was ich gesehen habe. Also, deine Erfahrungen können variieren, aber ja, wenn du über 100.000 liegst, nimm es nicht für selbstverständlich. Du bist in einer sehr vorteilhaften Position, relativ gesehen. Und wenn du dein Geld richtig einsetzt, dann kannst du diese über 100.000 Dollar weit bringen. Es ist schwer, wenn man Studienkredite abbezahlt, natürlich. Ich erinnere mich daran. Aber wenn man sie schnell abbezahlt und sie nicht mehr da sind, macht das einen großen Unterschied. Aber das ist eine ganz andere Sache. Wenn ihr mehr Geldtipps wollt, fragt Dave Ramsey oder jemanden. 900.000 Dollar im Jahr verdienen. Das ist viel Geld. Oh, was ist das? Warte mal. Was sehe ich gerade? Äh, die 900.000 Dollar im Jahr. Ich habe noch nie jemanden getroffen, der 900.000 Dollar im Jahr verdient hat. Das ist die Primäragenda. Ich weiß nicht, ob er 900.000 Dollar im Jahr verdient hat oder nicht. Ich habe ihn nie sagen hören. Ich wäre wirklich überrascht, wenn ein Softwareentwickler, der nicht mindestens Architekt oder Principal Engineer ist, einer dieser schicken Titel, irgendwo in der Nähe so viel verdient. Denn wenn man bedenkt, dass viele CEOs vielleicht eine oder zwei Millionen im Jahr verdienen. Ich kann mir einfach nicht vorstellen, dass jemand 900.000 Dollar an einen Entwickler zahlt. Die Principal Engineers bei Home Depot, als ich dort gearbeitet habe, verdienten meines Wissens nach normalerweise etwa zwei oder drei K oder sorry, zwei oder 300k irgendwo in diesem Bereich, vielleicht bis zu 400K, aber sie waren 20 Jahre lang Programmierer und hatten sich hochgearbeitet. Also ja, wenn du neu in der Programmierung bist, erwarte nicht dieses Gehalt. Es ist extrem selten. Extrem selten, wenn es überhaupt passiert. Besonders jetzt, da unser Markt im Moment etwas überfüllt ist, weil jeder in den letzten 20 Jahren gesagt hat: "Oh, Programmieren ist ein einfacher, bequemer Schreibtischjob, bei dem man Millionen verdient, mit praktisch keiner Arbeit." Also gehen alle hinein und denken, es ist leicht verdientes Geld, was bedeutet, dass wir einen Überschuss an Entwicklern haben und wir sind jetzt Zahnräder in einer Maschine. Wir sind, wenn du ein Entwickler bist, kein besonderer, einzigartiger Arbeiter im Unternehmen. Du bist oft einer von Tausenden oder einer von Sieben, aber du bist super ersetzbar, es sei denn, du gehst über das Übliche hinaus und machst dich unersetzlich. Aber ja, erwarte keine 900.000 Dollar. Das ist eine App, damit ich zuhören kann. Wurde dieser Typ von YouTube gesponsert? Er wurde von YouTube gesponsert. Das ist verrückt, Mann. Gut für ihn. Mit dem Vim-Flex. Wenn du Vim benutzt, erhebt es dich auf eine höhere Bewusstseinsebene, von der aus du auf die armen verlorenen Seelen herabblicken kannst, die Werkzeuge wie VS Code, IntelliJ und Emacs benutzen. Das stimmt aber, Mann. Okay, also Vim ist eine ganze Sache. Wenn du im Netzwerkbereich, in der Netzwerktechnik tätig bist oder regelmäßig Docker-Container und ähnliches verwendest, startest du normalerweise mit Linux als Betriebssystem in irgendeiner Form. Und wenn du ständig dein Terminal benutzt, dann macht es Sinn, Vim zu lernen. Ich habe noch nie jemanden getroffen, der Emacs benutzt. Ich weiß, es ist eine große Debatte, aber jeder, den ich kenne, der hart genug ist, entweder Vim oder Emacs zu benutzen, benutzt Vim. Also, wenn du von Emacs weißt, lass es mich bitte wissen. Ich habe es noch nie benutzt. Ich habe gehört, es hat viele Tastenkombinationen und all solche Dinge. Aber ja, Vim ist wirklich kompliziert zu lernen. Ich habe ungefähr anderthalb Jahre lang nur in Vim gearbeitet, oder ich glaube, es war ungefähr ein Jahr. Ich hatte vorher schon mal in Vim herumgespielt, aber das war es auch schon. Und ich musste es für die Arbeit benutzen. Also habe ich es Tag für Tag benutzt. Am Ende eines Jahres war ich ungefähr okay in Vim, wo ich eine gute Muskelgedächtnis für die Bewegung, das Wechseln zwischen verschiedenen Modi und so weiter hatte. Aber es war wirklich lustig, denn für etwa ein oder zwei Wochen bin ich zu Visual Studio Code zurückgekehrt. Ich glaube, ich habe mit einem jüngeren Kollegen gearbeitet und er verstand Vim überhaupt nicht und ich habe ihn gerade an das Team gewöhnt und im Einführungsprozess war er auch ziemlich neu im Programmieren. Also haben wir ihn in Visual Studio Code angefangen und ich habe ihn durch den Prozess geführt und während dieser Zeit war es, als ob die mentale Anstrengung, die ich nicht aufbringen musste, um einfach nur Wörter auf den Bildschirm zu bekommen, wie eine riesige Last von mir genommen wurde. Vim ist so viel Arbeit und es ist cool und man kann erstaunliche Dinge tun und man kann flexen und wenn man sehen will, wie es toll ist, schaut einfach den Kanal von Primagen an. Aber ja, ich habe einfach das Gefühl, dass die kognitive Belastung, die man durch die Verwendung von Vim bekommt, bis man Vim vollständig beherrscht, es einfach nicht wert ist. Und es ist jetzt leicht, dieser Teil wird von Person zu Person stark variieren, manche Leute, es wird einfach klicken, andere Leute, es wird noch länger dauern, aber es dauert mindestens 6 Monate, um einigermaßen gut darin zu werden. Und dann nach einem Jahr bist du vielleicht ziemlich gut, aber es gibt immer noch Dinge, die schneller sind. Ja. Aber wieder die mentale Anstrengung, die man aufbringen muss, um einfache Dinge zu tun, bis man vollständig fließend ist, was leicht ein oder zwei Jahre dauern wird. Ich glaube einfach nicht, dass der Aufwand den Ertrag wert ist, mit der Ausnahme, dass es für deine Arbeit notwendig ist. Wie gesagt, wenn du Netzwerkzeug machst und ständig zwischen verschiedenen Docker-Containern wechselst und jeder Docker-Container Dateien hat, die du bearbeitest und so weiter, sehr üblich in Netzwerkszenarien oder verteilten Computing-Szenarien, Cloud-Server, all das Zeug. Wenn du diese Art von Arbeit machst, dann ist Vim irgendwie das Einzige, was Sinn macht, denn du willst nicht jedes Mal, wenn du es öffnest, Visual Studio Code oder so etwas in jedem einzelnen Docker-Container installieren. Und du kannst auch nicht immer einfach etwas in einem Texteditor öffnen, der kein Vim ist, denn Vim läuft in deinem Terminal. Also, das ist eine ganz andere Sache. Ich bin kein Netzwerkeexperte. Ich bin also nur tangential mit diesem Aspekt vertraut. Aber ja, persönlich, wenn du nicht im Bereich verteilte Cloud-Netzwerke arbeitest und dich nicht mit Docker-Containern oder vergleichbarem beschäftigst, ist meine persönliche Empfehlung, es sei denn, du findest es wirklich cool und willst es einfach lernen, weil es cool ist, bleib weg von Vim, denn das Verhältnis von Aufwand zu Ertrag ist meiner Meinung nach die anfängliche Investition nicht wert. Wenn du die gleiche Anstrengung investierst, um schneller mit anderen Dingen zu werden, wirst du einfach besser in diesen anderen Dingen, anstatt nur im Tippen. Ich denke, das ist eine gute Zusammenfassung meiner Meinung zu Vim: Wenn du es nicht speziell für deine Arbeit brauchst, was es natürlich ändert, dann lerne es ruhig, wenn es cool ist, natürlich, aber wenn du es nicht super cool findest und es für deine Arbeit nicht wirklich brauchst, ist es im Grunde Zeitverschwendung. Aber das ist wahrscheinlich, ich weiß nicht, wie scharf das sein wird. Fühlt euch frei, mir zu widersprechen. Wenn du Leuten sagen willst, dass du reich bist, nimm einen Macintosh. Nun, normalerweise stellt die Arbeit heutzutage den Laptop zur Verfügung. Es geht also eher darum, ob das Unternehmen dir schicke Ausrüstung geben will oder nicht. Wenn du auf einem Dell programmierst, dann hast du mein Mitgefühl. Um Leuten auch zu sagen, dass du ein Clown bist. Echte Entwickler benutzen aber Linux. Du kannst die meisten Leute beeindrucken, indem du einfach Ubuntu benutzt. Aber wenn du Leute wirklich beeindrucken willst, solltest du viel Geld an IBM zahlen, um Red Hat Enterprise Linux zu benutzen. Das ist ziemlich gewagt, aber irgendwann wirst du dich allein am Urinal wiederfinden. Ein Mann wird hereinkommen. Er wird den Kopf drehen und dich ansehen. Dann wird er diese drei Worte sagen. Ich benutze Arch, übrigens. Du wirst dich sofort kleiner fühlen, als ob dein Ding einfach nicht so gut entwickelt ist, wie du dachtest. Aber keine Sorge, du wirst gerade von jemandem geflext, der kein Leben hat und unzählige Stunden damit verbringen kann, sein Betriebssystem zu konfigurieren. Ja, das stimmt. Nun, wieder, es ist eines dieser Dinge, wenn du es gemeistert hast, dann cool. Benutze das, was du gemeistert hast, und flexe ruhig damit. Das ist in Ordnung. Sei kein Idiot, offensichtlich, aber du weißt schon, es ist in Ordnung, stolz auf Dinge zu sein, die schwer sind und die du erreicht hast. Aber ja, Arch, wie Vim, ist es wirklich nicht wert. Ich denke, die Leute, die am erfahrensten mit Arch und so weiter sind, sind meistens diejenigen, die vor 30 oder 40 Jahren angefangen haben, als es das Einzige gab, und was soll man machen? Aber heutzutage haben wir so viele Werkzeuge, die es einfacher machen und die Programmierung weniger zu einer Wissenschaft und mehr zu einer Kunst machen, worüber ich ein Video machen muss, denn das macht manche Leute anscheinend wirklich wütend. Aber Programmieren muss nicht mehr komplett wissenschaftlich sein. Und es entfernt sich meiner Meinung nach von der Wissenschaft und bewegt sich mehr in Richtung Kunst wegen moderner Werkzeuge. Und ich denke, das ist gut. Ich denke, das macht es für neue Leute viel einfacher, hineinzukommen und nicht einfach von Komplexität überwältigt zu werden. Aber das ist eine ganz andere Unterhaltung. Und dein Profil sollte genug Auszeichnungen und Abzeichen haben, um dich wie einen nordkoreanischen General aussehen zu lassen. Ernsthaft, ich wusste nicht einmal von den Abzeichen. Ich kümmere mich nicht um Abzeichen in irgendeinem der sozialen Medien, mit denen ich interagiert habe, die sie haben. Ich benutze GitHub überhaupt nicht als soziale Medien. Das ist aber urkomisch. Aber was du tust, ist, deine 8 Dollar zu bezahlen, um auf X, früher Twitter genannt, zu posten, dann machst du abgefahrene, heiße Takes, mit denen niemand auch nur im Entferntesten einverstanden sein kann. Das bringt mich zum Lachen. Ja, ich mag PHP nicht. Ich weiß, dass manche Leute es wirklich, wirklich mögen. Ich weiß, dass es sich seit meinem ersten Erlernen stark verbessert hat. Um fair zu sein, JavaScript ist auch ziemlich schrecklich. Vielleicht sollte ich eine Folge machen, in der ich PHP, die neue Version, lerne. Wenn du Ratschläge gibst, die so eklatant schlecht sind, bekommst du vielleicht sogar eine Antwort von Elon Musk selbst. Das ist wirklich verrückt, dass Elon Musk ihm geantwortet hat. Gut für ihn, Mann. Ich denke, das ist auch ziemlich wahr, mit der Ausnahme, dass Glück nicht von Alkohol kommt. Ich bestreite diesen Punkt entschieden. Ich habe noch nie jemanden gesehen, dessen Leben objektiv besser ist wegen Alkohol. Viele Leute denken das, aber dann ist das Endergebnis viel schlimmer und es ist sowieso nicht gut für dich. Also, das ist eine ganz andere Sache. Da gibt es Nuancen. Fühlt euch frei, mich in den Kommentaren anzuschreien, wenn ihr denkt, Alkohol sei der Sinn des Lebens. Ja, da ist viel Wahrheit dran. Das Interviewsystem in der Programmierwelt ist ziemlich lächerlich. Datenstrukturen und Algorithmen werden normalerweise als Test verwendet, um zu sehen, wie man mit komplexen Programmierthemen umgeht. Persönlich denke ich, dass der beste Weg, um herauszufinden, ob jemand mit dir zusammenarbeiten sollte, zumindest in der Programmierung. Ich kann nicht für andere Berufe sprechen. Ich denke, der beste Weg ist im Grunde eine Lehre, bei der es heißt: Du kannst grundlegende Tests machen, wie: Weißt du, wie man programmiert? Zeig mir den Prozess, wie du etwas programmierst. Ich denke, es ist nichts falsch daran. Aber dann im Grunde sagen: Okay, wenn du die Person magst und ihre Persönlichkeit so ist, dass sie das Team nicht ruiniert, zumindest soweit du das beurteilen kannst. Mach eine Lehre, bei der sie mit dir arbeiten, bezahlt werden, aber nicht so viel, vielleicht für einen Monat oder zwei. Eine Art Testphase, sieh, ob sie wirklich gut mit dem Team zusammenarbeiten und dann am Ende dieser Zeit, entweder sind sie eine tolle Ergänzung und du bist froh, sie im Team zu haben, also behältst du sie, oder sie sind eine schlechte Ergänzung. Dann sagst du ihnen einfach, dass sie nicht gut in diesem Team wachsen werden, dass sie nicht gut zusammenpassen und dass sie sich anderswo Arbeit suchen sollten. Und ich denke, man sollte ihnen das nicht einfach so aufdrücken, sondern erwarten, dass sie während dieser Zeit auch woanders Bewerbungen schreiben, denn es ist ein Test für euch beide, ob ihr zusammenarbeiten wollt. Ich denke, das wäre viel besser. Nun, das, was ich gerade beschrieben habe, braucht definitiv Verfeinerung und man müsste es für dein spezifisches Szenario und so weiter anpassen, aber ich denke, ein Lehrlingsmodell oder zumindest etwas, das einem Lehrlingsmodell ähnelt, wäre viel effektiver, um Programmierer zu finden, die zu deinem Team passen und gut mit deinem Team zusammenarbeiten können. Und ich habe es auch gut funktionieren sehen. Aber ich denke, niemand würde wirklich widersprechen. Vielleicht du, ich weiß es nicht, aber ich denke, niemand würde der Aussage widersprechen, dass das moderne Interviewsystem in der Programmierwelt, um neue Programmierer für die Arbeit zu finden, ziemlich schrecklich ist. Es funktioniert nicht wirklich gut. Es führt zu einer sehr hohen Fluktuationsrate. Es gibt Leute, die Jobs annehmen, die sie hassen, und dann gehen. Es gibt Leute, die Jobs annehmen, die sie hassen, und die sie dann rausschmeißen. Wisst ihr, es ist ein kaputtes System, und ich denke, etwas Neues auszuprobieren wäre wahrscheinlich gut. Nun, Leute werden auch jedes System brechen, das man ihnen gibt. Also, es ist nicht so, dass es perfekt wäre, aber für mich persönlich würde ich mich sicherlich mehr in Richtung einer Lehre neigen, anstatt mir deinen Lebenslauf zu geben und dann zu sehen, ob er die richtigen Schlüsselwörter enthält und dich dann 17 Mal zu interviewen und dann vielleicht eine Entscheidung zu treffen. Es ist ein schlechter Prozess. Lasst mich wissen, wenn ihr seltsame Stellen zum Anhalten wollt, aber lasst mich wissen, wenn ihr ein Video sehen wollt, das mehr darüber spricht. Ich denke, es ist ein sehr relevantes Thema in der heutigen Gesellschaft als Ganzes, aber auch in der heutigen Tech-Community, mit den Entlassungen, die wir in den letzten Jahren hatten, mit der Art und Weise, wie sich die Tech-Branche gerade entwickelt. Ja, lasst mich wissen, ob ihr an so etwas interessiert seid. Der ultimative Flex, den ein Programmierer haben kann, ist jedoch, das Bauernhofhandwerk zu lernen. Der Programmierer, der seinen Computer in die Luft jagt und zu den Amish geht, ist unverwundbar für all die Flexes, die wir in diesem Video betrachtet haben. Während er seine Kuh melkt und seine Felder bestellt, ist seine Identität nicht mehr an diese oberflächlichen Dinge gebunden. Oh, das war gut. Ich hoffe, es hat euch gefallen. Ich hoffe, ich habe einige nützliche Kommentare gegeben. Lasst mich wissen, was ihr in den Kommentaren unten denkt, ob ihr zustimmt oder nicht. Wenn ihr hasst, was ich gesagt habe, ist das in Ordnung. Ich hasse euch nicht. Ich denke, ihr seid, ich weiß nicht, ob ihr wunderbare Menschen seid, aber ich denke, ihr seid wertvolle Menschen, und ich hoffe, euer Leben ist großartig oder wird zumindest besser. Aber das war ein Exkurs. Ja, danke, dass ihr bis hierher zugeschaut habt. Wenn ihr noch hier seid, wow, ihr seid cool. YouTube denkt, ihr würdet auch einige dieser Videos mögen. Versucht es vielleicht mal. Und vergesst nicht zu liken, zu abonnieren und all das Zeug. Lasst mich in den Kommentaren wissen, ob es Themen gibt, die ihr gerne weiter erforschen würdet. Und ich tue mein Bestes, um auf alle Kommentare zu antworten, also bin ich nicht immer der Schnellste, aber ich überprüfe es und sehe, was ihr sagt. Also, ich hoffe, ihr habt einen schönen Tag und äh, tschüss. Ich schätze, ja, wir sehen uns später.