Steile These

Doch bevor es ins Eingemachte geht, möchte ich erstmal eine These aufstellen: Ich glaube nämlich, ihr habt schon in so vielen Stellenanzeigen (oder Headhunter-Anfragen) von dem „netten und motivierten Team“, mit seinen „tollen Mitgestaltungsmöglichkeiten“, der „Kaffeeflatrate“ und der „mega Familienfreundlichkeit“ bei „super flexibler Arbeitszeit“ und natürlich „total spannenden Projekten“ gelesen, dass euch das nur noch anödet. Hat es eigentlich jemals irgendwen überrascht, dass da nirgendwo steht: „Arbeite in einem Team voller sozialphober Psychopathen an saudrögen Projekten in einem mittelcharmanten Bürogebäude mit schlechter Parksituation und häufigen Überstunden“? Nein? Eben!

Das Problem ist, jedes Mal, wenn ich versuche eine Stellenanzeige für uns zu erfinden, erwische ich mich dabei, wie ich die selben Floskeln zu Papier bringen will und mich darüber ärgere, dass sich das so doof anfühlt, obwohl ich gleichzeitig nunmal finde, dass das bei uns halt nun einmal keine Floskeln sind. Was nicht heißen soll, dass hier ausschließlich, alles immer Tutti-Frutti ist – aber es ist halt auch einfach echt viel echt gut. Schauen wir uns das doch mal im Detail an:

Mitgestaltungsmöglichkeit

Vielleicht ist es untypisch, mit diesem Aspekt einzusteigen, anstatt euch zu erzählen, wie technisch kompetent wir sind – aber dass wir nach 20 Jahren Firmengeschichte nicht total unfähig sind, was unser Fachgebiet angeht, könnt ihr uns an der Stelle vielleicht einfach mal glauben. Viel spannender finde ich aber eben sämtliche „Rahmenbedingungen“, die bei uns so herrschen und die uns meiner Ansicht nach von vielen anderen unterscheiden.

Es gibt irgendwie keine Tabuthemen.

Das Thema „Mitgestaltungsmöglichkeiten“ empfinde ich da für den „wf-spirit“ als ganz zentral. Bei uns kann man nämlich tatsächlich eigentlich alles mitgestalten, was man möchte – oder um es mit den Worten eines Kollegen zu sagen: „Es gibt irgendwie keine Tabuthemen.“ Die webfactory möchte ein Ort sein, an dem Menschen zufrieden und glücklich sind und das lebt sie nicht nur auf dem Papier aus. Es ist nun jedem selbst überlassen, ein Herzensthema aufzumachen bzw. bei einem bereits existierenden Thema „mitzumischen“ und das kann alles mögliche sein: Von technischen Fragestellungen ("Wie können wir unsere Tests verbessern?") über grundlegende Firmenprinzipien ("Wer bekommt wieviel Gehalt und wie entscheiden wir darüber?"), räumlichen Gegebenheiten ("Welche Farbe sollen die Rollos im Wintergarten bekommen?") bis hin zu ganz individuellen Wünschen ("Darf ich einen Hund mit zur Arbeit bringen?") – mir fällt wirklich kein Thema ein, das Tabu wäre, oder grundsätzlich hierarchisch „von oben“ entschieden werden würde. Schreib dir doch einfach mal auf, wie dein ideales Berufsumfeld aussähe oder was du dir alles von deinem Arbeitsplatz wünschen würdest und jetzt stell dir vor, du könntest wirklich versuchen all das zu realisieren. Vielleicht klappt nicht alles immer sofort und auf einmal – auf manche Ziele muss man sicherlich erst hinarbeiten – aber die webfactory versucht immer, alles irgendwie möglich zu machen. Toll, oder?

Handlungsfreiheit und Vertrauen

Gehört ein bisschen zum vorangegangenen Abschnitt dazu, verdient aber eine extra Erwähnung, wie ich finde. Die webfactory möchte nämlich auch ein Arbeitsplatz sein, an dem man vertrauensvoll miteinander umgeht und das geht sogar soweit, dass wir Mitarbeiter*innen frei über die Firmengelder verfügen können. In der Praxis bedeutet das: Grundsätzlich kann jede*r entscheiden, was auf Firmenkosten gekauft werden soll und wir haben vollen Zugriff auf die Kreditkarte, den Paypal-Account und Co. Wenn ich ein neues Buch kaufen möchte, ein tolles Küchengerät oder wenn ich eine Konferenz buchen will (oder zwei oder drei im Jahr…), dann kann ich das einfach tun und muss vorher niemanden um Erlaubnis fragen. Die Regel besagt lediglich, dass man sich selbst überlegen soll, eine andere Person hinzuzuziehen, wenn man das Gefühl hat, dass die geplante Anschaffung so teuer ist, dass man sich alleine mit einer Entscheidung unwohl fühlt. Natürlich funktioniert das Prinzip nur solange, wie wir auch alle verantwortungsbewusst mit dieser Freiheit umgehen – bisher haben wir aber nur positive Erfahrungen damit gemacht. 

Familienfreundlichkeit

Die webfactory ist nicht das erste Arbeitsumfeld, in dem ich mich persönlich bewege und natürlich habe ich mich schon oft mit Freunden aus den unterschiedlichsten Branchen über das Familienthema unterhalten. Ich habe schon selbst beobachtet, wie Verträge schwangerer Frauen rein zufällig nicht mehr verlängert wurden, oder Geschichten darüber gehört, was anderen von ihren Chefs so an den Kopf geknallt wird, wenn sie es wagen, Nachwuchs in die Welt zu setzen. Bei uns hier in der webfactory wiederum waren die beiden (männlichen) Chefs tatsächlich lange Zeit die einzigen mit Nachwuchs und entsprechend auch die einzigen, die aufgrund der Kinderbetreuungsthematik ihre Arbeitszeit reduziert (und ja: dabei auch auf Gehalt verzichtet) haben. Allein das fand ich schon immer bemerkenswert, denn der klassische (männliche) Chef, den man so vor seinem geistigen Auge hat, würde doch niemals weniger als Vollzeit (plus Überstunden, meine ich) arbeiten. Wenn ich also sage, dass die Chefs ihre Arbeitszeit reduziert haben, meine ich damit nicht etwa „von 60 auf 55 Stunden“, sondern eben irgendwo unterhalb ihrer vorherigen Vollzeitstelle. Letztes Jahr ist nun zum ersten Mal ein Mitarbeiter Vater geworden und die Firma hat es ihm sofort problemlos möglich gemacht, seine Arbeitszeit für ein volles Jahr von fünf auf zwei Tage die Woche zu reduzieren. Es ist bei uns auch ganz selbstverständlich, dass jemand früh nach Hause geht, oder spät kommt, oder spontan gar nicht kommt, wenn der Nachwuchs krank ist oder Kindergeburtstag hat, die Neffen und Nichten abgeholt werden müssen oder was-auch-immer. Im übrigen ist es genau so selbstverständlich möglich, der Firma fern zu bleiben, wenn der Hund krank ist – der Luxus beschränkt sich also nicht nur auf menschliche Familienmitglieder. 

Arbeitszeit und Home Office

Aktuell gilt eine 40-Stunden-Woche bei uns als Vollzeitstelle. Ich bin ganz ehrlich: Ich finde das ganz schön lang und nach hinten raus unproduktiv. On the bright side sind wir an dem Thema dran: Wir haben vor einigen Monaten die „Baustelle“ 30-Stunden-Woche-bei-vollem-Lohnausgleich-einführen“ aufgemacht (erwähnte ich schon, dass es bei uns keine Tabuthemen gibt?) und wollen alles dafür geben, diesen Traum zu verwirklichen – nicht nur, aber auch, weil wir uns davon erhoffen, attraktiver für neue Mitarbeiter*innen zu werden. Schon heute steht es jedenfalls jedem frei, seine Arbeitszeit bei gleichzeitigem Lohnverzicht zu reduzieren. Das ist natürlich – ganz klar – vor allem auch eine Frage der finanziellen Machbarkeit. Wiederum sehr positiv zu bewerten ist aber auch aktuell schon die Flexibilität, mit der wir unsere Arbeitszeit einteilen können. Es ist absolut gar kein Problem, wenn man zwischendurch mal einen Arzttermin hat oder zum Friseur geht, mittags ins Schwimmbad fährt oder eine Runde durch die Südstadt joggt (wir haben auch eine schicke, neue Dusche im Büro), mal später kommt, mal früher geht usw. Auch Überstunden sind bei uns tatsächlich praktisch kein Thema. Man munkelt, dass in manch anderer Agentur die Mitarbeiter*innen Extrastunden schieben müssen, wenn die Projektdeadline ins Wanken gerät oder das Budget zur Neige geht. Wir finden das nicht in Ordnung und suchen an dieser Stelle in aller Regel nach anderen Lösungen. Was wiederum Home Office und Remote Arbeit angeht, können wir uns meiner Einschätzung nach noch ein wenig verbessern. Aktuell sehen wir kein Problem darin, wenn jemand einen Home Office Tag pro Woche einlegt (es hat sich irgendwie so eingebürgert, dass das bei allen der Mittwoch ist) aber einige von uns wünschen sich da langfristig noch eine größere Flexibilität und auch die Möglichkeit, längere Zeit Remote zu arbeiten. Grundsätzlich sind wir dem Thema aber offen gegenüber eingestellt und wenn jemand mal wirklich ganz konkrete Bedürfnisse anmeldet, werden wir sicherlich darauf eingehen. Bisher war das im aktuellen Team wohl einfach noch nicht so relevant. 

Total spannende Projekte

Unsere Projekte sind spannend – aber nicht immer. Oder: Es finden nicht immer alle jedes Projekt gleich toll. Ich denke, das ist ganz normal und keine große Überraschung. Was wir aber – glaube ich – alle ganz toll finden, ist die Tatsache, dass wir fast ausschließlich für Kunden aus dem sozialen und künstlerischen Bereich arbeiten (hinter dem Link verbirgt sich eine kleine Auswahl). Das bedeutet, dass wir Websites zu Themen erstellen, mit denen wir moralisch total im Reinen sind, die oft wenig mit der „bösen Welt des Kapitalismus“ zu tun haben und in denen es nicht darum geht, den Nutzer dazu zu bringen, auf möglichst viele Werbebanner zu klicken. Was vielleicht tatsächlich nicht jedem liegt, ist eben jene Form von Agenturarbeit, die wir abdecken. Wir arbeiten nunmal mit Kunden zusammen und nicht an unserem eigenen Produkt. Das heißt, dass wir mit unseren Kunden kommunizieren, interagieren und natürlich auch im alltäglichen Geschäft Support leisten. Unsere Arbeit kann sein, über Monate hinweg ein ganz neues Webprojekt von A bis Z aufzuziehen, aber es gehört auch dazu, das Impressum anzupassen, oder herauszufinden, warum irgendeine Anzeige kaputt ist. 

Das Team

Wir sind echt nett. Wirklich. Kann man nicht anders sagen. Ok, der ein oder andere hat einen wirklich unterirdischen Wortwitzhumor, beim Mittagessen diskutierten wir letztes Jahr überdurchschnittlich oft über den Brexit (ok, die Briten haben das letztes Jahr auch überdurchschnittlich oft versucht), es fällt mal der ein oder andere derbe Spruch (woran ich nicht ganz unschuldig bin) und natürlich merkt man schon, dass man hier mit einem Haufen Nerds (aber dafür ziemlich sozialkompetenten!) zusammenarbeitet. Hast du das jetzt irgendwie anders erwartet? Nee, oder?

Das Miteinander

Unsere Firma ist ein Ort, an dem die Menschen offen und respektvoll miteinander umgehen und auch auf zwischenmenschlicher Ebene zeigt sich, dass es keine Tabuthemen gibt. Wir wissen alle, dass es zum Mensch-sein dazugehört, dass man mal gute und schlechte Tage hat, nicht immer gesund ist und auch das Erleben im Privaten einen Einfluss darauf hat, wie wir uns auf der Arbeit geben und wie produktiv wir sind. Auch hier versucht die webfactory stets den Mensch mit all seinen Bedürfnissen mitzunehmen und soweit wie möglich dazu beizutragen, dass es allen gut geht. 

Kaffeeflatrate und andere Genüsse

