A Letter To My Coworkers Concerning Peer Reviews

Every six months, we at Sparkbox do peer and leadership reviews. We’ve been at it for about two years now, so I have a feel for an approach to providing feedback to my coworkers. Following a conversation I wrote the following letter to my fellow Sparkboxers and dropped it in our #general Slack channel. After some positive feedback, I was further encouraged to share this letter, verbatim, with the world. Peer reviews can be tough, its giving feedback to coworkers in manner that can be a bit intimidating. This is a letter written as an encouragement to help prepare a good mindset for writing a peer review.

Alright y’all, here’s a quick little internal post on how I do peer reviews. It has taken some time and a lot of gleaning from others in the office. So, some of this may sound familiar, but perhaps this will help some of you.

Peer reviews can be super intimidating. When I started my very first peer review, I felt like I had to write these review for Ben and Rob to read. Later on I heard some one say they approach the peer reviews like they are telling the person directly. I’ve really taken that approach to heart. To me reviews have become a great way to reflect on why I like working with y’all and getting an opportunity to tell you why that is so freaking awesome. Think of the review you’re giving as though it were a conversation you are having with that person in the kitchen over some coffee and Oreos. Use emojis, make it fun, but be honest.

I got up this morning and went to Press to work on my peer reviews. After coming into the office I got talking to one of the folks I was reviewing, and I just had to tell them some the things I wrote done. Things that make me so excited to work with them. It turned into a beautiful and encouraging conversation.

The other intimidating thing about the reviews are the number scale questions. It’s hard to come at this without the thought that you are putting a numeric value on people you really like. My first review, I gave everyone max numbers, because you deserve it. But, as time has gone one I’ve adopted a number approach akin to Ben’s. I start with the middle number for everything. The middle number, to me, means you are doing a killer job. Above that, you are kicking some serious ass. If I ever feel like I need to give a number below the middle, I explain it in the comment. And like above, I try to approach it conversationally, I put myself in the mindset that I am sitting down face to face with the person. It brings a level of empathy and humility to the words you choose.

I love, love, love working with you all. The feedback I have received from past reviews have made me a better person and a better worker. I savor your feedback, and hope this helps you with overcoming any apprehension you may experience going into writing your reviews.

To give some context, our peer reviews consist of a handful of questions followed by two section that are number-based ratings. The first set is 1-10 rating on Fluency, Humility, and Empathy—the foundations of the company. The second set is a 1-6 rating on a myriad of aspects. Each section allows for an opportunity to explain the ratings, which I try to do. But, this is my chart for assigning the numbers in those sections:

1 (Loweset Rating)

I like you, but we should sit down and chat a bit. Something is up, I’m not sure if it is me, you, or what.

5 or 3 (Middle Rating)

You’re terrific and I love working with you. You are exactly as I’d hope you’d be.

10 or 6 (Highest Rating)

You are so effing awesome, I cannot contain myself. I’m going to start drawing plans for the monument I want to build in your honor. Would you like more coffee?

That’s how I approach peer reviews at Sparkbox. I get that I have a freedom to be rather informal in my approach, but I feel like it is adaptable. Regardless of format, providing honest feedback in a conversational voice has helped me overcome my apprehension of peer reviews.

Exponent Anniversary Episode

I’ve heard Ben Thompson pop up on The Talk Show every now and then, but last summer I was introduced to his podcast, Exponent. In their 100th episode, Ben and co-host James Allworth give detail the world since the introduction of the iPhone ten years ago. This is possibly the most quintessential episode of Exponent. If you have never listened to the podcast, this is a great place to start.

The reality behind scrambling names

It’s not related to a bad memory or to aging, but rather to how the brain categorizes names. It’s like having special folders for family names and friends names stored in the brain. When people used the wrong name, overwhelmingly the name that was used was in the same category, Deffler says. It was in the same folder.

Apple Refunds and Purchase History

I have been buying media and software from Apple for a long time. Pretty much since the iTunes Music Store opened. Until yesterday, I have never so utterly regretted a purchase that I wanted a refund. Apple does not make it obvious how to accomplish this task, so much so I got a feeling that it couldn’t be done. I searched the Apple Support documents the best I could to no avail. Through a series web search landed on instructions start this process in iTunes by going to the Account page and viewing recent purchases.

Turns out there is an easier way.

Apple has a website built for viewing purchases and reporting issues with those purchases. The title of the site is Report A Problem, and at first I didn’t get why. I saw the full purchase history of my account from the iTunes Store, App Store, and even the Mac App Store. Then it dawned on me, it was everything in the last 90 days. The timeframe to report a problem.

What is nice is the purchase history can be broken down by receipts1 and product type as well as search. From what I can tell though, it takes up to 24 hours before a purchase will show up on the site. I was looking into a refund about 14 hours after purchasing.

Once the purchases, a Mac app and companion iOS app, showed up on the site I pressed the “Report A Problem” button. The area expanded to reveal a dropdown list and a text area to describe the problem. I selected “Didn’t mean to purchase this item” and for that the description was required. I left the Apple employees a lamenting response, hit submit, and was told to expect a full refund in five to seven business days. Easy enough.

  1. The receipt bit is quite nice for those business reimbursement requests.

