Thirty Four

Today I’m still three years away from another prime birthday, but this is my ninth semiprime birthday and my ninth Fibonacci birthday.  That last Fibonacci birthday was a bit of a bigger deal though.

I didn’t publish my post about thirty-three. I spent the day fairly exhausted after having my brother visit, and for a while when I get exhausted I tend to get fairly down emotionally. I need to get better with sleeping. Maybe I’ll try that as a thirty-four-year-old.

As a thirty-three year old, I really threw myself into making art. I painted, I drew, I burned wood.  I often struggle to love anything I create, but every once in a while I do. Lately, I’ve mostly been doing watercolor sketching in bars, painting with a brush attached to a Dremel, and burning small pieces of wood. It’s fun to experiment with things that are so different than how I spend my days. It’s important to step away from the computer. I’m glad I found an outlet for me to do that in 2016.

Professionally, thirty-three was the year I was honored with the opportunity to be the deputy lead of a WordPress release. Helping do that will forever be an important accomplishment and one of my most important contributions to WordPress.  I also switched jobs (again), moving back into media and publishing. I’ve also added to new events to my volunteer schedule, taking a (broader) role in WordCamp US and being a part of the inaugural team around WordCamp for Publishers. The role I have as a part of the Model UN I help organize has evolved yet again and I’ve switched into a senior staff role that is less focused on the day to day running of a department and is now completely focused on photography, technology, and helping where it is needed during the actual event.

Thirty-three had challenges. Every year does. These challenges won’t magically go away with me turning a year older. Today is really just another day, it just happens to be the anniversiry of the day I was born.  So I guess I’ll drink to that. 🍻🥂

Aaron’s Rule for Better Meetings #6

An addendum to my initial list of rules for better meetings.

  1. All Meetings where product decisions get made need to include a designer and an engineer. It’s important to provide multiple perspectives when making product decisions, and none of those decisions should be made without engineering and design having an opportunity to explain their perspective on benefits and costs.

photo: used under a Creative Commons Attribution license. Original: #WOCinTech

We Use Way Too Many Fonts

Massimo Vignelli is most famous for designing the NYC Subway map. In this video, he speaks about typography, the history of fonts and argues that “There are good maybe a dozen (fonts)…I only really used three or four in my life.” He also argues that when designers are less good, they use more fonts. When they are really bad, they use them all.

Fonts also greatly affect the load time of web pages. Since most web fonts are almost always externally hosted, it’s even more important to be conscious of how many fonts you use. What would happen if we limited font choices more? What if you only could use Open Sans at two weights along with both the regular and italic versions. How would that affect what you designed?  Would it force you to use other differentiators?  Would color become more pronounced? Would size?

When one variable is taken away from the design process it doesn’t have to limit you; it can actually make your design more impactful.

MoMA uses a single font for the vast majority of the museum. However, it also designs a new font for each of its special exhibits. It makes each one stand out even more. Could single font websites do the same thing? When you write a really powerful essay you make your own font just for it?

Null Propagation Operator proposal for JavaScript

At it’s January meeting, TC39 (essentially the standards body responsible for JavaScript) heard a proposal for some syntactical sugar that really excites me.  It’s called the Null Propagation operator and allows code that looks like

const firstName = (message
&& message.body
&& message.body.user
&& message.body.user.firstName) || 'default';

to become code that looks like

const firstName = message.body?.user?.firstname || 'default';

Essentially, it allows for eliminating lots of checks to ensure multilevel JavaScript objects are properly defined. This reminds me a bit of the null coalesce operator in PHP as  it allows for easier to read code. It needs to be balanced so these languages don’t turn into Perl filled with secret operators.

The proposal is now in stage 1 which means that TC39 “expects to devote time to examining the problem space, solutions and cross-cutting concerns”. It’s still early to get excited about this, but this is one of those pieces of syntactical sugar that make writing code easier.

My One Icon