Jaaa, wir haben natürlich auch eine Kaffeeflatrate. An dieser Stelle vielleicht tatsächlich erwähnenswert ist die superduper Siebträgermaschine, die wir vor ein paar Monaten gekauft haben (nachdem das ganze Team an einem Barista-Kurs teilgenommen hatte). Ohne Flachs: Ich kann jetzt in Bonn fast nirgends mehr Kaffee trinken, weil er einfach nirgendwo so gut schmeckt, wie in der webfactory. Nebenher bemerkt macht es vielen von uns großen Spaß, inklusive Latte Art so ganz professionell Kaffee zuzubereiten. Abgesehen davon gibt es bei uns Sprudelwasser per Knopfdruck aus der Leitung und wöchentlich einen neuen Obstkorb. Mittags kochen wir reihum im Team und essen gemeinsam – und wer darauf keinen Bock hat, versorgt sich halt anders. Vielleicht steckt auch in uns irgendwo ein kleiner Ökohipster, denn wir bereiten standardmäßig vegetarisches und glutenfreies Essen zu. Fleischesser werden aber dennoch nicht gedisst und insbesondere von den Hunden mit Freude aufgenommen!

Urlaub

Wir haben grundsätzlich 28 Tage bezahlten Urlaub im Jahr, aber on top noch „Sonderfrei“, was ich total toll finde. Das bedeutet, dass wir Rosenmontag (hier im Rheinland feiert man da Karneval) und die Tage von Heiligabend bis Silvester geschenkt bekommen. Unbezahlter Urlaub ist darüber hinaus verhandelbar und in der Vergangenheit auch ab und an schon vorgekommen. Wenn jemand Urlaub nehmen möchte, geht auch das total locker und unkompliziert: Im Prinzip ist jeder angehalten, sich selbst zu überlegen, ob harte Gründe gegen einen Urlaubswunsch sprechen und wenn man findet, dass das passt, kann man ruhigen Gewissens auch schon die Flüge (oder in Zeiten von FFF vielleicht die Zugtickets) buchen und im Nachhinein einfach das Team informieren. Selbst spontane Urlaube waren bisher nie ein Problem und selbst wenn sich herausgestellt hat, dass man bei der eigenen Urlaubsplanung etwas wichtiges übersehen hat („Ach Mist, da ist die Konferenz?“), dann haben wir den Urlaub dennoch immer irgendwie möglich gemacht.

Das Büro

Ist tatsächlich erwähnenswert, weil wir in einem schicken Altbau in der Bonner Südstadt arbeiten dürfen. Das sieht dann auch so aus, wie man sich das vorstellt: Stuck an den Wänden, hohe Decken, Kassettentüren, große Räume und ein wunderschöner Wintergarten. Wir sind erst im September 2019 eingezogen, das heißt, es ist sogar alles noch ganz frisch renoviert! Achja: Außerdem haben wir ein Bällebad!

Willst du auch mal bei uns baden? Dann schau in unsere aktuelle Stellenanzeige und bewirb dich einfach unter: info@webfactory.de 

Hast du noch Fragen? Dann schreib uns unter selbiger Adresse oder komm einfach mal auf einen Kaffee vorbei (eine kleine Vorwarnung wäre hierbei praktisch)!

Wir freuen uns auf dich!

Anlass war die Gehaltserhöhungsanfrage eines Kollegen: Er sei jetzt zwei Jahre im Team und hätte gerne eine Anpassung. Er habe gelernt, dass man regelmäßig fragen muss, weil man sonst gehaltsmäßig abgehängt wird. Wir waren in den 20 Jahren vorher in der komfortablen Situation, nicht häufig mit solchen Fragen konfrontiert worden zu sein. Und wenn doch, haben wir zwei Geschäftsführer über die Anfrage beraten und entschieden. Wir haben nie ein explizites Geheimnis aus Gehältern gemacht, aber sie auch nie aktiv offengelegt.

Zurück zur Gehaltsanfrage des Kollegen. Auch hier habe ich mich mit meinem Co-Geschäftsführer Matthias beraten. Dass wir das Gehalt erhöhen wollten, war schnell klar. Womit wir uns schwer taten, war die Wahrnehmung "wer nicht fragt, wird abgehängt". Das fanden wir nicht fair, zumal wir im Team mehrere Leute hatten, die auch für eine Erhöhung in Frage gekommen wären, aber nicht gefragt hatten. Wie sollten wir nun vorgehen?

• Nur wer fragt, bekommt eine Erhöhung? Das hatten wir schnell ausgeschlossen, es erschien uns unfair und hätte vermutlich dazu geführt, dass über kurz oder lang jeder Kollege regelmäßig nach einer Erhöhung gefragt hätte. Hierzu muss man wissen, dass Gehaltsverhandlungen zumindest bei mir, aber auch bei vielen meiner geschätzten Kolleg*innen weit unten auf der persönlichen Beliebtheitsskala rangieren.

• Wenn eine*r fragt, bekommen alle eine Erhöhung? Das wäre aus unserer Sicht fairer gewesen, denn zumindest hätte es nicht Teammitglieder, die fragen, gegenüber denjenigen bevorzugt, die nicht fragen. Richtig rund fanden wir aber auch diese Lösung nicht ;-)

• Es gibt regelmäßig automatisch Erhöhungen, ohne dass jemand fragen muss? Schon besser. Allerdings war uns klar, dass uns das regelmäßig mit der Frage konfrontieren würde, wer wie viel Erhöhung verdient hat. Und da hatten wir das starke Gefühl, dass wir als Geschäftsführer vielleicht gar nicht den vollen Überblick haben, wer wie viel leistet (z. B. wussten wir, dass es im Team auch Kollegen gab, die sehr geschätzt waren für ihre Hilfsbereitschaft, wenn andere Probleme hatten – sie haben also einen großen Beitrag geleistet, der für uns Geschäftsführer gar nicht direkt sicht- und fühlbar war.)

Der Teamworkshop

Wir haben uns daher entschieden, die Frage nicht alleine, sondern gemeinsam mit dem Team zu beantworten. Dazu haben wir einen ganztägigen Workshop zum Thema Gehälter einberufen.

Als Vorbereitung gab es die erste Gehaltszufriedenheitsumfrage in der Geschichte der webfactory. Über ein Online-Tool (Google Forms) haben wir allen Kollegen anonym folgende Fragen gestellt:

• Wie zufrieden bist du mit deinem aktuellen Gehalt? (1=sehr zufrieden—10=sehr unzufrieden)

• Hast du das Gefühl, dass die Gehälter bei der webfactory fair verteilt sind? (1-10)

• Wie zufrieden bist du mit dem Gehaltsprozess, also dem Weg, wie das Gehalt festgelegt wird? (1-10)

• Gibt es im Gehaltszusammenhang Dinge, die dich bei der webfactory stören?

• Gibt es im Gehaltszusammenhang Dinge, die du bei der webfactory besonders positiv findest?

• Sonstige Wünsche/Fragen/Anmerkungen?

Die Ergebnisse waren überraschend: Die Zufriedenheit mit dem eigenen Gehalt rangierte im Mittelfeld, wobei 2/3 der Antworten im eher positiven Bereich lagen (5 oder besser). In der Frage nach der Zufriedenheit mit dem Gehaltsprozess lagen schon 2/3 der Antworten im negativen Bereich (6 oder schlechter). Die Wahrnehmung der Fairness war sogar noch darunter – 5 von 6 Antworten waren im negativen Bereich. Gerade letzteres hat uns gewundert: Dass die Gehälter in der webfactory nicht hoch waren und die Kollegen damit vielleicht Grund zur Unzufriedenheit hatten, konnten wir uns vorstellen – aber warum wurden die Gehälter als unfair empfunden? Wohlgemerkt: Sie waren noch nicht transparent, d. h. zumindest offiziell wusste niemand, was die anderen verdienen.

Ein perfektes Thema für den Workshop, bei dem wir uns im Anschluss an die Präsentation der Umfrageergebnisse dann intensiv mit der Frage nach der Fairness von Gehältern auseinandergesetzt haben. Folgende Aussagen hatten in der Frage "Was ist fair" hohe Zustimmung im Team:

• Abhängig von der Leistung/dem Wert für die Firma/der Produktivität/der Schwierigkeit der Aufgaben (6x Zustimmung, 1 Gegenstimme)

• Keine Unterscheidung zwischen Ausbildung und Studium bei gleicher Leistung (6x Zustimmung, 1 Gegenstimme)

• Nachvollziehbar, wie das Gehalt festgelegt wird (7x Zustimmung, keine Gegenstimme)

• Nicht abhängig vom Verhandlungsgeschick (8x Zustimmung, keine Gegenstimme)

Die Aussage "Transparenz" als Fairnesskriterium rangierte im Mittelfeld mit 4 Zustimmungen und 2 besorgten Gegenstimmen.

Da die Frage nach der Transparenz der Gehälter eine wichtige Voraussetzung für die weitere Arbeit war und aus unserer Sicht nur im Team entschieden werden konnte, haben wir uns im nächsten Abschnitt des Workshops explizit damit befasst. Bei der Frage nach dem Pro und Contra von Gehaltstransparenz haben wir im Team folgende Punkte zusammengetragen:

• Transparenz könnte Rechtfertigungsdruck auf die Geschäftsführung aufbauen

• Transparenz könnte zu Neid und Frust führen

• Transparenz ermöglicht offene Diskussion

• Wir können ein sensibles, persönliches Thema nicht mehr einfach ignorieren (keiner hatte Lust auf Gehaltsdiskussionen, aber andererseits ist das Gehalt für jeden von uns ein Thema mit großen Auswirkungen)

• Müssen wir dann gleichzeitig auch einen "Prozess" haben?

• Und last but not least: Die Unzufriedenheit ist schon da, sie kann also nicht durch Transparenz erzeugt werden

Insbesondere der letzte Punkt, der ja durch die Zufriedenheitsumfrage belegt war, hat dann in meiner Erinnerung den Durchbruch gebracht: Es bestand plötzlich eine starke Tendenz bei allen, dass wir die Gehälter transparent machen sollten. Aufgrund der Tragweite der Entscheidung haben wir uns aber noch über das Wochenende Bedenkzeit gegeben (der Workshop war am Freitag) und haben am Montag in geheimer Abstimmung entschieden. Das Ergebnis: 7 Ja-Stimmen und eine Enthaltung. Die Gehaltstransparenz war damit besiegelt.

Offenlegung der Gehälter

Noch am Tag der Entscheidung habe ich die aktuellen Gehälter aller Teammitglieder (natürlich inklusive der Geschäftsführung) im webfactory-Wiki veröffentlicht. Mit Blick auf einen angedachten zukünftigen Gehaltsprozess bereits auf der Basis von Stufen anstelle von reinen Euro-Beträgen. Ausgehend von 2.000 € habe ich 15 Stufen berechnet, jede Stufe bedeutete eine ungefähr 9%ige Steigerung zur vorangegangen. Diesen Abstand hatte ich in einer Publikation zum Gehaltsmodell von it-agile als Empfehlung gefunden, einem Beratungsunternehmen, das selbst seit langem ein teamorientiertes Gehaltsmodell hat. Stufe 15 lag bei 6.700 €.

Die neue Wikiseite "Gehälter" enthielt die resultierende Tabelle mit den Gehaltsstufen und eine Zuordnung jedes Teammitglieds zu einer Stufe bzw. teilweise auch zwischen zwei Stufen auf Basis des aktuellen Gehalts. Unsere damaligen Gehälter lagen im Mittelfeld des Spektrums, weder die obersten noch die untersten Stufen waren besetzt.

Im Anschluss haben wir eine zweite Gehaltszufriedenheitsumfage gemacht, mit den gleichen Fragen wie oben, und einem erfreulichen Ergebnis: Die Zufriedenheit sowohl mit den Gehältern als auch mit der Fairness der Gehälter und dem Gehaltsprozess hatte sich insgesamt deutlich verbessert (50% fanden die Verteilung jetzt eher fair und 5/6 waren mit dem Prozess zufrieden) – und das, obwohl wir nichts anderes getan hatten als den Status Quo offenzulegen. Hier kam uns vermutlich zu Gute, dass wir uns auch vor der Transparenz immer schon bemüht hatten, eine faire Einstufung vorzunehmen und darauf zu achten, dass Teammitglieder mit vergleichbarer Leistung auch vergleichbare Gehälter bekamen.

