Working Draft

Wöchentlicher News-Podcast für Webdesigner und -entwickler

Unterstützung

Wir optimieren unser Audio mit Auphonic, wo ihr uns Processing-Time kaufen könnt! Alternativ findet Ihr uns auch auf Patreon:

Become a Patron!

Werben bei Working Draft!

Mit zehnjähriger Geschichte und über 5000 Downloads pro Folge ist Working Draft der etablierteste Podcast für Webentwickler im deutschsprachigen Raum. Wenn ihr neue Entwicklerkollegen sucht oder ein Produkt für Webentwickler anbietet, schreibt uns unter sponsoring@workingdraft.de.

Revision 485: ES2021 & Beyond

13. Juli 2021 | 2 Kommentare

Anlässlich der offiziellen Verkündung von ECMAScript 2021 fanden sich Hans, Schepp und Peter zusammen, um nicht nur die Feature-Liste des neuesten JavaScript-Standards zu rekapitulieren, sondern dabei auch etwas in Zukunft und Vergangenheit von ECMAScript zu blicken.

Schaunotizen

[00:00:29] Habemus ES2021
Wir scheitern in gewohnter Manier daran, die Feature-Liste von ECMAScript ohne allzugroße Abschweifer durchzugehen. Vorweg: der Browsersupport ist gar nicht schlecht! Zum neuen String.prototype.replaceAll() haben wir nur zu ergänzen, dass es genau wie String.prototype.replace() eine Falle enthält, in die zumindest Peter schon mal getappt ist. Die besprechung der neuen Logical Assignment Operators führt uns zu den fehlenden throw-Expressions (die Peter in seiner Toolsammlung durch eine fail()-Funktion halbgar ersetzt). Numeric Separators nehmen wir einfach zur Kenntnis, während Promise.any() zu einer länglichen Debatte rund um das Wesen von Promises und Observables (eingeschlafenes Proposal, lebendige Implementierung RxJS) führt. Klassen haben mehr private-Features (in Firefox originell implementiert) und die neuen Memory-Manangement-Helper WeakRef und FinalizationRegistry werden die meisten Entwickler:innen sehr selten brauchen. Zum Abschluss wünscht sich Peter noch do-Expressions in gut (d.h. nicht wie im Proposal) sowie tmp-Variablen.

Revision 484: CSS Tücken und Tooling

7. Juli 2021 | 2 Kommentare

Schepp und Peter erfreuten sich in dieser Revision an der Anwesenheit von Martin Donath (Twitter, Github), der nicht nur Maintainer von Material for MkDocs ist, sondern auch daran arbeitet, mit Stylezen das beste CSS-Intellisense diesseits der Baikal-Amur-Magistrale zu erschaffen.

Schaunotizen

[00:00:59] CSS Tücken und Tooling
In einem exzentrischen Orbit kreisen wir um das Thema Tools für CSS und die mit diesen Tools und/oder CSS einhergehenden Herausforderungen. Das Tool-Thema enthält neben Prä/Postprozessoren wie PostCSS, Less und Sass auch Konzepte wie BEM/ITCSS/OOCSS, konkrete Frameworks a la Tailwind und Addons wie CSS Modules. Diesen Erstellungs-Tools gegenüber stehen Analyse- und QA-Ansätze wie Visual Regression Testing (mit Varianten wie Warhol und SiteEffect) und relativ simplen Lintern. Martins Stylezen ist da etwas anders: aufbauend auf der Idee, dass CSS eigentlich eine statisch typisierte Sprache istund inspriert von Adam Argyle, wird Stylezen eine Art TypeScript für CSS (Stylezen-Extension für VS Code in Aktion). Am Rande geht es außerdem um Custom Properties, Container Queries, CSS Containment, warum niemand CSS ernst nimmt, die kognitive Komplexität von CSS, Web Components (v.a. Revision 480), Shadow DOM, Scoped CSS, Cloud Flare Workers, csstype, die absurde Komplexität von CSS Grid, Mootools und die Freuden der Webstandards-Spezifikations-Exegese.