Sparkbox Foundry: Working With Templates and Other People’s Code

Purchased templates get a bad wrap. Up until early this summer I was on the bandwagon, deriding the use of templates. But, then my colleagues and I had an instance where it made since on a project. My mind has shifted to understand why and how agencies can utilize prefab web templates to meet the needs of their clients. However, there are things to keep in mind when choosing this approach. Hopefully my article on the Sparkbox Foundry we be a useful guide for those weighing such a decision.

The Shift: Progressive Enhancement

I joined several of my Sparkbox teammates this month a helped write a joint article for The Shift on the topic of Progressive Enhancement. I love the topic and I dive into what I love about CSS, the cascade makes progressive enhancement a natural aspect of the development process. The tl;dr on utilizing the cascade for progressive enhancement is to put styles for older browsers near the top of the selector block with newer properties toward the bottom. This works especially well for Flexbox properties, which I get go into detail in the article, so check it out!

Be sure to keep up with what others are writing for The Shift, with my list of Shift articles.

Container/Element Query Demos Collection

Last week I attend the CodePen Show & Tell at ConvergeSE. While there, I demoed Container Queries using a collection of demos I posted on CodePen. If you’re not familiar with Container Queries (a.k.a. Element Queries) I highly recommend checking out my talk on the subject from CSS Dev Conf last October, or checkout this list of resources.

Container Queries are still in an early concept state. More work needs done to make this a browser standard, but things still seem optimistic. There is need for more and more use cases though, and polyfills are a great start. Consider taking one of the polyfills from the collection for a spin. Hit me up on Twitter if you have a new demo to add to the collection.

How to Make the Web Better

Who Browsers Are For

The most pivitol tool a web developer uses day in and day out is a browser. They are what we develop for. Browsers can equally enstill excitement and dread throughout a project. As a web developer, it can be hard to maintain perspective of the purpose of browser—to meet the needs of the typical user.

As developers we want the browsers’ primary focus to be on making feature-packed, standards-based browsers. We want really great built-in tools to debug our HTML, CSS, and JavaScript. And when we come across bugs in one browser and not another we curse its name be declaring it the new IE! The perspective we have to keep in mind though is that most users of a browser, are not developers.

Browsers are justsoftware and there are bound to be bugs and issues. Thankfully most browser makers have instituted short release timeframes to take care of minor bugs quickly. But even so, the browser makers’ priority is a feature rich experience for the user. These are features that aren’t associated to any standards, but instead provide the user with preferencial features. One of the reasons I prefer to use Safari has my main browser is the built-in feed reader and tabs syncing. Other browsers offer these features as well, but I like how Safari does it.

Browsers aren’t primarily made for developers, but they are a vital community to a browsers survival. At that web developers are completely reliant on the existance of state of browsers to accomplish their job. We need to maintain constant dialogue between web developers and browser makers.

Report Bugs

All the major browser makers have teams dedicated to reviewing and prioritizing bugs. Browsers are probably the biggest form of customizable software, taking in a set of parameters from HTML, CSS, and JavaScript and rendering them on the page. They cannot account for all problems, nor may they experience the same pain points you are running into day after day. Instead of lementing that the current browser is the new IE, log a bug report and make the web better.

Here is where you can log a bug for each major browser maker:

Follow The Browsers

Additionally consider following the Twitter accounts, blogs, and mailing lists of all the browsers to be aware of what they are up to. WebKit has a great blog, Chromium has a very active community forum, and Opera is quite intent on tweeting all kinds of things.

Make The Web Better Through Engagement

The voice of the developer is important to the browser maker. Lamenting short-comings and complaing about a lack of support doesn’t help fix those problems. We can tweet twelve times a day how much we don’t like Safari’s JavaScript tools, but won’t fix it. Tell the browser makers what you don’t like, what will help you make better websites. They have avenues to listen, but they need to be utilized, otherwise we’re just yelling at inanimate screens.

Take the time to document and report a bug, and make the web better.

Net Magazine: Element Query Tutorial

I wrote a tutorial covering Element Queries for Net Magazine that appeared in last month’s issue. The web version of the tutorial is now available on their website. If you haven’t looked into element queries, it isn’t too bad of a place to start. In the article I give an overview of what element queries are, some simple use cases, and an explanation of using a polyfill.

The online version leaves out some aside content from the print edition, so below you can find some resources to further explore the wonders of element queries.


Articles and Websites

Responsive Issues Community Group (RICG)

RICG is helping push element queries forward as a web standard.

Media Queries Are Not The Answer: Element Query Polyfill

By Tyson Matanich

Working around a lack of element queries

By Scott Jehl

Media Queries are a Hack

By Ian Storm Taylor

Element Queries

By Tab Atkins, Jr

Element Queries, From the Feet Up

By Daniel Buchner

Element Queries for CSS

By Tommy Hodgins