Pendeldiplomatie

Nach der Veröffentlichung war es uns wichtig, mit allen Teammitgliedern Einzelgespräche zu führen, um eine offene Aussprache über wahrgenommene Ungerechtigkeiten und Anpassungsbedarf zu ermöglichen. Wir haben dann in der Geschäftsführung einen Entwurf für eine Korrektur der Einstufung auf Basis des Feedbacks erarbeitet, bei dem einige Kolleg*innen höher eingestuft wurden. Diesen Entwurf haben wir dann erneut mit jedem einzeln besprochen und auf Basis des Feedbacks noch einmal angepasst. Insgesamt war das eine recht zähe Pendeldiplomatie, aber immerhin: Nach zwei Tagen hatten wir eine neue Einstufungstabelle, die die Zustimmung aller Teammitglieder hatte. In einer dritten Umfrage im Anschluss an die Neueinstufung waren dann übrigens 5/6 mit ihrem Gehalt zufrieden und 2/3 fanden die Verteilung fair – 1/3 sogar mit der zweitbesten Note.

Uns war aber klar, dass das noch kein Modell für zukünftige Gehaltsanpassungen sein konnte: Die Beteiligung des Teams hatte den Entscheidungsprozess erstmal umständlicher statt leichter gemacht. Zudem hatten wir noch keine Kriterien für eine Einstufung – diese war rein Bauchgefühl-basiert.

Entwicklung eines Gehaltsmodells

In den folgenden Monaten haben wir uns Gedanken gemacht und recherchiert, wie ein Gehaltsmodell aussehen könnte. Wir brauchten einerseits nachvollziehbare Kriterien für die Einstufung, andererseits sollten diese hinreichend weich und offen sein, um nicht falsche Anreize zu setzen. Ein plastisches Beispiel hat mir Henning Wolf beschrieben, einer der Gründer und langjähriger Geschäftsführer von it-agile:

Wir hatten mal sowas wie einen Kriterienkatalog, z. B. konnte man eine damals „Senior-Berater" benannte Stufe nur erreichen, wenn man schon mal einen Konferenzvortrag gehalten hat. Das führt aber zu komischen „Checklisten“-Karrieren und nicht zu guten Vorträgen. Deshalb haben wir keine festen Kriterien, sondern Themenbereiche, in denen wir die Kollegen relativ zu einander bewerten. Am Ende geht es um sowas wie den „Wert oder Nutzen für das Unternehmen“ im Verhältnis zu anderen Kollegen.

In einem weiteren Teamworkshop haben wir daher gemeinsam Themenbereiche gesammelt, die man für einen Vergleich zweier Kollegen untereinander heranziehen kann. Diese Liste ist eine Art Brainstorming-Ergebnis, wir haben im Grunde alle genannten Punkte aufgenommen. Die Liste ist aber auch nicht abschließend – sie soll vor allem Anhaltspunkte geben. Sie enthält folgende Punkte:

• Kundenorientierung

• Verantwortungsübernahme

• Erfolg und Wertschöpfung

• Technisches Know-How/Skills

• Schwierigkeit der Aufgaben

• Motivation und Einsatz

• Teamfähigkeit, soziale Kompetenz

• Pragmatismus und "Dinge-auf-die-Straße-bringen"

• Vielseitigkeit

• Marktwert

• Formale Qualifikationen

Auf Basis dieser Liste wäre es nun also möglich, zu sagen: Kollege B bekommt ein um eine Stufe höheres Gehalt als Kollegin A, weil beide in den meisten Kriterien gleich abschneiden, aber B eine deutlich höhere Kundenorientierung hat. Oder: A und B sind auf der gleichen Stufe, weil B zwar eine höhere Kundenorientierung hat, aber A schwierigere Aufgaben übernimmt.

Gehaltserhöhungen

Die Vergleichskriterien schienen uns sinnvoll, ließen aber eine Frage unbeantwortet: Wie berücksichtigen wir, dass jedes Teammitglied sich weiterentwickelt? Wie reduzieren wir langfristig Anpassungsbedarf in der Einstufung? Anlass für unseren Einstieg in das Gehaltsprojekt war ja der berechtigte Wunsch eines Kollegen nach einer Gehaltserhöhung nach 2 Jahren Betriebszugehörigkeit. Unsere Sorge war: wenn wir einfach nur bei der Stufentabelle und dem Kriterienkatalog bleiben, wird es regelmäßig ein Wettrennen um Neueinstufungen geben – in einem als fair empfundenen Ausgangsgefüge reicht es, wenn ein Teammitglied sagt, dass es eine Erhöhung möchte, um einen Anpassungsbedarf bei allen anderen zu erzeugen, bis jede*r eine Stufe höher geklettert ist.