Revision 483: Safari 15 und Browser-Extensions aller Art

29. Juni 2021 | 5 Kommentare

Hans, Vanessa, Peter und Schepp trafen sich unter dem Vorwand, die „Neuerungen“ von Safari 15 zu diskutieren, kamen dabei aber über Umwege auch auf Browser Extensions sowie das Pro und Contra von Bookmarks zu sprechen

Schaunotizen

[00:01:01] Safari 15
Die Jünger des heiligen Steve haben anlässlich der letzten WWDC (Video) eine neue neue Safari-Version in Petto. Enthalten sind null PWA-Features, diverse UI-Updates (v.A. Tab Groups), Unterstützug für <meta name="theme-color"> (was wir hinsichtlich der Browserunterstützung und des Dark-Pattern-Patenzials gründlich besprechen) und aspect-ratio für Iframes – ein Hack weniger!
[00:00:00] Bookmarks und Browser-Synchronisierung
In einem kurzen Exkurs predigt Hans mit Verve die Vorzüge vereinheitlichter Browser-Synchronisierung, speziell für Bookmarks. Peter vetritt halbherzig das Team Hirnsieb. Als Tools für Bookmarking und Wissens-Orga empfehlen wir Chrome und seine Einbauten (Hans) Pocket (Schepp) Abyss (Vanessa) und Obsidian (Peter).
[00:00:00] Browser-Extensions und Webseiten-Eingriffe
Außerdem neu in Safari: Unterstützung für Web Extensions, (fast) ganz wie in Chrome und Firefox! Anlässlich dessen berichtet Schepp von seinen Erfahrungen mit Chrome-Extensions-Entwicklung und schimpft besonders auf die extrem nutzlose Dokumentation. Über Extensions kommen wir zum Über-Thema „Elemente, die in Webseiten eingreifen“ (Extensions wie Grammarly, PW-Manager), die zusammen mit der allgemeinen Komplexitätszunahme (Responsive Design, Dark/Light Mode, bizarren Bugs auf allen Ebenen Entwickler:innen in den Wahnsinn treiben. Kann man dem Wahnsinn mit Tools wie Sentry, Sizzy und Polypane begegnen, oder sollten wir alle doch lieber was mit Holz machen? Hans hat die ultimative Antwort auf diese Frage …

Keine Schaunotizen

DOM Treemap
Schepps in der Revision angesprochene Browser-Erweiterung, mit der man in die Tiefen seines DOM Baums auf der Suche nach den verloren DOM-Knoten hinabsteigen kann. Gibt es für Chrome und für Firefox.

Revision 482: Angular im Jahr 2021

22. Juni 2021 | 3 Kommentare

Nachdem es schon wieder zweieinhalb Jahre her ist, dass wir unseren letzten Blick auf Angular geworfen haben, luden wir uns Martina Kraus ein, um uns wieder auf Stand zu bringen.

Martina twittert als @martinakraus11, ist selbstständige Beraterin, Trainerin und Sprecherin zum Thema Angular, und das nicht erst seit gestern. Zudem organisiert sie zahlreichen Meetups in der Heidelberger Region. Aufgrund dieser zahlreichen Aktivitäten ist sie mittlerweile zur Google Developer Expert (GDE) für Angular avanciert und tauscht sich dementsprechend viel mit dem Angular Core-Team zu Wünschen aus der Community und neuen Entwicklungen des Frameworks aus.

Schaunotizen

[00:01:00] Angular im Jahr 2021
Die aktuell neuste Version des Frameworks ist die Version 12, die mittlerweile voll auf den Compiler „Ivy“ setzt, welcher in unserer letzten Folge vor zweieinhalb Jahren noch Zukunftsmusik war. Einer der ganz großen Vorteile von Ivy ist, dass der erzeugte Code im Gegensatz zu früher getreeshaked werden kann, was Angular-Anwendungen, die nicht von Angular bereitgestellten Features nutzen, deutlich kleiner werden lässt.

Außerdem beschreitet das Framework einen interessanten neuen Pfad, nämlich indem es zunehmend auf TypeScript zugunsten von ES 2017 verzichtet. Das kommt insofern unerwartet, als dass Angular bei seiner Einführung 2016 als erstes JavaScript-Framework überhaupt voll auf TypeScript gesetzt hat und die anderen beiden großen Frameworks jetzt erst bei Angulars Level an TypeScript-Unterstützung angekommen sind. Auf Typinferenz muss dabei niemand verzichten, denn Angular 12 setzt auf einen neuen Modus namens „Strict“, der von der Autorin erwartet, dass alle Variablen, die an einem Template hängen, initialisiert werden müssen. Und dadurch ist dann von Anfang an klar, um was für einen Datentyp es sich handelt. Wir sind gespannt, ob andere Frameworks hier nachziehen werden.

Nach wie vor bereitet der Umstieg vom alten Compiler auf Ivy allerdings hier und da noch Probleme, weil nämlich Angular-Libraries für beide Compiler adaptiert werden müssen. Hier gibt es aber Schützenhilfe von Tools wie dem Angular Compatibility Compiler (ngcc) – und auch Martina hat dazu dankenswerterweise einen Talk auf Lager. Zudem hat Ivy noch ein paar eher halb-offizielle Features wie Higher Order Components oder Custom Change Detection, die in Zukunft ausgereiftere Interfaces benötigen. Auch dazu hat Martina einen Talk parat!

Eine weitere wichtige Neuerung von Angular 12 ist dass es mit Webpack 5 daherkommt. Dieses erleichtert vor allem das Orchestrieren von in Angular gebauten Micro-Frontends, was so vormals nur mit der Microfrontend-Library von Manfred Steyer möglich war (siehe dazu auch den Talk vom ihm).

Wer nach dem Hören unserer Folge Lust auf Angular bekommen hat, dem empfiehlt Martina den Einstieg über das Angular-eigene Einsteiger-Toturial „Tour of Heroes„, oder aber die Tutorials von Maximilian Schwarzmüller, aka Academind.

Geht es hingegen darum, Feedback los zu werden, dann schickt eine Mail an devrel@angular.io, oder wendet Euch an die DevRel Emma Twersky, oder geht den Weg über eine*n GDE wie Martina.

Revision 481: Multithreading, Web Worker, Shared Worker und Multi-Screen-Applications mit Tobias Uhlig

15. Juni 2021 | Keine Kommentare

Rod und Peter hatten Tobias Uhlig zu Gast, der als federführende Kraft hinter dem Framework neo.mjs einiges zu Multithreading in Webapps zu erzählen weiß.

Schaunotizen

[00:01:00] Worker, Tiere, Sensationen!
Nach den üblichen Vergleichen von Tobias‘ neo.mjs mit Angular und co geht es umgehend an’s Eingemachte. Wie quatschen nicht nur über Dedicated Worker, Shared Worker und Service Worker (nebst Worker DOM), sondern auch über Message Channels bzw. Message Ports (und ihre Transferierbarkeit) und Asynchronität im Allgemeinen. Anhand von neo.mjs kauen wir Fragen von Remote Method Access, handgedengeltem VDOM und abgestuftem TypeScript-Support in modernen Tools durch. Auch über die im Jahre 2021 ggf. noch verbleibende Relevanz von Drag & Drop und Multi-Window-Apps denken wir laut nach und verweisen gegen Ende auf Tobias‘ Covid-Dashboard als eine neo.mjs-Demo.

Revision 480: Web Component Design mit Joy Heron

8. Juni 2021 | Keine Kommentare

Fullstack-Entwicklerin, CSS-Feinschmeckerin und Webstandards-Liebhaberin Joy Heron (Twitter, Webseite, Case-Podcast) fand sich im virtuellen Workingdraft-Studio ein, um mit Schepp, Peter und Vanessa über Web Components zu fachsimpeln.

Schaunotizen

[00:01:36] Web Components und Web Component Design
Wir beginnen damit, die Unterschiede zwischen Web Components und Framework-Komponenten herauszuarbeiten und bequatschen dabei mit Custom Elements, Shadow DOM und dem template-Element die wesentlichen Bestandteile von Web Components. Wir besprechen Accessibility-Fragen, wägen HTML-Seiten gegen SPAs ab (relevant: Removing client-side React.js (but keeping it on the server) resulted in a 50% performance improvement on our landing page) und besprechen das Für und Wider von Polyfills für Web Components. Ergebnis: gutes Web-Component-Design braucht keine Polyfills (aber wenn, dann sollte es ein leichtgewichtiger Polyfill sein). Außerdem kommen zukünftige (Deklaratives Shadow DOM) und verflossene (HTML Imports) APIs rund um Web Components zu Sprache. Über die Frage des Einsatzspektrums und denkbarer Alternativen zu sowohl Web Components als auch fetten Frameworks (hyperHTML, µland) kommen wir zu der Frage, welche Wert das Wissen um Webstandards-Basics (mit Event.preventDefault() als Beispiel) heutzutage überhaupt hat. Gegen Ende verweisen wir noch auf die MDN-Doku zu Web Components, Joy’s Talk Web Components: Maintaining and Reusing your Frontend, Brad Frost’s Artikel zu front-of-the-front-end and back-of-the-front-end web development und Joy’s Kompendium Responsible Web Applications. Zudem stellt Peter für frühstens 2027 einen Blogpost über OOP-DOM mit Elementen in Aussicht.

Revision 479: Late-Night mit Feedback Culture, Basecamp, Design Sprints

1. Juni 2021 | Keine Kommentare

Eine weitere Late Night Ausgabe mit Kahlil und Stefan im Überleitungsmarathon!

Schaunotizen

[00:00:59] Changes at Basecamp
Nachdem die Menschen von Basecamp in den Late Night Episoden regelmäßig auftauchen müssen wir natürlich kurz über den Mitarbeiter-Exodus und die vorangegangene Kommunikation reden. In einem zusätzlichen Artikel gibt es mehr Information. Wir sind erstaunlicherweise anderer Meinung!
10/50/99% Feedback
Apropos Feedback! Machen Sie das Logo doch bitte größer, morgen gehen wir live! Damit solche Dinge nicht passieren bietet es sich an das richtige Feedback zur richtigen Zeit zu geben. Der Artikel veranschaulicht das sehr gut und wir reden über unsere Erfahrungen. Stefan schwört auf die Technik der Design Sprints um schnell Meter zu machen.
Web Components at GitHub
GitHub verwendet schon lange Web Components und berichtet. Das Catalyst Toolkit hilft GitHub Entwickler:innen dabei, schneller und einfacher ans Ziel zu kommen. Wir sind immer noch skeptisch ob Web Components, jetzt wo sie wirklich da sind, tatsächlich als Allheilmittel durchgehen. Irgendwo mittendrin erwähnt Stefan auch noch Proxies, und wir kommen wieder ganz vorne an.

Revision 478: Abschweifen mit TypeScript 4.3

26. Mai 2021 | Keine Kommentare

Unter dem Vorwand, eine neue TypeScript-Version zu besprechen, trafen sich Stefan und Peter und quatschten in Wahrheit über Delphi, Balkonpflanzen, Rust, Napoleon, Go(tt) und die Welt.

[00:00:58] Schaunotizen

Announcing TypeScript 4.3 RC
Es steht eine neue TypeScript-Version vor der Tür, die wir Feature für Feature durchkauen und dabei immer wieder bis zum Mond abschweifen. Der Umstand, dass ConstructorParameters<Type> nun auch für abstract Classes funktioniert, führt uns direkt ins traditionelle OOP-Roasting. Dabei erwähnen wir nicht nur Stefans Artikel zum Constructor Interface Pattern, sondern auch Fehlleistungen aus dem Hause Bloomberg.com. Über den Wert der Always-Truthy Promise Checks sind wir uns ebenso uneinig wie über die diversen Upgrades des TS-Compilers, nutzen letzteres Thema jedoch zum Abschweifen in Richtung Bazel, esbuild, Go (und den legendären Generics-Hack) und Rust. Neue Editor-Features von TS lassen uns über die Beziehung zwischen TypeScript und VS Code philosophieren, bevor es an die ersten Neuerungen von TS 4.3 geht, die uns wirklich interessieren. Tweaks am den Typen von Gettern und Settern sind nicht die Weltformel, aber gerade für Web Components schon ein sinnvolles Feature. Unabhängig davon fordert Peter einen Rust-artigen unsafe-Block für TS, damit Löcher im Typsystem besser behandelt werden können). Der Klassenkampf setzt sich mit override nebst --noImplicitOverride sowie #private (jetzt auch für Methoden) fort, was wir auf sehr zurückhaltende Weise begrüßen. Contextual Narrowing for Generics (eine selektive Aufschlauung der Typsystems) und Template String Type Improvements (eine weitere selektive Aufschlauung der Typsystems) sagt uns da schon mehr zu. Gegen Ende verfransen wir uns dann mit einen Proposal für do-Expressions, Napoleons Rückzug aus Moskau, ReasonML/ReScript, Delphi, GTK und Empfehlungen für die Revionen 446 und 175 dann vollends.

