Feels like Spring

It’s been raining so much this winter that it wasn’t uncommon to spot the odd heron hunting in the temporary puddles in front of my house. A very strange break from the drought, but not unwelcome at all.

All the cold and the rain was perfect germination weather for a lazy gardener like me. It made it rather easy for the garden to sprout from seed directly in the bed. After planting I almost did nothing afterwards, since it was raining so frequently.

Now that it’s warming up, everything is blooming, which makes coding outside very tempting.

Work and other things

I work for Automattic a completely 100% distributed company with employees from all around the world. Once a year we hold the Grand Meetup, a frenetic week long event where the whole company flies in to blanket an unsuspecting off-season ski resort with our own wifi and friendly Automatticians.

It’s a crazy-fun experience, and one of the rare chances we get to see the folks we work with in person.

team

My awesome team

 

While at the meetup, I got a lot of enthusiastic thanks from folks for helping out on reviewing their pull requests. It was extremely flattering, but I also had the nagging thought of “Is it so unusual for cross-team reviews to happen?”

So Many Pull Requests

stack.gif

To give some more context, I primarily work on Calypso, an open source dashboard for reading, writing, and managing all of your WordPress sites in one place.

At any given time there are roughly 3-5 pages worth of PRs with a needs review label. This is pretty overwhelming. I can understand how easy it could be to have tunnel vision and only keep track of your teammate’s work.

To encourage folks to review a bit more, here’s a quick summary of how I break up my day:

Morning – review all the things!

I happen to work in the latest time zone on my team. This means that by the time I’m online, the rest of my team already has a number of in-progress or needs review PRs that are fresh and waiting for me. This is one of my only chances to chat with folks while they’re also awake, which makes it a great time to catch up with folks or have a live video hangout.

My morning time is very interrupt-driven, which is why this is also the best time of day for me to review my team’s PRs. I have a special email filter for Calypso pings. I try to run an inbox-zero approach here, but depending on current project needs I might not be able to get through all of them.

coffee.gif

Coffee and Breakfast is also very important

 

Afternoon – Coding

By the time I’ve finished lunch, the rest of my team should hopefully be relaxing as their day winds down. Slack is mostly quiet in my afternoons, aside from helping out with a random Calypso fire or two that may occur from time to time. I usually have a solid chunk of uninterrupted time, which is great for getting into the flow, loading a complex problem into your brain, and cranking out a decent approach to a problem.

I stop when I’ve hit a good point, where I’m pretty certain I won’t be dreaming about solving the issue in my sleep.

code.gif

Evening – Trash Pickup or Cross Team Reviews

After hitting a good point with my in progress issue, I usually have a little bit of time left in my day. To wind down, I might pick out a quick janitorial issue to hammer out, or more often I might peruse that giant list of PRs that need to be reviewed:

giphy-1.gif

But how to pick one?

Picking a PR to Review:

Here are some suggested approaches:

  • Take a look at one of the oldest PRs on the list. Ping the author with questions if it looks inactive.
  • If you don’t have a lot of time, choose a tiny PR to look at. These are the fastest to review and test, and usually have the least risk of causing a regression.
  • Choose something you’re unfamiliar with. Reviewing PRs is a great way to learn, and to keep a pulse of what’s happening on other teams. Don’t be afraid to dive into a section you’ve never looked at before. If you don’t follow, or something is unclear, ask questions! The PR author is usually happy to explain.

Always Waiting for a PR Review?

Do you always feel like you’re waiting for a review? A few tips:

  • Add context and reasons of what your PR is trying to achieve in the summary, so someone unfamiliar with the issues can hop in and help.
  • Add step-by-step testing instructions! This makes it easy for people to review your code.
  • Break down huge PRs into manageable chunks. Large diffs are incredibly hard to review and test, and it’s more likely that folks just don’t have that amount of time to sit down and attempt to understand the PR.
    • The might mean adding wip PRs with feature flags
    • Sorting out janitorial things, like updating code-styles into their own PRs
    • Do things in steps. For example, first creating a PR to add a new component, before using it on a page in a second PR
  • Take some time to review a few PRs! Other folks are waiting too!

Night – Relax!

Your day might look very different, but I find that interrupted time is great for PRs, and quiet time is incredible for coding.

Remember to take it easy though and not to overwork yourself. I personally try to work somewhat traditional hours and turn on a do-not-disturb mode on my phone for night time hours. This helps me from from getting sucked back into work mode too late at night. Other folks might be able to handle a much looser schedule, but I am not one of them. 🙂