Um diesen Effekt und die erwarteten unangenehmen Diskussionen zu vermeiden, haben wir eine automatische Anpassung in unser Gehaltsmodell integriert: Einen prozentualen Aufschlag für die Dauer der Betriebszugehörigkeit. Nach unseren Erfahrungen steigt der Wert einer Mitarbeiterin für die Firma mit der Zeit stark an – zum einen, weil sie sich selbst fachlich und persönlich weiterentwickelt, zum anderen, weil sie die Firma und ihre Kunden und Projekte besser kennenlernt. Unsere Inspiration war hier Buffer, ein Startup, das jedem Mitarbeiter 5% Aufschlag für jedes Jahr Betriebszugehörigkeit zahlt (https://open.buffer.com/transparent-salaries/). Wir sind etwas niedriger eingestiegen, zumal wir den Loyalitätsbonus natürlich auch für die bestehenden Kollegen einführen wollten. Und da Matthias und ich bereits 20 Jahre im Unternehmen waren, hätten wir 100% Aufschlag nicht als fair empfunden und es hätte uns auch finanziell überfordert. Unser Modell sieht 4% Gehaltssteigerung für die ersten 5 Jahre vor, 2% mehr für jedes weitere Jahr bis zum 10. Jahr, und 1% pro Jahr darüber hinaus.

Dennoch gibt es natürlich ab und zu auch das Bedürfnis nach einer Neueinstufung – alleine schon bei neuen Teammitgliedern, mit denen wir während der Probezeit lieber eine vorsichtige Einstufung vereinbaren, die dann am Ende der Probezeit überprüft wird.

Der Prozess für Neueinstufungen

Für uns war klar, dass der Prozess für Neueinstufungen teambasiert sein muss – sonst hätte es potenziell bei jeder Einstufungsänderung Unzufriedenheit oder Diskussionen im Anschluss gegeben. Daher setzen wir folgendes Verfahren ein:

Wenn ein Teammitglied auf eine neue Gehaltsstufe wechseln möchte, stellt es bis zum Ende der ersten vollen Arbeitswoche des Jahres einen "Antrag" – konkret eine Mail an die Geschäftsführer mit der gewünschten neuen Stufe und einer Begründung auf Basis des Gehaltsmodells. Diese Begründung wird, wieder in Form einer anonymen Online-Umfrage, an das Team weitergegeben. Hierzu stellen wir folgende Fragen:

• Ich bin für folgende Einstufung (Auswahlliste mit allen Gehaltsstufen)

• Anmerkung/Begründung dazu

• Gibt es sonstige Personen, die aus meiner Sicht höhergestuft werden müssten?

• Gibt es Personen, die aus meiner Sicht zu hoch eingestuft sind?

• Ist das resultierende Gehaltsgefüge (wenn die Entscheidungen in meinem Sinne fallen) insgesamt fair? Wenn nicht, was müsste sich ändern?

• Was ich sonst noch sagen wollte (freies Bemerkungsfeld)

Wichtig ist uns dabei, dass mit jeder Neueinstufung auch noch einmal mit dem gesamten Team die Fairness des Gesamtgefüges abgestimmt wird.

Auf der Basis der Umfrage entscheidet dann die Geschäftsführung über die Einstufung. Aus unserer Sicht kann die Entscheidung auch an andere Personen delegiert werden (ein "Gehaltschecker"-Gremium), aber das ist vielleicht eine zukünftige Ausbaustufe.

Berufserfahrung: eine offene Flanke

Wir haben das Gehaltsmodell bewusst so konstruiert, dass wir regelmäßige Gehaltserhöhungsanfragen unnötig machen. Das erreichen wir wie beschrieben über den Betriebszugehörigkeitsbonus, der den Zuwachs an Produktivität sowohl durch hinzugewonnene Berufserfahrung und Fachwissen als auch durch bessere Kenntnis der Fima und ihrer Kunden abbilden soll.

Eine Schwierigkeit besteht aus meiner Sicht noch darin, dass Berufserfahrung, die innerhalb der webfactory gesammelt wird, damit anders bewertet wird als Berufserfahrung, die vorher gesammelt wurde (die muss folglich durch die Gehaltsstufe abgebildet sein). Nehmen wir an, ein Entwickler mit Uniabschluss steigt mit 2 Jahren Berufserfahrung in der webfactory auf Stufe 8 ein. Nach 5 Jahren bei uns hat er auf der gleichen Stufe einen Betriebszugehörigkeitsbonus von 20%, also das Äquivalent von zwei Gehaltsstufen mehr als beim Einstieg. Wenn eine Kommilitonin von ihm, die gleichzeitig ihren Abschluss gemacht und in den 5 Jahren woanders gearbeitet hat, zur webfactory wechselt, müsste sie auf Stufe 10 einsteigen, wenn sie annähernd das gleiche Gehalt bekommen sollte (tatsächlich wären es dann sogar noch 30 € weniger). Mein Eindruck ist aber, dass die Gehaltsstufen unweigerlich auch mit Rang- oder Wertigkeitsstufen assoziiert werden. Selbst wenn die neue Kollegin "nur" auf Stufe 9 einsteigen würde und damit ein um knapp 9% geringeres Gehalt akzeptieren würde als ihr Kommilitone, würde es für ihn doch leicht so aussehen, als sei er mit Stufe 8 weniger wert als sie.

Hier glaube ich, dass vielleicht noch ein Baustein fehlt, der dieses Problem vermeiden hilft.

Mein Fazit

Die Gehaltstransparenz hat sich seit Tag 1 richtig angefühlt. Ich glaube, niemand von uns kann sich mehr vorstellen, die Gehälter wieder geheim zu halten. Insbesondere die offenen Gespräche über faire Gehälter wären ohne Transparenz nicht möglich.

Das Gehaltsmodell mit der Kombination aus automatischen und anlassbezogenen Erhöhungen hat sich seit nunmehr drei Jahren in allen Situationen bewährt. Durch seine Offenheit und das Fehlen von harten Kriterien ist die Einstufung zwar manchmal schwierig und natürlich subjektiv, aber da das ganze Team gehört wird, nicht willkürlich. Gerade diese Flexibilität ermöglicht es uns auch, jedem Einzelfall gerecht zu werden.

Insgesamt ist es recht ruhig um das Thema, was für mich auch bedeutet, dass das Modell hinreichend gut funktioniert und wir uns anderen Baustellen widmen können.

Gerade letzte Woche haben wir übrigens zum ersten Mal seit der Einführung des Modells die Gehaltsstufen inflationsbasiert angepasst, was für jeden eine zusätzliche Gehaltserhöhung von 4,78% bedeutete.

When staging a project to run tests or build a Docker image, you might need to fetch additional dependencies (libraries or "vendors") from private repositories. However, GitHub Actions are limited to accessing the repository they run for.

To solve this, you can create an additional SSH key with sufficient access privileges. Store that key in the secrets storage which is in the "Settings" area of your repository. The secret content is the private SSH key, as you will find it in the id_rsa file.

For the following example, the name of the secret should be SSH_PRIVATE_KEY.  Then, have a look at the following workflow definition:

# .github/workflows/my-workflow.yml
# ... other config here
jobs:
    build:
        runs-on: ubuntu-18.04
        steps:
            -   uses: actions/checkout@v1

            -   name: Setup SSH Keys and known_hosts
                env:
                    SSH_AUTH_SOCK: /tmp/ssh_agent.sock
                run: |
                    mkdir -p ~/.ssh
                    ssh-keyscan github.com >> ~/.ssh/known_hosts
                    ssh-agent -a $SSH_AUTH_SOCK > /dev/null
                    ssh-add - <<< "${{ secrets.SSH_PRIVATE_KEY }}"

            -   name: Some task that fetches dependencies
                env:
                    SSH_AUTH_SOCK: /tmp/ssh_agent.sock
                run: ./fetch-deps.sh

We first run ssh-keyscan to detect GitHub's SSH host keys. This for sure could be improved if worker nodes had these keys already set up. We then start the ssh-agent , binding it to a predictable socket location, and finally import the SSH private key into the agent. The nice thing about the way this happens is that the private key is never written to disk.

After the setup step has run, the SSH agent will still be running and can be used by other processes. To make this happen, set the SSH_AUTH_SOCK environment variable. Commands like git run ssh under the hood and will make use of the key stored in the agent when they authenticate to other hosts.

Right now, you will have to set the environment variable for every step that needs it, but it looks as if an improvement for this is already underway. 

Where to register the public SSH key part?

To actually grant the SSH key access, you can – on GitHub – use at least two ways:

• Deploy keys can be added to individual GitHub repositories. They can give read and/or write access to the particular repository. When pulling a lot of dependencies, however, you'll end up adding the key in many places. Rotating the key probably becomes difficult.
• A machine user can be used for more fine-grained permissions management and have access to multiple repositories with just one instance of the key being registered. It will, however, count against your number of users on paid GitHub plans.

class Order
{
    const PRIORITY_NORMAL = 'normal';
    const PRIORITY_HIGH = 'high';

    // ...
}

A method accepting one of these constants usually looks like this:

class Order
{
    /**
     * Create a new order instance
     */ 
    public static function place(ItemList $items, string $priority): self
    { ... }
}

Problems with the scalar-typed approach

Although there are two special string values defined as the two constant values in the above example, clients of this method may pass in literal string values (a plain  'normal'  or  'high' ) directly. For example, this may happen if they are taking the value directly from request parameters, which obviously is a risky practice.

In general, as the  Order::place()  method above accepts a string, nothing prevents you from passing in arbitrary string values.

Another possible mistake is that parameter order is messed up and arbitrary values are passed in places where constant values are expected.

To make your software design robust, defensive and fail-fast, in the above example you should check that the  $priority is indeed one of the available priorities.

As you can imagine, this can quickly get impractical when the constant values are used a lot and passed on between methods, as each method would need to check them again and again. Adding a new constant value would also require you to update all those checks.

When working with  int  constants ( 0, 1, 2, ... ), the mistake of messing up the parameter ordering might be so subtle that you cannot catch it by checking the parameter value.

Constant value objects

So, here is another way how we can design this. I will be building upon two OOD concepts:

• Value objects describes the approach of modelling plain values as objects.

• Often, it is benefical as well to design such objects as being immutable.

You can find valuable chapters on both ideas in Eric Evans' book "Domain Driven Design".

Bringing both together, we can come up with an  OrderPriorty  class as follows. Let's call this a constant value class:

class OrderPriority
{
    private const NORMAL = 'normal';
    private const HIGH = 'high';

    private $priority;

    public static function NORMAL(): self
    {
        return new self(self::NORMAL);
    }

    public static function HIGH(): self
    {
        return new self(self::HIGH);
    }

    private function __construct($priority)
    {
        $this->priority = $priority;
    }
}

As the  OrderPriority  constructor is private, the only way of creating  OrderPriority  instances is through the static construction methods  OrderPriority::NORMAL()  and  OrderPriority::HIGH() .

We can now write our method as

class Order
{
    public static function place(ItemList $items, OrderPriority $priority): self
    { ... }
}

Since PHP is type-checking the  $priority  parameter, you can now be sure you're dealing with some kind of  OrderPriority . Without further checks or safeguards, the  place(...)  method can now be sure that  $priority  is one of the valid priority levels.

There is one required change for clients passing in one of these values: Instead of writing  Order::PRIORITY_NORMAL  or  Order::PRIORITY_HIGH , we will now use  OrderPriority::NORMAL()  or  OrderPriority::HIGH() . This is necessary to create the instances of our constant value class.

Note that I chose to name these methods all caps to resemble the convention of constant identifier naming.

Checking for constant values

When checking a parameter like  $priority  for one of the constant values, we can write the check as  $priority == OrderPriority::HIGH() . This already works for the  ==  loose comparison since the values of both constant class instances – the one in  $priority  and the one created on the fly – are the same.

As a cautious programmer, however, you're probably using the strict comparison operator  ===  whenever possible. With a constant value class as shown above, this will not work, since this operator also checks for object identity and we're using two different object instances.

So, let's fix that.

Using flyweights

The Flyweight is a structural pattern from the classic "Gang of Four" book. Part of the pattern is the idea to re-use object instances when they don't differ in state, which is perfect for our immutable constant values.

Also described in the pattern is the need to have some kind of factory to obtain flyweight object instances without creating them again and again.

So, let's add a new method to our class that takes care of this. We'll call it  constant()  since it returns the constant value object instance for a given value.

This method will be  private  as well, so clients still have to use the construction methods ( OrderPriority::NORMAL()  and  OrderPriority::HIGH() ) as before.

class OrderPriority
{
    private const NORMAL = 'normal';
    private const HIGH = 'high';

    private static $instances = [];

    private $priority;

    public static function NORMAL(): self
    {
        return self::constant(self::NORMAL);
    }

    public static function HIGH(): self
    {
        return self::constant(self::HIGH);
    }

    private static function constant($value)
    {
        return self::$instances[$value] ?? self::$instances[$value] = new self($value);
    }

    private function __construct($priority)
    {
        $this->priority = $priority;
    }
}

Now, for every different constant value, only one single object instance will be created. The same instance will be returned for every call to methods like  OrderPriority::NORMAL() . And since there is only one instance per value, the  === strict comparison now works.

Constant definitions in interfaces

One tiny drawback of the approach shown above is that you cannot put such constant definitions into interfaces. The approach is based on object instances, which are a runtime concept. Interfaces, however, do not contain implementation code and thus cannot provide the necessary methods.

You can, of course, have a "constant value class" to provide the allowed values and then have your interface use it, for example as part of method signatures.

A nice trait

In our current draft of the  OrderPriority  class, everything besides the actual two constant values and the construction methods is pretty much boilerplate and would be the same for every "constant value class". So, let's move that to a reusable trait:

trait ConstantClassTrait
{
    private static $instances = [];

    private $value;

    final private function __construct($value)
    {
        $this->value = $value;
    }

    private static function constant($value)
    {
        return self::$instances[$value] ?? self::$instances[$value] = new self($value);
    }
}

With this,  OrderPriority  becomes:

class OrderPriority
{
    use ConstantClassTrait;

    private const NORMAL = 'normal';
    private const HIGH = 'high';

    public static function NORMAL(): self
    {
        return self::constant(self::NORMAL);
    }

    public static function HIGH(): self
    {
        return self::constant(self::HIGH);
    }
}

Casting to and from strings

Sooner or later, you might find yourself in a situation where you need to render an HTML form with something like a select list or radio button for an  OrderPriority . Or, you need to accept the  OrderPriorty  from a form or the command line as input.

Since we're now dealing with the  OrderPriority  class, we now have a perfect place to keep such additional methods:

class OrderPriority
{
    // Omitted trait and construction methods (like before)
    
    public static function fromString(string $value): self
    {
        if ($value !== self::NORMAL && $value !== self::HIGH) {
            throw new InvalidArgumentException();
        }
        
        return self::constant($value);
    }
    
    public function __toString()
    {
        return $this->value;
    }
}

You can now easily cast an  OrderPriority  instance to a string, for example when using it as the  <input value="..."> .

Now assume your task is to write the code that accepts a new  Order  from a web request or the command line. At your UI/code boundary, the order priority will clearly be available as a string. The  Order::create()  method, however, needs an  OrderPriority  instance.

Even somebody new to your project will quickly figure out that there are only a few ways to actually create  OrderPriority instances. They will probably find the  OrderPriority::fromString()  method and write code like this:

    // Somehow obtain $itemList
    $order = Order::place($itemList, OrderPriority::fromString($_REQUEST['priority']));
    // ... 

The bottom line is that the way we have written our  Order  and  OrderPriority  classes here makes it almost impossible to use them in a wrong way or to forget checking our inputs.

Even more value object perks

For a moment, assume your business comes up with a requirement to add a new  expedited  priority class. This service level is above the  normal  level, but does not yet make a  high  priority order.

I'll leave it to you as an exercise to add the  EXPEDITED  constant definition, a creation method and to update the  fromString()  method in our  OrderPriority  class.

What is more interesting is that we can now add an additional method to compare two priorities:

class OrderPriority 
{
    // ... as before

    public function atLeast(OrderPriority $other): bool
    {
        // Return true if $this->value is a priority equal to or above $other->value.
    }
}

With this, our new business rule might be something along the lines of

class ShippingFeeCalculator 
{
    public function computeShippingFees(Order $order): Money
    {
        // ...

        if ($order->getPriority()->atLeast(OrderPriority::EXPEDITED()) {
            // ... do what business requested
        }
    }
}

Being a value object, the  OrderPriority  class is a nice place to keep such additional comparison and computation methods which make it even more expressive.

Summary

This article described how simple class constants can be replaced with instances of a "constant value class". Methods that accept such constants can use type hints to make sure only valid constant values can be passed, without having to perform any additional checks. By reusing object instances, comparisons of constant values can also be written using the  ===  strict syntax check, with only minimal changes to code being necessary.

In addition to that, the constant value objects are a great place for keeping a particular kind of business logic.

Eine Anfrage wie diese löst oft widersprüchliche Gefühle aus. Einerseits macht es Spaß, eher obskuren Bugs auf die Schliche zu kommen, andererseits seufzt man innerlich ob der ungewöhnlichen Problematik.

Zum Glück konnten wir das Problem zügig eingrenzen: "Mit deaktiviertem Javascript funktioniert es", schrieb Stefan nach zehn Minuten. Einige Zeit später war klar, dass es an Hyphenopoly, einem Javascipt-basierten Polyfill für Silbentrennung lag. 

Silbentrennung – ein gelöstes Problem?

Wir setzen Hyphenopoly in Projekten ein, in denen Wert auf ordentlichen Flattersatz mit Silbentrennung in allen Browsern gelegt wird. Eigentlich unterstützen mittlerweile fast alle Browser Silbentrennung über eigene Wörterbücher und Regelwerke, die natürlich für jede Sprache unterschiedlich sind. Der Support für Deutsch ist insgesamt geringer als der für Englisch, aber Mozilla Firefox, Apple Safari, Google Chrome und demnächst Microsoft Edge haben Silbentrennung für die deutsche Sprache umgesetzt. Die große Ausnahme ist hier leider der Microsoft Internet Explorer (IE) in allen Versionen. Für Deutschland gibt StatCounter zwischen Mai und August 2019 zwar "nur" noch einen Anteil von ca. 7% für IE 11 an, beim Gemeinsamen Bundesausschuss liegt dieser aber deutlich höher: hier sehen wir in unseren Daten für IE 11 eine Quote von 25% für den gleichen Zeitraum. Diese Zahlen sowie der (Kunden-)Wunsch nach visueller Einheitlichkeit sind der Hauptgrund für unseren Einsatz von Hyphenopoly.

Hyphenopoly bringt von Haus aus eine sogenannte feature detection mit: zunächst wird nur ein kleines Skript geladen, das beim Aufruf der Website für ein konfiguriertes Testwort testet, ob der Browser eine erwartete Silbentrennung vornehmen würde. Nur wenn das Ergebnis negativ ausfällt, lädt Hyphenopoly das eigentliche Skript sowie die für die aktuelle Sprache nötigen Wörterbücher nach.

Regression in Firefox

Zurück zu unserem Problem. Die Tatsache, dass Hyphenopoly scheinbar verhindert, dass Verknüpfungen mit kopiert werden können, ist unschön, aber vielleicht nicht die Stelle, an der wir zuerst ansetzen sollten.

Was uns vor allem verwundert hat: Firefox unterstützt Silbentrennung für Deutsch, Hyphenopoly hätte also gar nicht in Aktion treten sollen! Ein kleiner Testcase bestätigte unseren Verdacht – tatsächlich schlug die Silbentrennung in Firefox fehl. 

Eine schnelle Suche im Bugtracker von Firefox blieb ohne Erfolg  – scheinbar hatte noch niemand ein Ticket erstellt. Kein Problem, wir hatten ja bereits einen Testcase. Zusätzlich konnten wir beweisen, dass die Silbentrennung in einer der letzten Versionen von Firefox noch korrekt funktioniert hatte. Genug Informationen für einen hoffentlich aussagekräftigen Bugreport.

Die Antwort traf nur wenige Stunden später ein: es war doch ein bereits bekannter Fehler, der in der folgenden Browserversion bereits behoben war. Mit einem Großbuchstaben beginnende Worte wurden nicht korrekt getrennt! Die gleichen Worte, komplett in Kleinbuchstaben, verhielten sich einwandfrei. Auch das konnten wir in unserem Testcase sofort nachvollziehen.

Abschließend konnten wir daher unser Hyphenopoly-Testwort anpassen (nur Kleinbuchstaben), das unnötige Laden des Polyfills auch in der aktuellen Version von Firefox verhindern und unsere Ansprechpartnerin informieren, dass sie ab sofort wieder Links von der Website kopieren und samt Verknüpfung in Word einfügen kann.

Eine kuriose Fehler-Kaskade aus dem Alltag in der Webentwicklung.
 

Ich weiß noch ganz genau, wie trocken und uninteressant ich den Bereich Webentwicklung fand. Vor zwei Jahren kam ich zum ersten mal mit HTML und CSS in Berührung. In einem stickigen Klassenzimmer wurde mir träge im Unterricht die ersten Basics der Sprachen vermittelt. Es wurde mit Fremdwörtern im Schwall geredet und in wirren Strukturen gezeichnet. Meine Verwirrung wurde dabei immer größer. In diesem Moment beschloss ich damals, dass ich den Bereich Webentwicklung nie wieder in meinem Leben betreten wollte.

Aber: Sag niemals nie!

Der Wurf

Nach dem Abschluss meiner Ausbildung zur gestaltungstechnischen Assistentin in Grafik und Objektdesign bewarb ich mich im Bereich Print für die duale Ausbildung als Mediengestalterin. Ich bekam einen Ausbildungsplatz und absolvierte mein erstes Lehrjahr im Printbereich. Was ich vorher nicht wusste: Mediengestalter, die im Bereich Digital ausgebildet werden, sind ebenfalls in meiner Berufsschulklasse. So kam es dazu, dass mich wieder HTML und CSS in der Schule verfolgten. Wieder durfte ich stupide die Sprachen lernen. 

Diese Mal ging der Lehrer aber mehr auf das Verständnis der Schüler einz. Ich verstand die ersten Basics, konnte mich aber mit dem Coden nicht anfreunden. Mit meinen ersten Kenntnissen versuchte ich, eine Website zu erstellen. Ich würde heute rückblickend sagen, dass es auf jeden fall keine Website war, welche ich da gebaut habe.

Das erste Schuljahr beugte sich dem Ende und mein Lehrer quälte mich durch das trockene Schulfach. Dann kam meine Ausbildungsstätte auf den interessanten Gedanken, dass ich in den Sommerferien ein fünfwöchiges Praktikum absolvieren könnte. Die einzige Bedingung war, dass ich das Praktikum im Bereich "Frontend-Entwicklung" absolvieren sollte. Ich gab mich den Gedanken hin und fasste den Entschluss, der Webentwicklung nochmals eine Chance zu geben. Und das, obwohl ich mir wirklich nicht vorstellen konnte, dass immer mehr Menschen Coden möchten, wenn es doch so trocken ist.

In meiner Berufsschulklasse sah ich einige Mitschüler, welche wirklich gute Websiten bauten. Das gab mir den Impuls, das Webentwicklung vielleicht doch nicht trocken sein konnte. Also bewarb ich mich bei der webfactory in Bonn. Meine Vorfreude wuchs,  da ich gespannt war, ob sich meine schlechten Erfahrungen mit Webentwicklung bestätigen würden, oder ob das Frontend doch interessanter ist, als gedacht.

Treibende Strömung

Ich bekam nach einem netten Telefonat den Praktikumsplatz. Am ersten Tag wurde ich von einem netten Team und zwei süßen Hunden begrüßt. Mit einem Online-Workshop, der zwei Tage ging, ratterte ich die Basics von HTML und CSS runter. Ich war wieder an einem Punkt, wo meine schlechten Erfahrungen sich bestätigen wollten. Das Webentwicklung tatsächlich nichts für mich ist.

Doch dann kam die Wendung. Als würde ein Regenschauer vorbei ziehen und die Sonne zwischen den Wolken durchscheinen, machte ich die ersten richtig interessanten Erfahrungen. Ich baute mit meinem Wissen aus dem Workshop eine erste Website. Ich verstand wirklich, was ich da schrieb! Ich war an einem Punkt angelangt, wo ich es nicht glauben konnte, dass ich zum ersten mal so etwas wie Freude fühlen konnte, während ich die Elemente und Styles in CodePen eintippte.

Ich konnte mit CodePen direkt sehen, wie sich der eingetippte Code verhielt. Besonders das Gerüst einer Website konnte ich nun sehen und anwenden. Nach den ersten Übungen kam Lukas auf mich zu und zeigte mir ein Spiel, das die Funktionen von Flexbox erklärt. Flexbox ist ein Weblayoutmodell, mit dem man Content auf der Website ausrichten kann. Danach zeigte er mir noch das Version Control System (VCS) Git. Mit Git führt man ein Protokoll über die Veränderungen des Codes, damit man nach längerer Zeit nachvollziehen kann, was man an bestimmten Stellen im Code geändert hat. So können auch andere Mitarbeiter an dem Code weiter arbeiten und Änderungen direkt nachvollziehen. Außerdem kann man aus einem beliebigen Stand auf den Code zurückspringen, falls man ungewünschte Änderungen zurücksetzten möchte.

Richtung wählen

In der zweiten Woche meines Praktikums fing ich an, ein Konzept für meine eigene Website zu entwickeln. Mir war schnell klar, dass ich ein Portfolio erstellen wollte, da ich in meiner Freizeit Designprojekte erstelle und diese präsentieren möchte. Auf der Seite sollten also meine Projekte zu sehen sein, und dazu Texte mit Einblicken in meine kreativen Prozesse.

Ich tüftelte das Konzept eine ganze Woche lang aus. Dabei wurde ich in ein Programm namens Sketch eingeführt, welches zur Visualisierung von Website-Layouts dient. Ich bekam immer wieder Feedback von Stefan, der mir half, mehr Verständnis für die Anforderungen von Webseiten und Userinterfaces zu erlangen.

Nach mehreren Entwürfen entschied ich mich nun für einen. Mir wurde immer wieder bewusst, dass die Ausbildung "Mediengestalter Digital und Print" genannt wird, aber zwischen den Bereichen Welten liegen. Nach Erstellung des Konzepts und meinen ersten Entwürfen fing ich mit dem Code Editor Visual Studio Code an, meine erste richtige Website zu bauen. Die ersten Basics funktionierten gut. Bis ich Flexbox anwenden musste. Ich übte gefühlt mehr als eine Woche, bis ich wirklich verstand, wie Flexbox funktioniert. 

Mit immer neuen Befehlen baute ich meine Website und mein Wissen aus. Dann kam der Tag, an dem mir Søren mitteilte, das meine Website auch mobil funktionieren muss. 

Responsive Design. Die Kopfschmerzen bahnten sich langsam an. Wie sollte das gehen? 

Ich las Bücher und googelte mehr als zuvor, um die mobile Ansicht zu optimieren. Doch die Navigation war mein Endgegner. Ich schrieb einen komplizierten Code, der nach viel Kopfzerbrechen am Ende mit wenigen einfachen Befehlen und Flexbox gelöst werden sollte:

.navigation {
    display: flex;
    justify-content: space-evenly;
    align-items: center;
}

Da verstand ich die Schwierigkeit, Code simpel zu schreiben. Media Queries halfen mir, den Anforderungen der verschiedenen Displays und dem Design gerecht zu werden, da man mit ihnen bestimmen kann, dass für verschiedene Displaygrößen unterschiedliche Befehle gelten dürfen.

Erkenntnis

Im Laufe der Umsetzung in HTML und CSS bemerkte ich eine zunehmende Unzufriedenheit mit meinem Design. Eva eilte mir zu Hilfe und gab mir wertvolle Tipps, wie ich mein Design optimieren könnte. Ich fing an, meine ersten Entwürfe komplett zu verwerfen und hielt mich an anderen Farbwelten und Typografien fest. Ich wollte, dass meine Persönlichkeit sich in dieser Website widerspiegelte.

Der letzte große Baustein folgte noch: Ich wollte zur Präsentation meiner Projekte eine Galerie haben. Der Begriff „Overlay“ viel zum ersten Mal. Eine Ansicht, die jeder schon mal gesehen hat: Die Website verdunkelt sich und Content wird in einen Präsentationsmodus gebracht. Mit JavaScript und npm bauten Lukas und ich ein Overlay in meine Website ein.

Während des ganzen Praktikums geriet ich immer wieder in Sackgassen beim Coden, aber mir wurde immer wieder durch Bücher und Teamwork geholfen. Manchmal half es auch einfach, erst am nächsten Tag das Problem in Angriff zu nehmen. Die positive Kritik, die mir immer weiterhalf führte dazu, dass ich meine Kreativität immer mehr herausholte und mein ganzes Herzblut in dieses Projekt steckte.

Dann kam der Zeitpunkt, an dem ich meine eigene Domain kaufte, mein Git Repository mit einem Webserver verknüpfte und meine Webseite endlich online war. Hier findest du sie: lisaheidenreich.de

Mir wurde bewusst, dass ich mir vor einem Monat nicht mal ansatzweise vorstellen konnte, dass es Spaß machen würde, Webseiten zu designen. Ich kann jetzt nachvollziehen, warum Webentwicklung eine tolle und wirklich aufregende Welt ist. Jeden Tag kommen neue Befehle dazu. Es ändern sich täglich neue Dinge, weshalb man nie auslernt. Vor allem die vielen Möglichkeiten reizten mich. Da begriff ich, dass Print und Digital doch mehr Gemeinsamkeiten haben, als gedacht, und trotzdem Unterschiede wie Tag und Nacht besitzen.

Das Praktikum bei der webfactory hat mir geholfen zu verstehen, dass Webentwicklung kein Einhorn (etwas Undefinierbares) ist, sondern ein logisches, cooles, nervenaufreibendes, komplexes Designen von Webseiten und Webanwendungen sein kann.

An meinem letzten Tag des Praktikums präsentierte ich meine Ergebnisse dem Team. Hier findest du meine Präsentation: Abschluss Präsentation

Lisa Marie Heidenreich

Symfony is open source. That means everyone may use it for free. You can read the source code, which gives you a better understanding of how things work. You are free to change and adapt the code to make it fit your needs. And everyone can contribute: By fixing bugs, adding new features and giving these changes back to the project itself.

For us at webfactory, building on top of Symfony has been a strategic choice we made back in 2011 and did not regret ever since. Symfony has grown over the years, also when it comes to strategic decision-making, policies and processes. There is a clearly defined release cycle, and Symfony delivered over a dozen of releases in time.

The Hackathon idea

I was very excited when I got the invitation for a "Hackathon" event in Brussels. Funding was provided by EU-FOSSA 2, the "EU-Free and Open Source Software Auditing project". This programme is managed by the European Commission's Directorate-General for Informatics (DIGIT). It provides a systematic approach for the EU institutions to ensure that widely used critical software can be trusted.

The Hackathon was invite-only and brought together about 50 contributors and "core team members" in a single venue. Most of them were from EU countries, but some also arrived from the US, Cuba, Morocco, Russia or Switzerland. The organizers did a great job, creating an environment where all attendees could work together to bring the Symfony project forward. We planned to work on strategic initiatives like Diversity and Inclusion, fix security problems and reduce the number of open support or change request tickets in general.

This weekend was different

Usually, open source projects work by using online tools for collaboration. Discussions and decisions take place in online forums, public chats or on mailing lists. This "asynchronous" way of working makes it possible for anyone to join. But sometimes it can be hard as well, since written communication lacks the richness of personal interaction.

The venue was an extraordinary place. These photos might give you an idea:

We had plenty of space to come together in groups, discuss things, to work on desks right next to each other or to retreat in cosy, quite places to help concentration.

Never before have so many contributors and members of the core team been together in one place. That gave an incredible boost to everyone and set free lots of energy and enthusiam. Talking to each other, getting advice from senior contributors or directions from the project leads themselves was always just a matter of walking a few steps.

Around that, we had a lot of occasions to get to know each other, to connect, trade stories and share experiences. For me, it was the first time to meet about a dozen of people that I had worked with before online without ever having seen their faces. In most cases, I knew their GitHub usernames better than their real names.

Some numbers and figures

Speaking of GitHub: On that platform, developers open so-called "pull requests". Basically, these are proposals to perform a particular change in the code. These pull requests are then reviewed and discussed. More than often, the initial idea undergoes many rounds of changes, fixes and improvements before it finally gets "merged". In addition to that, "issues" are created for reporting bugs, discussing new ideas and features even before having code for it.

The GitHub statistics for this weekend are impressive, even though the second day hasn't even finished yet:

The Symfony documentation team, which works in a separate GitHub area, did equally well:

Fabien Potencier, the project lead, estimated that on this weekend the work of two months of regular activity has been done. In this filtered issue tracker list, you will find that more than 230 issues have been addressed or even resolved.

The most impressive figure, in my opinion, comes from the "Continuous Integration" system. For every single change suggested, this system will run a suite of several thousand automated software tests to make sure nothing breaks. If you look at the following chart of how many test runs have been triggered during the past 30 days, it gives you a good idea of how much activity there was.

After more than 12 hours of focused work on the first day, we're now on Sunday afternoon and preparing for a closing session. All the groups will get an opportunity to tell the others about their work and results. We're also looking forward to some closing remarks from the project leads as well as the EU-FOSSA 2 team.

Although exhausted, I think most of us will return home with a feeling of satisfaction. For sure we've all learned a lot at the same time as bringing the Symfony project and related open source projects a leap forward.

Thanks – and hope to see you all soon again at one of the Symfony conferences or user groups!

Many thanks to jdreusse, tobion and nicolas-grekas for their time and for discussing the topic in an open-minded way. The PR we were initially discussing is symfony/issues/27351. Later on, @dunglas also pointed me to an earlier PR. 

Why it is convenient to do it wrong

What you might have seen already is that secrets like database passwords, API tokens and such are added to configuration files and committed into code repositories:

# config/services.yaml
parameters:
    mysql.password: nobody-knows-this
    some_api.token: this-is-a-secret

It doesn’t matter if it is the config/services.yaml file, or maybe different files like parameters_prod.yml , parameters_dev.yml  which are included depending on the environment ( dev , prod ) that you’re in.

Storing plain-text secrets in your code repository is a bad practice. That way, they are distributed to everyone and everywhere the repo is used, like development laptops, CI servers and production systems.

You might be tempted to do it this way because it is simple and convenient. At least for two reasons:

• You have the necessary parameters right alongside your code. A team member can just clone the repo and they’re ready to go. No need to figure out the right MySQL password, tokens and stuff before you can start working on a project.

• Imagine you start using another API in your application. If you commit the code that requires the API token in one repo and the token itself somewhere else, then you’d have to make sure that during deployment both repos/versions will be aligned. You don’t want to run a version of the code when the token is not yet in place.

Storing secrets safely

Obviously, it would be better if we had a way to store secrets in a „safe“ way. You can, for example, keep all your secrets in a secrets.json file and use off-the-shelf tools to encrypt this file before you commit it into version control.

The Puppet ecosystem provides a neat tool for this called hiera-eyaml . It’s written in Ruby, and if you’re lucky, gem install hiera-eyaml might be all you need to get it installed. There’s also a Docker image available, if you're more comfortable with that.

To prepare your repo, run eyaml createkeys . That will create a private-public key pair and store it a ./keys directory. Grab the private_key.pkcs7.pem file from there and stow it away in a safe place – not in your repo. Commit the public_key.pkcs7.pem file and keep it in your repository.

With this in place, the eyaml command has some operating modes to encrypt and/or decrypt strings or files:

# Encrypt "bar" and print as YAML for the "foo" key
eyaml encrypt -l foo -s bar 
# Ask for the secret value as a hidden password
eyaml encrypt -l foo -p 
# Encrypt the value "bar" and print as a plain string
eyaml encrypt -s bar -o string

All of these work with just the public key being available. Make sure to check the documentation or --help output for more details.

Also, eyaml edit -d secrets.json will open secrets.json in your $EDITOR . Try putting the following lines into that file:

{ 
    'mysql_password': 'DEC::PKCS7[dont-tell-mum]!',
    'another_token': 'DEC::PKCS7[another-secret]!'
}

Once you exit the editors, all DEC::PKCS7[…]! sections will be replaced with encrypted values.

Don’t let the eyaml  name misguide you. In fact, the tool does not care about the file format. As you will have noticed, I’ve used JSON in the example above.

secrets.json  will be checked into version control. This way of keeping encrypted values in a file that is itself unencrypted is useful because version control commands like blame or diff still work as one would expect. If the entire file were encrypted, every single change would result in a completely different file being committed.

Decrypting secrets in the runtime environment

At runtime, you need to decrypt the secrets so that Symfony can work with the plain values. Let's try to keep that decryption step out of Symfony and solve it with the tools we already have.

So, in the case of eyaml , the following command will read the secrets.json file and write it decrypted to .secrets.json . Obviously, this time you need to provide the private key.

eyaml decrypt --pkcs7-private-key=/path/to/private_key.pkcs7.pem -f secrets.json > .secrets.json

Honestly, I am not sure how you would get the private key safely in place. Maybe you can distribute it to your production machines using some kind of infrastructure management or tooling, or mount it into the container when running your application in Docker.

The point is that this command can be run at a very late stage, during the actual deployment.

When using Docker, you don’t have to bake the decrypted secrets into the image, which also avoids pushing them into the registry. You can instead defer this step until you actually start the container.

Even more, you can remove the private key again after this file has been dumped but before actually start the application.

(To-Do: Explain in more detail how this could work. Use an entrypoint script? create the container and extract the secrets file before start ing it?)

Reading secrets at runtime

With the decrypted .secrets.json file is in place, you can use Symfony’s EnvVarProcessors to read it. Consider this:

parameters:
    env(SECRETS_FILE): '.secrets.json'
    mysql.password: '%env(key:mysql_password:json:file:SECRETS_FILE)%'
    some_api.token: '%env(key:another_token:json:file:SECRETS_FILE)%'

This gives you two parameters %mysql.password% and %some_api.token% that you can use in your application and container definition, just like in the opening example.

Since we’re using the %env(…)% syntax, the values are not compiled into the Dependency Injection container. Yet, you can still warm the Symfony Cache during CI and ship Docker images with it.

More sophisticated secrets management

In fact, the second half of this approach – accessing the secrets at runtime through %env()% in Symfony – is independent from how you get the secrets there.

The eyaml -based approach outlined above works nicely for the use case we initially discussed. It's a low-barrier approach when you want to keep the secrets in the code repository itself and trust your production machines enough to have the plain secrets lying around in files.

If you want to take a more comprehensive approach, tools like Docker Secrets, Hashicorp's Vault or something from your PaaS provider are definitely the way to go. 

Docker Secrets will provide decrypted secrets as files in a memory-based filesystem mounted into a particular container. So, in the case of crashes, there is not even a file left on the disk. I am sure Vault can do something similar.

As  %env()%  is evaluated at runtime, you can also do fancy things like automatically rotating your secrets every day. Whatever tool you need for this, it does not need to do anything special with your already-running application.

You might want to note that the above approach is not limited to a single file. Use several files, for example when secrets need to be updated by different tools.

By using an environment variable that points to the secrets file, you can change the path to that file at deployment time. So, you could also come up with hybrid approaches: For example, have a plain text file that contains "default" database credentials on your development machine. On production, switch to a Vault-backed location with credentials that are rotated automatically.

Why not use env variables?

When we first engaged in the discussion this morning, my first question was „why not simply use environment variables for that“? After all, env vars are the recommended way of configuration for 12 Factor Apps.

However, as others noted already, env vars have a few downsides that make them less suitable for sensitive information. The main arguments brought are:

• Environment variables may easily be leaked. For example, they are contained in the phpinfo() output or can be part of ps process tables.

• Also, in the case of failures, environment variables are often included in dumps, reports or logs.

• Environment variables are inherited to child processes, for example when using the Symfony Process component. This violates the principle of least privilege. Also, it makes the previous point more important – for example when running other tools, you’d have to make sure that they don’t „leak“ the environment either.

• (New) developers might not even be aware that the environment contains sensitive data and thus not treat it with the necessary care.

Exposing secrets through files or, even better, through files in per-process memory filesystems does not have any of these drawbacks.

Closing remarks

I have a pending Symfony PR that adds a new require EnvVarProcessor type. With that, you can have a PHP script that will be executed at runtime every time the container is booted.

This PHP script can then return the value that will be used in the configuration.

You can use that to return array structures that will even be cached in the PHP opcache. Should your secrets file end up in the document root, chances are that fetching a .php file does not reveal anything to the outside.

On top of that, the fact that it’s just plain PHP opens up new ways of creatively fetching API tokens and secrets from somewhere .

Zuallererst muss man wissen, dass ich zwar in Bonn geboren, aber in Ostbüren, einem kleinen Dorf in der Nähe von Unna, aufgewachsen bin. Wie ich trotzdem zu einem Praktikum in Bonn gekommen bin? Das geschah über mehrere Ecken und eher zufällig. Ein Freund meines Vaters hatte erfahren, dass mein zukünftiger Berufswunsch in die Richtung der Mediengestaltung ging. Da er gut mit Stefan befreundet ist, konnte ich so den Kontakt zur webfactory herstellen und nach einem kleinen „Praktikums-Bewerbungsgespräch“ stand fest, dass ich im Februar 2018 mein Praktikum bei der webfactory in Bonn bestreiten durfte. Nachdem sich der Januar 2018 dem Ende neigte, wuchs meine Vorfreude immer mehr, das Team und die Arbeitsatmosphäre kennenzulernen.

Was ist eigentlich Webentwicklung?

Da ich zuvor nicht wirklich mit Webentwicklung in Kontakt gekommen war, ging ich naiverweise davon aus, dass man eine Website folgendermaßen erstellt: einfach ein paar Blöcke in eine leere Website ziehen, diese mit einer benutzerfreundlichen Oberfläche nach Lust und Laune gestalten, sie anschließend mit Inhalt bestücken und sie dann einfach „im Internet“ speichern. Eben so, wie es die tollen Werbungen von diversen Homepage-Baukasten Websites versprechen. Ich sah also nicht gerade eine Herausforderung darin, eine Internetpräsenz zu erstellen. Jedoch sollte ich feststellen, dass diese einfache Welt so nicht existiert… 

Jeder, der sich mit meiner naiven Ansicht identifizieren kann, darf nun einen kleinen Einblick in die Komplexität der Webentwicklung werfen: Hier ist ein kleiner Ausschnitt von unserer Website.  

Wer sich nun fragt, was der ganze Text im Bild 2 zu bedeuten hat: So sieht ein recht simpler Code-Ausschnitt aus, welcher später vom Browser gelesen und, wie im Bild 1 zu sehen dargestellt wird.

Laufen lernen

Da das Thema Webentwicklung für mich etwas grundlegend Neues war, musste ich zunächst die Basics kennenlernen, weshalb mir CodePen und ein paar Bücher zum Thema ans Herz gelegt wurden. CodePen ist eine Online-Community zum Testen und Zeigen von HTML-, CSS- und JS-Codeschnipseln. Man kann direkt im Browser in einem Editor Code schreiben, welcher in einem zweiten Fenster daneben vom Browser interpretiert wird. Man bekommt also sofort ein Feedback und kann somit lernen, wie sich der Code verhält. Durch CodePen bekam ich einen seichten Einstieg in das Thema Webentwicklung und konnte ein rudimentäres „Verständnis“ (falls man das so nennen darf) aufbauen, wie HTML und CSS zusammen spielen, um eine Website zu strukturieren und zu gestalten. Somit habe ich zunächst Tags wie <html><body><header><div><h1><p><ul> und <li> kennengelernt. Meine erster Versuch sah so aus: 

Es war genau an diesem Punkt, wo ich mental zwischen

und

stand. Es überwog dann aber doch letzteres.

Anschließend nahm ich mir das Buch „Resilient Web Design“ von Jeremy Keith vor, in dem es um die Entstehungsgeschichte des Internets und um grundlegende Herangehensweisen, wie man Webseiten flexibler und widerstandsfähiger machen kann, geht. Doch was mir am meisten im Kopf hängen geblieben ist, ist ein Zitat von Sir Isaac Newton: „If we have seen further it is by standing on the shoulders of giants.“ In anderen Worten: wenn unser Wissen durch Generationen weitergegeben wird, werden Theorien verfeinert, Maßeinheiten standardisiert und präzisere Experimente durchgeführt. Wir wären heute nicht an dem selben Punkt, wenn nicht das Wissen von früheren Generationen weitergegeben worden wäre. Diese Denkweise kann man auch auf die Webentwicklung übertragen. Das Web ist in einem ständigen Wandel und wird, solange wir unser Wissen weitergeben, auch in diesem Wandel bleiben.

Da in der webfactory mit GitHub gearbeitet wird, konnte ich mir mit TryGitHub einen guten Einblick in ein sogenanntes „Version Control System“ (VCS) verschaffen. Da die interaktive Webanwendung einem die Schritte spielerisch beibringt, sind die Basics leicht zu verstehen. 

Ein VCS bringt viele Vorteile mit sich. Es dient zur Erfassung von Änderungen an z.B. Dokumenten oder Dateien. Jede Veränderung wird mit einem eigenen Versionsstempel versehen und in einem Archiv gespeichert. Somit kann man zu jedem Zeitpunkt auf eine ältere Version zugreifen, um z.B. Fehler, welche bei einer Änderung aufgetreten sind, zu beheben. Gerade aus dem Bereich der Webentwicklung ist ein VCS nicht mehr wegzudenken. 

Da ich nun ein wenig mehr mit dem Thema Webentwicklung vertraut war, wurde mir das Buch „Responsive Webdesign“ von Christoph Zillgens an die Hand gegeben. Wie der Titel schon verrät, geht es um responsives Webdesign. Aber was ist das?

„Responsive Webdesign“ ist eine gestalterische und technische Denkweise zur Erstellung von Websites. Grundsätzlich geht es darum, eine Website für jedes nur mögliche Endgerät optimal darzustellen. Früher war es üblich, eine Website einfach für zwei bis drei verschiedene Bildschirmgrößen zu erstellen. Jedoch gibt es mittlerweile unfassbar viele Größenvarianten, weshalb man eine Website nicht mehr mit festen Breitenangaben, sondern mit flexiblen Variablen designed.

Wenn man mit Responsive Webdesign arbeitet, wird man schnell über Begriffe wie „Mobile First“ oder „Desktop First“ stolpern. Beides sind Methoden, wie man eine Website gestalten kann. Im Fall von „Mobile First“ beginnt man, seine Website von der mobilen Ansicht aus zu gestalten. Dafür gibt es viele verschiedene Gründe. Ich habe hier drei Gründe aufgelistet, welche mir am wichtigsten erscheinen:

1. Durch den mangelnden Platz ist man daran gebunden, nur den wichtigsten Inhalt auf seiner Website darzustellen – somit vermeidet man schon in der Konzeptionsphase überflüssige Nebeninformationen. 
2. Zur Zeit gibt es 4,12 Milliarden Internet Nutzer. Davon sind 3,8 Milliarden Nutzer mit dem Smartphone im Internet. Das sind ~ 93% der User (Stand July 2018). Somit macht es mehr als Sinn, seine Website zunächst für eine mobile Ansicht zu gestalten.
3. Progressive Enhancement (auf deutsch „fortschreitende Verbesserung“) beschreibt die Vorgehensweise, eine Website so zu gestalten, dass sie auch unter erschwerten Bedingungen, wie z.B. auf alten Smartphones (mit wenig Leistung), in veralteten Browsern, trotz schlechtem Netzempfang etc. so funktioniert, dass User ihre Bedürfnisse befriedigen können (Zeitungsartikel lesen, Formular abschicken, …). Danach verbessert man die UX (User Experience) dieser „Basisversion“ für Geräte, Browser und Situationen, die mehr Möglichkeiten unterstützen und erlauben. 

Beim „Desktop First“ läuft es genau andersherum. Hier beginnt man aus der Desktop Ansicht heraus, seine Website zu gestalten. Obwohl auch sinnvolle Argumente für „Desktop First“ sprechen, ist meine persönliche Vorliebe der „Mobile First“ Ansatz.

Meine Portfolio Website

Wireframes

Da ich nun einen Grundschatz an Informationen zum Thema Webentwicklung besaß, konnte ich endlich mit der Entwicklung meiner eigenen Website beginnen. Zunächst musste die Frage geklärt werden, was meine Website beinhalten sollte. Da ich in meiner Freizeit gerne zeichne und mit Photoshop experimentiere, stand schnell fest, dass es in die Richtung einer Portfolio-Website gehen sollte. Nachdem diese Entscheidung feststand, fing ich damit an, s.g. Wireframes anzufertigen. Wireframes sollen dazu dienen, eine Struktur für eine Seite festzulegen, ohne sich dabei von Designelementen wie Farben und Bildern ablenken zu lassen. Jedoch waren in meinem Kopf tausend Ideen von tollen animierten Diagrammen und außergewöhnlichen Formen, die mit Funktionen belegt werden könnten, sodass ich nicht bei dem Erstellen einer Struktur blieb, sondern sofort begann, mir Gedanken über Dinge zu machen, welche noch weit entfernt lagen. Doch mit Hilfe von Stefan konnte ich drei Wireframes zu Papier bringen, welche mir im späteren Erstellungsprozess meiner Website sehr halfen. 

Im nächsten Schritt begann ich zunächst, ein Logo und Icons für meine Website zu erstellen. Dabei half mir ein Artikel namens „The Ultimate Guide to a Flat Icon Set“. Muzli ist ein Blog, der viele nützliche Tipps zu digitalem Design und UX veröffentlicht. Mit Hilfe von Stefan und dem Artikel konnte ich mein erstes Icon Set erstellen, welches sich aber im Laufe des Designprozesses meiner Website noch mehrere Male verändert hat. 

Responsive

In dem zuvor erwähnten Buch „Responsive Webdesign“ ging es um den responsiven Aspekt einer Website. Dieser durfte natürlich auch in meiner Website nicht fehlen. Deshalb sollte ich mich noch eingehender in das Thema Media Querys einlesen. Nach kurzem Durchstöbern des Internets konnte ich damit beginnen, meine Website mit Media Querys für mehrere Endgeräte zu optimieren.

Inhalte integrieren

Nachdem ich meine Website für verschiedene Endgerätgrößen optimiert hatte, war es an der Zeit, meine Inhalte einzufügen. Mit Hilfe des so genannten „Masonry Layout PlugIns“ konnte ich meine Bilder auf eine schöne Art und Weise darstellen. Dieses Layout findet man z.B. bei Pinterest oder folgenden Seiten: Kristian Hammerstad, Loading Effects for Grid Items. Masonry sortiert Objekte wie Bilder nach ihrer Größe, sodass möglichst keine Lücken entstehen. Außerdem bringt dieses PlugIn großartige Lade-Effekte mit sich, wie man im letzten Beispiel sehen kann. 

Farbpalette

Der nächste Schritt auf meiner Liste sollte mir noch schlaflose Nächte bereiten… 

Die große Frage der Farbpalette stand im Raum. Mit Hilfe von verschiedenen Seiten, wie z.B. Pigment und Coolors konnte ich sehr schnell Farbkombinationen finden, was sich sowohl Segen als auch Fluch herausstellte, da ich nicht mehr aufhören konnte, neue Farbpaletten zu generieren. Ich hatte schnell ungefähr 16 verschiedene Farbkombinationen, welche mir alle gefielen. 

Mein typischer Arbeitsablauf bestand daraus, dass ich mich vormittags mit Stefan oder Søren zusammensetzte und überlegte, welche Features oder Verbesserungen ich im Laufe des Tages umsetzen wollte. Häufig bekam ich hilfreiche Tipps zur Hand und konnte bei Fragen immer einen Ansprechpartner finden. 

So stand ich nun da mit meinen 16 verschiedenen Farbpaletten, und jedes Mal, wenn ich mit Fragen zu den beiden kam, hatte ich eine andere Farbpalette auf der Seite implementiert, was die beiden sichtlich zur Verzweiflung brachte!

Natürlich konnten sie mir auch bei diesem Problem weiter helfen. Ich bekam den Blogartikel „V6-Color“ an die Hand, in dem Rob Weychert (ein Künstler und Designer aus Brooklyn, NY) beschreibt, wie man das Problem mit der Farbauswahl lösen kann. Seine Idee ist es, die Website zunächst einmal nur mit Grauabstufungen zu designen, um so zu erkennen, welche Bereiche akzentuiert werden sollen. Anschließend kann man dann eine Farbpalette darüberlegen, welche die selbe Priorisierung von Farben hat. Man verhindert so, dass zu viele Objekte auf der Website durch Farben hervorgehoben werden und miteinander in Konkurrenz treten.

Typografie

Nun war es an der Zeit, sich mit dem Thema Typografie zu beschäftigen. Noch nicht ganz ausgesprochen, lag auch schon ein 400 Seiten schweres Buch vor mir, mit dem Titel „Detailtypografie“ von Friedrich Forssman. Zuvor hätte ich nie gedacht, dass man sich so viele Gedanken zu Schrift machen kann. Zugegeben war ich damit auch dezent überfordert, weshalb ich mir mit der Hilfe von Google Fonts ein schönes Schriftarten-Pärchen (zwei aufeinander abgestimmte Schriftarten) aussuchte und es anschließend in meine Seite einband.

Veröffentlichung

Da sich meine Praktikumszeit langsam dem Ende neigte, durfte einer der wichtigsten Schritte natürlich nicht fehlen: Das Veröffentlichen! 

Mittlerweile konnte sich meine Website sehen lassen. Ich war selber von dem Resultat begeistert und erstaunt, was man in vier Wochen ohne Anfangswissen auf die Beine stellen kann. Somit war es an der Zeit, meine Website über GitHub Pages im Internet zu veröffentlichen. GitHub Pages ist ein kostenloser Dienst, um statische Websites zu hosten. Nachdem dieser Schritt ebenfalls abgehakt war, musste ich natürlich meine Website sofort mit dem Smartphone aufrufen! 

Es war ein magischer Moment für mich, meine Arbeit von über vier Wochen endlich, im wahrsten Sinne des Wortes, in den Händen halten zu können. Die eigene Website über sein Smartphone aufzurufen fühlt sich einfach großartig an. 

Parallel zu meiner Freude tauchten noch die ein oder anderen Schönheitsfehler auf, welche zuvor von mir nicht abzusehen waren. Diese wurden natürlich dann noch schnell behoben.

Und so sieht meine Website nun aus: https://dermeier.github.io/portfolio-website/ 

Die Überraschung

Schon zu Beginn des Praktikums war ich gefragt worden, wie meine zukünftigen Pläne aussähen. Tatsächlich war ich auf der Suche nach einem Ausbildungsplatz im Bereich Mediengestaltung. Zufälligerweise suchte die webfactory noch einen Auszubildenden für das Jahr 2018. Daher wurde mir der Vorschlag gemacht, dass man nach dem Praktikum einmal schauen könnte, ob sowohl die webfactory als auch ich mir eine Ausbildungsverhältnis vorstellen könnte. An meinem vorletzten Tag wurde ich dann zu einem kleinen Gespräch gebeten. Mit einem Kaffee in der Hand erwarteten mich Stefan und Søren, um mit mir das Praktikum zu rekapitulieren. Doch wir kamen recht schnell zu dem Punkt, an dem Søren sagte: „Ich habe ein gute und eine schlechte Nachricht! Die gute Nachricht ist: du darfst gerne deine Ausbildung bei uns anfangen! Die schlechte Nachricht ist, dass du dann auch im alltäglichen Wahnsinn der Webentwicklung steckst.“ Ich denke, es ist nicht nötig zu erwähnen, wie sehr ich mich über diese Nachricht gefreut habe! 

Am liebsten hätte ich noch am selben Tag den Vertrag unterschrieben, zuvor mussten aber noch ein paar organisatorische Dinge geklärt werden. Wie anfangs schon erwähnt wohnte ich nicht in Bonn und ein tägliches Pendeln von insgesamt fünf Stunden wäre nicht möglich gewesen. Doch nach ausgiebiger Absprache mit meinen Eltern stand fest, dass ich nach Bonn ziehen würde. Infolgedessen konnte ich meinen Vertrag einige Woche später unterschreiben! 

Mein letzter Tag

Am letzten Tag des Praktikums erstellte ich eine Präsentation, welche ich dann nach dem Mittagessen dem ganzen Team präsentierte. Zu meiner Überraschung wurde mir als Abschiedsgeschenk ein Buch über die Geometrie des Designs überreicht. 

Schneller als ich es erwartet hätte, hieß es nun, im wahrsten Sinne „Auf Wiedersehen“ zu sagen.

Fazit

Abschließend kann ich sagen, dass die Zeit bei der webfactory großartig, herzlich und informativ war. Ich habe in den vier Wochen so viele neue Sachen gelernt ohne überhaupt zu bemerken, dass ich sie lerne. Ebenso hat der Aufenthalt meine Interessen so erweitert, dass ich das neu entdeckte Interessenfeld nun zu meinem Beruf machen möchte/werde. Bei der webfactory fühlt man sich einfach wie Zuhause!

Ich habe wirklich keine Ahnung mehr, wie ich eigentlich ursprünglich auf die Idee gekommen bin, dass ein Hund eine tolle Sache wäre. Vielleicht war es auch eher so herum, dass es mir vorher schlichtweg nicht in den Sinn gekommen ist, weil es unmöglich gewesen wäre, einen Hund an meinem alten Arbeitsplatz (ein Forschungslabor) zu integrieren. Ein Bürohund hingegen gehört ja mittlerweile fast schon zum guten Ton – und während ich so gedanklich an meiner Idee feilte (Hundebilder anschauen, Hundevideos gucken, Hundebücher lesen… man steigert sich da ja so rein mit der Zeit…), reifte in mir auch die Überzeugung, dass die webfactory die perfekte Bürohundefirma wäre. Allein schon, weil uns Mitarbeiter*innen ja doch eher selten ein (realistisch umsetzbarer) Herzenswunsch abgeschlagen wird. Ich war mir dann auch einigermaßen sicher, dass meinem Vorschlag kaum jemand würde widersprechen können, denn ich hatte mir einen sehr guten Plan zurechtgelegt: Es würde kein so richtiger Hund werden, sondern nur ein Pflegehund. Ein Bürohund auf Zeit also. Das hielt ich auch privat für eine gute Idee, denn ich wollte mich auch nicht so gerne direkt ein ganzes Hundeleben lang verpflichten, ohne zu wissen, ob mir das mit dem Vierbeiner überhaupt so gut gefallen würde und ob meine Lebensumstände über Jahre hinweg die Betreuung eines Hundes zulassen würden. Ein Pflegehund hingegen schien mir die win-win-win-situation zu sein: Win-1 und 2 für die Firma und mich, die keine Entscheidung für immer treffen müssten, sondern in Ruhe ausprobieren könnten, und win-3 für den Hund, der bei mir würde leben dürfen, bis er seine Adoptivfamilie gefunden hätte, anstatt im Tierheim auf sie warten zu müssen. 

Die Entscheidungsphase

Als die Idee also lange genug gereift war (und ich das Gefühl hatte, dass mein Jobstart ausreichend lange zurücklag um nicht zu sehr mit der Tür ins Haus zu fallen...), habe ich schließlich eine Mail ans Team geschrieben und meinen Wunsch erklärt. Ich wollte, dass sich alle ganz in Ruhe und in ihrem eigenen Tempo Gedanken zu dem Thema machen konnten, bevor wir in der großen Runde darüber reden. Und natürlich bot so eine Mail auch ausreichend Raum, um auf sämtliche Studien zu verlinken, die zeigen, wie gut sich die Anwesenheit von Hunden am Arbeitsplatz auf die Mitarbeiter*innen auswirkt. ;-)

Der in den nächsten Wochen folgende "Kampf" war kein großer, aber es mussten schon einige Gespräche geführt werden. Einige Mitarbeiter reagierten vollkommen begeistert, anderen war es relativ egal. Ein Mitarbeiter machte sich Sorgen um seine schwelende Hundeallergie, ein anderer machte sich große Sorgen um alles Mögliche (Haare auf dem Teppich, unangenehmer Geruch, Postboten verbellen, „Den gibst du doch nie wieder ab“ etc.). Auch die Unabsehbarkeit der Länge des Experiments war ein Thema. Zu meiner großen Freude erhielt ich auf meinem Weg allerdings auch Unterstützung von der hundebegeisterten Fraktion im Team: Somit tummelten sich plötzlich auf mysteriöse Art und Weise eine große Anzahl an niedlichen Hundebildern in unseren Testfotos oder es wurden ganz unauffällig Tüten voller Hunderleckerlis im Sichtbereich der Skeptiker deponiert. Ich gab mir unterdessen Mühe, allen genannten Sorgen einen passenden Lösungsvorschlag entgegenzusetzen. So versprach ich beispielsweise, mit dem Vierbeiner für die Dauer seines Besuchs in unseren Meetingraum auf der anderen Straßenseite umzuziehen, falls er sehr stören würde oder irgendjemand wirklich schlimme Allergieschübe hätte. Es hat ein Weilchen gedauert, doch letzten Endes waren alle Fragen geklärt, alle Hürden überwunden und so zog im Februar schließlich die weiße Wuschel-Hündin Blanca bei uns ein.

Ein Hund zieht ein

Ich glaube, die Zeit mit Blanca war für mich privat deutlich aufregender als für die Kollegen auf der Arbeit. Blanca war eine liebe Hündin, die auf der Arbeit meistens brav auf ihrem Platz lag, gerne Stofftiere zerkaute, und deren einzige offensichtliche Macke darin bestand, mir auf Schritt und Tritt nachzulaufen. Angst und Bange wurde mir kurz, als sie den Serverraum mit der Hundewiese verwechselte und eine nasse Pfütze auf dem Teppichboden hinterließ – und als sie dann auch noch Durchfall bekam, der auf selbigem landete. Doch zu meiner großen Überraschung lösten die Teppichunfälle keine Krise in der Firma aus und letzten Endes hatte ich sogar das Gefühl, die einzige zu sein, die das richtig schlimm fand. Auch die restlichen der zuvor geäußerten Sorgen lösten sich in Luft auf: Blanca bellte nicht, zerkaute keine Möbel, stank auch nicht unangenehm (Profitipp: Hund baden!) und niemand erlag einem Allergieschock. Insgesamt blieb Blanca bloß für zwei Wochen und dann zog sie auch schon wieder aus. Das darauf folgende Teamfazit zum ersten Hunde-Experiment fiel insgesamt positiv aus. Das wichtigste: Die Skeptiker hatten ihre Meinung geändert und fanden das Büroleben mit Hund doch gar nicht so schlimm. Ganz ohne lange Umschweife stimmten dann auch direkt alle zu, dass ich noch einmal einen Pflegehund mit zur Arbeit nehmen dürfte – immerhin war ich ja auch fast ein bisschen traurig, dass Blanca uns so schnell wieder verlassen hatte. Und so zog nur kurze Zeit später Nico bei uns ein. 

Noch ein Hund zieht ein

Auch wenn Blanca schon brav war, übertraf Nico sie sogar noch. Auf der Arbeit tapste er ab und an friedlich durch die Räume, schlief die meiste Zeit des Tages in irgendeiner Ecke, war — selbst mit Durchfall (warum haben Hunde eigentlich ständig Durchfall???) — vorbildlich stubenrein und eigentlich nahm man ihn nur so richtig wahr, wenn er ab und an empört herumwuffte, weil er etwas zu essen haben wollte. Es sah fast so aus, als würde auch Nico nach kurzer Zeit adoptiert werden, doch dann stellte sich heraus, dass er einen Herzfehler hat und deswegen wohl kaum noch Chancen, eine Familie zu finden. Und somit blieb Nico. Bis heute. Besonders schön fand ich es zu sehen, wie die Gespräche über sein für-immer-bleiben im Vergleich zu den ersten Hundegesprächen abgelaufen sind: Während wir am Anfang über mehrere Wochen Unterhaltungen geführt haben, war die Entscheidung darüber, dass er bleiben darf, nach einer Weile des Austestens dann blitzschnell gefallen: Eine Runde, jeder durfte seine Meinung sagen und nach einer Minute war das Ding durch. 

Status heute

In der Firma hat Nico mittlerweile etliche Fans gefunden und dreht tagsüber seine Runden durch die Büros, um sich von einem nach dem anderen durchkraulen zu lassen. Als ich über das Wochenende verreist war, durfte er sogar schon einmal bei einem Kollegen übernachten, ein anderer war schon mit auf der Hundewiese und immer mal wieder fallen Sätze wie: „Ich finde es einfach schön, wenn wir ein Teammeeting haben und Nico legt sich zu uns.“ Unter seinem Pseudonym „Obi-Wau Kenobi“ hat Nico sogar mittlerweile seinen eigenen Teamavatar und einen Eintrag in der Mitarbeiter-Sektion unserer Website. Während die Hundeallergiker sich eingangs noch eher von ihm ferngehalten und nach jedem Kraulen die Hände gewaschen haben, ist auch das mittlerweile passé und selbst die Hundeskeptiker haben hier und da mal ein paar Streicheleinheiten übrig. Soweit ich das beurteilen kann, haben sich alle Sorgen des Teams mittlerweile in Luft aufgelöst und ich kann jeder anderen Bürogemeinschaft somit nur ans Herz legen, das Experiment einfach mal selbst zu wagen, statt sich zu sehr in was-wäre-wenn-Gedanken und Ängsten zu verstricken.

Und über die Arbeit hinaus? Nun, der arme Nico hat wirklich ganz laut „Hier“ gebellt, als die Hundekrankheiten verteilt wurden. Zu dem Herzfehler kamen mit der Zeit immer mehr Diagnosen und Behandlungen dazu. Glücklicherweise geht es Nico dank medizinischer Betreuung mittlerweile richtig gut. Zugegebenermaßen: Hätte ich mich anfangs direkt für einen eigenen Hund entschieden, wäre es wohl kaum ein alter, kranker Hund aus dem Tierheim geworden, sondern vermutlich ein Welpe vom Züchter – aber jetzt bin ich sehr froh darüber, dass es eben Nico geworden ist und glaube wirklich nicht, dass ich mit einem anderen Hund glücklicher wäre. Wie eingangs angedeutet, hätte ich mich auch von selbst vermutlich nicht so bald getraut, einen Hund für immer zu mir zu nehmen und bin ganz froh, dass das Schicksal mir da einen kleinen Schubs gegeben hat.

Noch ein Hund zieht ein?

„Wir sollten mehr Bürohunde haben“, sagte vor einiger Zeit ein Kollege ganz unbedarft, beim Mittagessen. Im Nachhinein könnte man meinen, dass diese Aussage vielleicht prophetischer Natur war, denn seit kurzem liebäugelt der nächste im Team mit der Adoption eines Vierbeiners. Wie es ausschaut, sind unsere Fellknäule also bald zu zweit und beim Mittagessen kann es nun schon einmal vorkommen, dass wir über Hunderassen und Welpenerziehung diskutieren. 

Ist dies also die Geschichte einer Firma, in der plötzlich nur noch Hundefans arbeiten und in der selbst der letzte Hundeskeptiker sein Herz an die Vierbeiner verloren hat? Keinesfalls! Nach wie vor gibt es unter uns hundebegeisterte und weniger hundebegeisterte Teammitglieder. Was unser Experiment aber gezeigt hat ist, dass wir eine Firma sind, in der die Bedürfnisse und Wünsche einzelner ernst genommen werden, in der wir miteinander reden, uns auf Experimente einlassen und bereit sind, unsere Meinung zu ändern. Zwar mögen nicht alle von uns ganz persönlich Lebensfreude daraus ziehen, dass es Nico gibt, doch haben alle mal mindestens festgestellt, dass er sie nicht stört und waren bereit, von ihrer ablehnenden Haltung Abstand zu nehmen. Und das ist auf jeden Fall einer der Gründe, warum ich sehr froh darüber bin, in diesem Team zu arbeiten. ♡

Falls jemand von euch lieben Leser*innen auch gerne einen Hund mit ins Büro nehmen möchte und Fragen hat oder sich einfach so für das Thema interessiert, wendet euch doch einfach an mich via: info@webfactory.de