Revision 477: Komponentenbibliotheken und Design Systeme

18. Mai 2021 | Keine Kommentare

Mit Fabian Friedl, DesignOps Team Lead bei Dynatrace, sprechen Vanessa, Hans und Stefan über Komponentenbibliotheken und Design Systeme.

Schaunotizen

[00:00:00] Komponentenbibliotheken und Design Systeme
Bevor ins Detail eingestiegen wird, erklärt Fabian erst einmal was eine Komponentenbibliothek überhaupt ist. Ein Hauptziel von Komponentenbibliotheken ist es, Konsistenz zwischen mehreren Applikation herzustellen. Darüberhinaus können sie allerdings auch Mehraufwand deutlich minimieren. So muss beispielsweise bei einem Redesign oder bei einer Erweiterung nicht jedes Featureteam die Änderung umsetzen. Stattdessen kommen Änderungen vom Team der Komponentenbibliothek. Die Basis von Komponentenbibliotheken sind Design Systeme. Als i-Tüpfelchen können Designer:innen und Entwickler:innen Design Tokens verwenden. Design Tokens geben atomic Styles an, die für verschiedene Plattformen, wie iOS, Android oder als Custom Properties für Web, exportiert werden können. Selbstverständlich kann es auch Nachteile geben. Doch diese lassen sich durch Organisation umgehen. Fabians Team arbeitet eng mit dem Designteam zusammen, eigentlich sind sie eher ein Team. Es gibt wöchentliche Designreviews, die für einen frühen Austausch sorgen. Eine wichtige Frage, die sich dann beim Entwickeln stellt ist: Wer ist der Konsument? Ist es ein komplettes Open Source Projekt, wie viele Feature Teams greifen auf die Bibliothek zu? Unabhängig davon, jeder Konsument der Bibliothek wird eine gute Dokumentation benötigen. Noch besser sind sogar Copy & Paste Snippets zum Ausprobieren. Je besser die Dokumentation ist, desto mehr erspart man sich Nachrichten über Chatsysteme mit immer den gleiche Fragen. Weiteres Material in den Links

