This “bookmarking” format doesn’t seem to be working for me because of the way I am doing this. It also seems that I am bookmarking more and more things and I leave all the bookmarks to the last days of the month. I feel like I don’t have enough time to give them proper treatment. I want to share my favourite quotes and my opinions on them and this method seems rushed. I might go back to my original plan of doing them every two weeks.

I have also decided to split between tech and non-tech related articles because I feel that the amount should be the same (and it currently isn’t).

Also this month went by too quickly. Too quickly.

Bookmarks from March

Non-tech articles

• Volunteering in orphanages - by Unicef.
• I Found the Best Burger Place in America. And Then I Killed It. - by Kevin Alexander
• The Weight of Words: Self-Acceptance Doesn’t Have to Be a Solo Journey - by Nicole Zhu
• The Poor Can’t Afford Not to Wear Nice Clothes - by Tressie McMillan Cottom
• You don’t need more than a warm smile to fly with babies… - by Eva Wiseman
• Journey of a Fashionable Minimalist: Episode 3 – Discovering minimalism - by Georgie Luhur Cooke
• Sorry to bother you, but do you say “sorry” too much? What to say instead - by Daniella Balarezo

Tech related content

• Content-based grid tracks and embracing flexibility - by Hidde de Vries
• Having an open dialog - by Scott O'Hara
• CSS Shapes Resources - by Kristopher Van Sant
• Fighting uphill - by Eric Bailey
• Help! None of my projects want to be SPAs - by Jason Goldstein
• Building Intelligent Layouts with CSS Grid - by Michelle Barker
• Web Accessibility Guide - by Stefan Fejes
• CSS Specificity - by Estelle Weyl
• How I Started Reading mix-blend-mode and What They Are Creating with It - by Wei Gao
• The web we broke. - by Ethan Marcotte
• Accessibility Insights - by Microsoft
• Colourise.sg - by Andrew Tan, Preston Lim and Tan Kai Wei
• Tinkersynth - by Josh Comeau
• Layered parallax effect - by Thea
• How to design an accessible color scheme - by Katie Riley
• CSS Scroll Snap: How Do I Look In This? - by Olivia Ng
• JS Paint - by Isaiah Odhner
• React fragments - by Sarah Chima
• CSS Grid: Floor Plan - by Olivia Ng
• An introduction to web components - by Caleb Williams
• Accessible Brand Colors - by Use All Five
• Offline Homebrewing - by Benjamin Parry
• Always Own Your Platform - by Sean Blanda
• Ctrl-Alt-Delete: The Planned Obsolescence of Old Coders - by A. Jesse Jiryu Davis
• Becoming a tech speaker - by Michelle Barker
• An Introduction to Static Site Generators - by Eduardo Bouças
• Making Generative Music in the Browser - by Alex Bainter
• Piccalili - Issue 1 - by Andy Bell

Things that made me smile one way or another

• Developurrs - #013 - Ana Rodrigues with Jessie - by Andy Bell and me

A while back someone I know that has a role in a product team (so, not a developer) showed me their brand new feature. Because I had just been working on a similar feature I decided to see how they were doing the keyboard navigation of that feature (because I wanted to learn and improve mine). They weren’t. So it wasn’t accessible. At the time, it wasn’t possible to see the contents of that feature using the keyboard at all.

I reported back to them and explained what happened when I used it and their reply was something along the lines “that’s a disappointment - I expected our developers to do better”. They took the feedback and improved it. When I heard their disappointment with their team, it reminded me of a quote from Mindera’s culture book that stayed with me: “It’s everyone’s job”. And I try, sometimes fighting my own blind spots, to apply it whenever I can.

An unaccessible feature will go live when any of these steps fails:

• The client/product/tickets don’t mention it in their requirements;
• It is designed without accessibility in mind;
• When the code developed isn't accessible;
• When in the code review it isn't flagged;
• When the accessibility of a feature isn’t tested in the testing environments;

At any moment, anyone in team can flag that something is missing, broken or can be improved. Everyone reads the tickets/acceptance criteria, everyone sees the designs, someone develops but someone reviews the code, everyone testes it (and most of the times, they will use the ticket’s acceptance criteria as a reference of what to test).

It is important to be everyone’s job because no one is perfect. Because mistakes can be made but mostly because we are all learning. In every single mentioned step there could be someone who just started that particular role, for example, and they will learn from these interactions and it will become part of their routine for their next tasks.

Apply the "it's everyone's job" where you can and everyone in the team will learn a skill for the future.

Big mood. Taken today at the march.

🦖