A few years ago, I needed an icon for something I was working on, so I opened up the noun project and started looking.  I couldn’t  find anything, so I set out to design my first icon.  What I came up with is my blood pressure icon.

The best part isn’t the emails every few months letting me know I made $0.40 (which I did in February), it’s seeing that for a few hundred people, my representation of blood pressure is how they want to represent blood pressure.

Screenshot of Nouns Project dashboard showing downloads of my icon

As someone who struggles at times to consider themselves a designer, it is reaffirming to see the icon used. If you happen to use it, please let me know.  I would love to see how it’s used by others.

Random Thoughts on my email norms

Over the years, I’ve sent a few thousand emails.  Less than some, more than others and I’ve developed a handful of normative behaviors in the process that others may find useful.

  • My default on a group conversation is to always reply all.  Communication is oxygen and I figure it is best to error on the side of overcommunicating.  People can always choose to self-filter.  I love that gmail includes an option to make reply-all the default. Everyone should set it that way.
  • If I don’t reply all, in the first line I will use a minus symbol so the rest of the chain knows who (if anyone) has been removed.
  • Concurrently, if I add people, I use a plus symbol so the rest of the chain knows as well.
  • The only time I use BCC is to remove someone who made an introduction, and I will state that they are being BCCed
  • I try to make the subject line clear and simple. The subject line should be evergreen (it should encompass the entirety of the conversation that needs to take place)
  • If it can all be said in the subject line, I’ll end it with EOM so people know they don’t need to open it.
    • This is less of an issue with chat programs like Slack being available.
  • I hate email signatures that are more than a line or two.
  • If my response can be said completely in emoji, you bet your ass I’m going to do it.
    • I do only use emoji for positive responses though.  No one wants to see 👎🏻 as the response to a request.
  • I try to avoid sarcasm.  It is much harder to be sarcastic in writing than it is in a higher fidelity form of communication.

What are your email norms? What email etiquette do you follow? Share it in the comments.

A WordPress without Woman.

If WordPress had no Woman contributors, 4.7 wouldn’t have had a release lead.
If WordPress had no Woman contributors, The queue for plugin reviews would rarely be empty.
If WordPress had no Woman contributors, many WordCamps would lack lead organizers, speaker wranglers and sponsor wranglers.
If WordPress had no Woman contributors, most WordCamps never would have been approved to be organized.
If WordPress had no Woman contributors, The REST-API never would have made it into core.
If WordPress had no Woman contributors, WordPress for Dummies never would have been written.
If WordPress had no Woman contributors, many support questions would go unanswered.
If WordPress had no Woman contributors, the training team wouldn’t have created lesson plans to help anyone teach WordPress.
If WordPress had no Woman contributors, most waapuu would never have been designed.
If WordPress had no Woman contributors, WordPress would be inaccessible to many people using assistive technology.
If WordPress had no Woman contributors, WordPress wouldn’t be fully translated in over 60 languages.

There is no area of WordPress that is untouched by the contributions of Woman. In honor of International Woman’s Day tomorrow, my friend Mika is participating in “A Day Without Women”. I support her and every other Woman of WordPress that chooses to do the same.

The theme for 2017’s International Woman’s Day is “Women in the Changing World of Work: Planet 50-50 by 2030”. While Planet 50-50 ignores the gender non-binary members of the world, it’s a phrase that aims to seek equal representation, recognition, and opportunity.

For my fellow men of the WordPress community, I encourage you to make sure a woman who’s work you appreciate is known tomorrow. Without the contributions of woman, WordPress would be worse off.

“My Code is Self-Documenting” — Eric Holscher 

Self-documenting code is one of the biggest documentation myths in the software industry. This view generally conflates documentation with code comments. I’d like to make two arguments in this post:

Code comments have value

Documentation has more value than just explaining how software works

Source: “My Code is Self-Documenting” — Eric Holscher – Surfing in Kansas