Links

Angular CDK
Stilfreier Grundbaukasten für barrierefreie Angular Komponenten
Calender Kit
Schon mal ein Kalender-Widget gebaut? Hier gibt’s kopflose Unterstützung.
React-aria
React Hooks von Adobe zur Erstellung barrierefreier Komponenten. Sehr qualitativ!
Headless UI
Headless Components von den Tailwind Machern in React und Vue
Reach
Stilfreie, barrierefreie React Komponenten
Polaris
Das Shopify Design System
Barista
Das Dynatrace Design System
Learnings from building a component Library
Fabians Vortrag auf der NG-DE

Revision 476: Recruiting und Karriere

11. Mai 2021 | 4 Kommentare

Anlässlich der Tatsache, dass Vanessa gerade mit Mitarbeiter*innen-Suche beschäftigt ist, sprachen wir über das Thema „Recruiting und Karriere“.

Schaunotizen

[00:01:00] Recruiting und Karriere
Wie ihr vielleicht wisst, arbeitet Vanessa in einem kleinen Startup, dessen Entwicklungsabteilung wachsen soll. Vanessa fiel dabei die Aufgabe zu, neue Menschen zu casten. Alle potentiellen Kandidaten landen zunächst einmal in einer Tabelle des Tools Notion. Alle infrage kommenden Kandidaten bittet Vanessa, ob sie auf ein GutHub-Repo oder auf einen GitHub-Commit verweisen können, auf den sie besonders Stolz sind. Das hilft Ihr, ein Gefühl für die Kandidatin oder den Kandidaten zu bekommen. Wer die Hürde nimmt, den erwartet eine Coding Challenge, welche auf 6 Stunden getimeboxed ist. Das ganze stellt immer eine Art Aufgabe dar, wie Vanessa sie jeden Tag umsetzen muss. Meist ist die Aufgabe umfangreicher als dass man sie in den 6 Stunden schaffen könnte. Vanessa interessiert, ob generell etwas Lauffähiges herauskommt, welche Entscheidungen die Person getroffen hat und wie ihr Coding-Stil ausschaut. Da die Challenge via GitHub bereitgestellt wird, sieht sie nebenbei auch, wie die Kandidatin oder der Kandidat mit Git umgeht. Nach Abschluss der Aufgabe führt Vanessa ein 90 min. technisches Interview. Dieses dient einem beiderseitig noch besseren Kennenlernen, und dem Bantworten von Fragen. Vanessa freut sich hierbei besonders über Verbesserungsideen was Technik oder UX angeht der Aufgabe angeht. Code-Fehler in der Coding Challenge werden jedenfalls verziehen, wenn es menschlich passt! Das letzte Interview schließlich ist der das, in dem es um Gehaltsvorstellungen geht.