Anyway, I hope this post was helpful! To my co-workers it was great seeing you at the Grand Meetup, and I can’t wait to see you all again!

bear.jpg

 

Sunday Roast

I visited London back in January and I was particularly fond of the Sunday Roast. This example is from Hawksmoor Air Street. The menu had a number of items, but just about every order out of the kitchen was this. No wonder though, the potatoes had a perfectly crisp crust, the yorkshire pudding was an excellent gravy delivery device, and the roast was spot on.

food.jpg

It was delicious.

I followed it up with sticky toffee pudding.

stickytoffee.jpg

Why didn’t that selector work?

CSS Specificity 

Ever get frustrated when a newly added CSS rule just doesn’t work? CSS specificity is how a browser determines which CSS properties will be applied to an element. If this is the first you’ve heard about this, don’t worry, a surprising number of engineers I meet don’t understand how CSS specificity works and can probably help explain why CSS naming conventions like BEM are so popular. (If you follow BEM, your score should typically never go past 0,1,0 or 0,2,0).

In a nutshell:

  1. The selector with the higher specificity score wins
  2. For selectors with the same specificity score, the last one wins (rule closest to the bottom of the stylesheet)
  3. Inline styles added to an element element overwrites any styles in the CSS
  4. !important will override all other specificity.
  5. If you have two matching !important rules, the last one wins.

How do you calculate specificity?

It’s actually pretty simple. CSS specificity is just counting. If you look at the specification:

A selector’s specificity is calculated as follows:

  • count the number of ID selectors in the selector (= a)
  • count the number of class selectors, attributes selectors, and pseudo-classes in the selector (= b)
  • count the number of type selectors and pseudo-elements in the selector (= c)
  • ignore the universal selector

Selectors inside the negation pseudo-class are counted like any other, but the negation itself does not count as a pseudo-class.

Concatenating the three numbers a-b-c (in a number system with a large base) gives the specificity.

Examples:

*               /* a=0 b=0 c=0 specificity =   0 */
LI              /* a=0 b=0 c=1 specificity =   1 */
UL LI           /* a=0 b=0 c=2 specificity =   2 */
UL OL+LI        /* a=0 b=0 c=3 specificity =   3 */
H1 + *[REL=up]  /* a=0 b=1 c=1 specificity =  11 */
UL OL LI.red    /* a=0 b=1 c=3 specificity =  13 */
LI.red.level    /* a=0 b=2 c=1 specificity =  21 */
#x34y           /* a=1 b=0 c=0 specificity = 100 */
#s12:not(FOO)   /* a=1 b=0 c=1 specificity = 101 */

Lets break that down a little bit further.

Concatenating the three numbers a-b-c (in a number system with a large base) gives the specificity.

ID Selectors > Class Selectors > Type Selectors

Here’s the tricky part. No matter how many type selectors you have, it’ll never trump a single class selector, and similarly no matter how many class selectors you have, it’ll never trump a single ID selector. Instead of using base-10, you can put a comma between each of the selector types.

So for example the top .foo selector cannot be overridden by a selector which only uses type selectors, no matter how many of them you add to your selector. For convenience, most folks will use base-10 since hopefully your CSS file doesn’t have selectors like this.

//specificity=0,1,0
.foo 
//specificity=0,0,11
html body div ul li span span span span span span 

What about inline styles?

Inline styles always overwrite any styles in the CSS. So the div in this case will be red, and this is true no matter how many id selectors we add to the css rule.

<div id="green" style="background:red;"></div>
#green {background: green;}

!important

In this case, our div actually will be green, despite the inline selector, or any CSS rules. It’s common knowledge to avoid using !important when you can use alternative means, because you’ll likely waste a lot of time for your future-self or your co-workers when you can’t override that important rule you just added.

<div id="green" style="background:red;"></div>
#green {background: green !important;}

When using !important is OK

That being said, !important is a tool and there are times when it’s acceptable to use it.

  1. Overriding Media Query Styles – Need to override a rule for a particular target screen-size? You can avoid this in some cases, but if you use a CSS framework like Bootstrap, you already have these rules in place.
  2. Utility Classes – Want that .pull-right to really stick to the right? !important. It’s easily arguable that you don’t need utility classes at all, but this is how you get them to work.
  3. Email Styling – Email styling is like stepping back in time. You use tables everywhere, clients have terrible CSS support, and sometimes the only way to override default client styling is by using !important.