Hans, der in einem größeren Unternehmen arbeitet, legt wiederum mehr Wert auf einen solchen „Cultural Fit“, als auf den Coding Stil. Seiner Meinung nach ist das Knowhow etwas, das man den Personen beibiegen kann. Dieses „Zusammenpassen“ muss man von beiden Seiten gesehen, auch wichtig dass die Firma zu der Person passt. Zum Zusammenpassen gehört auch die Frage, würden die Person das Unternehmen hin und wieder in München besuchen, oder käme das nicht infrage? Darüberhinaus soll die Kandidatin oder der Kandidat Lust auf Neues haben und Dinge anschieben wollen. Hans` Meinung nach gibt es nämlich sehr viele Menschen, die die Dinge gerne so belassen wollen, wie sie sind. Die wären allerdings weniger für das Unternehmen geeignet, für das er arbeitet. Darum hat Hans den Recruitment-Prozess umgedreht: Als allererstes versucht Hans mit einer Kollegin oder einem Kollegen zusammen in einem 30- bis 45-minütigen Gespräch herauszufinden, ob beide Seiten zusammenpassen. So merkt man schnell, wenn es nicht passt und beide Seiten haben keinen zu großen Zeit-Invest vorab tätigen müssen. Erst danach folgt der fachliche Test in Form einer Reihe technischer Fragen und Challenges, für welche Hans das Tool Codility nutzt, das auf 60 Minuten Zeit begrenzt ist. Danach folgt das technische Interview. Hier ist für Hans wichtig, was die Person über bestimmte Konzepte denkt, wie z.B. Lifecycle Hooks. Für ihn ist vor allem interessant, wie die Leute antworten, nicht so sehr der Inhalt selbst. So ist es auch okay, wenn jemand etwas nicht weiß. Es geht ihm darum, mit der Kandidatin oder dem Kandidaten ins Gespräch kommen und Lust auf eine zukünftige Zusammenarbeit zu bekommen.

Im Verlauf unseres Gesprächs kommen wir auch auf das Thema „Freelancer“ zu sprechen. Vanessa findet Freelancer schwierig, weil die meist nicht die ganzen Hürden überwinden müssen, die die Festangestellten nehmen mussten, und auch, weil sie mehr verdienen. Der Punkt wiederum führt uns zum nächsten Thema „Verdienstmöglichkeiten“: Vanessa findet, es sollen alle möglichst gleich und angemessen verdienen. Bei Hans im Unternehmen gibt es für verschiedene Tätigkeiten vordefinierte Gehaltskorridore. Dadurch sind die Gehälter recht homogen. Zumindest vermutet er das, denn in seinem Arbeitsvertrag steht die Klausel, dass Angestellte nicht über ihr Gehalt sprechen dürfen. Hier wirft Schepp ein, dass so eine Klausel überhaupt nicht zulässig ist und er der Meinung ist, dass das nur ein Werkzeug ist, mit dem ein Arbeitgeber seine Belegschaft klein hält. Zum Thema „Verdienst als Freelancer“ schildert er seine Beobachtung, dass man zu jedem Stundensatz seine passenden Kunden findet und dass gerade die Kunden, die mit hohen Stundensätzen kein Problem haben auch immer zügig bezahlen. Schepp weist auch darauf hin, dass die Summen, die Freelancer fordern, die Nachteile ausgleichen, die sie gegenüber Festangestellten haben: Sie können jederzeit aus den Diensten entlassen werden, sie müssen bei der Sozialversicherung den Arbeitgeberanteil mittragen, sie werden bei Krankheit nicht weiterbezahlt und jeder Urlaub kostet Freelancer doppelt Geld: In Form von tatsächlichen Urlaubskosten, plus dem Verdienstausfall. Hier pflichtet Vanessa bei, dass sie Freelancer kennt, die deswegen, und aus Reputationsgründen, über Jahre hinweg keinen Urlaub gemacht haben. Im Bereich der Festanstellung findet Hans, dass Senior Engineers in Deutschland zwar gut, aber nicht sensationell gut verdienen, und dass die größten Gehaltssprünge meist mit Arbeitgeberwechsel einhergehen. Als Weiterentwicklung der Karriere bleibt Engineers meist nur der Weg ins Management. Die Seite www.engineeringladders.com gibt Ratschläge für die Karriere.

Eine erfreuliche Beobachtung, die Hans in den letzten Jahren gemacht hat, ist dass die Bewerber immer diverser und facettenreicher werden. Das findet Hans richtig gut! Vanessa meint, das komme aber noch stark auf die Firma an, bei der man ist.

Zu guter Letzt sind wir uns auch alle einig, dass uns sogenannte „Perks“, also Dinge wie Kickertisch, Obstkorb & Co eigentlich nicht so wichtig sind. Sie sind zwar angenehm, aber nicht entscheidend.

Keine Schaunotizen

Revision 440: Engineering Manager und andere Karrierepfade
Vor knapp einem halben Jahr haben sich auch schon Kahlil und Stefan über das Thema „Karriere“ unterhalten. Falls Ihr die Folge noch nicht kennt: Es lohnt sich reinzuhören!
git rerere
Die Funktion git rerere steht für „reuse recorded resolution“. Was es damit auf sich hat, lest Ihr hier.