Larry Lessig’s Long Walk. A long feature on Larry Lessig and his walk through New Hampshire that kicked off the MayDay PAC project.
Category: Blog
The software I use
While answering some “What do you use for…” questions the other night Daniel suggested I write up a recap of what tools I use. He wrote something similar a few days back and it was interesting to read through.
During the day I’m helping organize and lead our various support teams at Automattic so the bulk of my time is spent writing, talking with people, and helping out with projects that come up. All of that requires pretty simple and lightweight tools.
My day-to-day communication all happens through two tools. Much of it happens through various P2s which we have setup for every team, major project, and area of interest within the company. If you’re not familiar with P2s Matt wrote a bit about how we use them. Or, go pick up a copy of Scott’s book. All of our chat then happens through Slack, which we use for both 1-1 and group text chats. There are stats built-in so I know I’ve sent just over 35,000 messages since we started using it about 5 months ago.
The upside to P2 as a core tool for me is that I’m in control of how I follow and receive updates. I follow about 50 internal sites and use email to keep up with posts and comments. Everything is routed in to 3 separate folders that group posts and comments by relative priority. For all this email I use Mail.app. It’s the only mail client that’s ever felt “right” to me. I can’t stand Gmail on the web and get distracted by having email in my browser.
Safari is my primary browser. I had used Firefox for ages but with the release of Yosemite I’ve gone back to Safari. It’s really clean and performance-wise I don’t notice any difference. Plus, the only browser extension I rely upon is 1Password.
Like Daniel I’m a huge fan of Bartender. It keeps things so much more sane up in the menu bar. Up there I have a few things running:
- Caffeine. Prevents your display from sleeping. And, as a bonus, here’s a retina-friendly icon set.
- Pomodoro Timer. I wrote a bit about this previously.
- Cloudup. For effortlessly sharing streams of images and video.
- Sidestep. For securely proxying my internet traffic.
- Flux. Amazingly useful tool to reduce eyestrain when using a computer at night.
I use Things to keep everything organized. For the last 6 months or so I was using Omnifocus. Along with the Yosemite upgrade I took a chance to re-evaluate my tools and decided Things just fit better for my usage. I’ve used it ever since the initial beta tests and have always found it fits my mental model of tasks pretty naturally.
Outside of tasks I use the native Calendar.app to stay scheduled. iCloud syncs everything over to my phone. For notes I use Simplenote for some things and FoldingText for others.
When I do need to code I use Coda. Any coding is just for personal projects and I find using Coda means I have just one tool to remember. It’s not for everyone but it works wonderfully for me.
Divvy is always running in the background, helping me keep windows organized and arranged. There’s something pleasing about having windows set to a grid.
I make sure to do some direct customer support once a week, too. I usually set aside one afternoon for that. It’s always done with our live chat team, which uses Olark. They’re good folks and the web-based chat client is pretty slick.
In terms of hardware I’m using a mid-2014 MacBook Pro, with the retina display of course. Spec-wise it’s got 16 GB of RAM and a 256 GB SSD. Performance-wise it’s more than I need most of the time, but I like using machines for quite a while. My last machine, an 11″ MacBook Air, lasted 3.5 years. I went with the 13″ model because the weight is pretty darn minimal. It’s the only screen I use, too. I stopped using my Cinema Display after upgrading to this laptop. The biggest benefit here is that my home setup is identical to my travel setup in every way. Consistency is nice.
This all makes me think I should do a mobile-specific version of this post, too. Perhaps later.
The Old Guard
The Old Guard is the cultural bellwether of the company. I believe that culture is a slippery thing to fully define, but I do believe it is the responsibility of the Old Guard to not only take the time to define the key values that are the pillars of that culture, to communicate the nuance of those values over and over again, and, lastly, when it becomes apparent they are no longer serving the company, they must be willing to let those values evolve.
Rands writing about The Old Guard.
A simpler Twitter
A long time ago I used Craig Mod’s Twitter for Minimalists. It was nice. Using that in a Fluid.app instance gave me the benefits of Twitter’s web application without the distraction of having it in my primary browser.
Craig’s recent tweet about modifying the notifications panel put it back in my mind.
I find the Twitter website to include some key pieces that third-party apps lack. I enjoy seeing favorites and other activity that’s only available through the web interface. The downside is that I dislike the habit of opening it in my primary browser; I prefer distractions that take more deliberate action to open. So I threw together some basic styles and now have this running:
It helps me build a small, digital habit field around using Twitter. If you want to set up something similar here’s a Gist of the CSS I’m using. Using that in Fluid.app will require the paid version, but it’s just $4.99. I also found this handy replacement icon that looks nice in my dock.
The Robots of Resistance. Long feature story on Chris Csikszentmihályi. It focuses on his projects that bridge art and engineering.
A day in the life
Some co-workers at Automattic are taking this week to blog about what a typical day at work looks like. Everyone’s using a shared tag so you can read through all the posts over here.
So far Marcus, Ben, Andrea, Wendy, Erica, and Bryan have all written posts. At the end of her post, Erica sums it up nicely:
It seems surreal, still, and I never imagined myself here, but I’m grateful. All the perks of travel are cool, but what Automattic has really given me is confidence. Here, I’ve done things that I never thought I could do. For my first few months, I was convinced someone made a mistake and would fire me. Three years later, I realize there are no mistakes, my opinion is valuable, and as this company has grown, so has my admiration for my colleagues.
That really mirrors my own experience of the last 4.5 years. If you read through those posts and want a work day like what’s described, we’re hiring.
Negative vs. Critical
Providing effective feedback is one of the most difficult and important things you can do as a team lead. Feedback takes two forms. First, there’s feedback that stems from great work. For example, someone on your team nailed a recent project. Second, there’s feedback that originates in a mistake or poor performance. Here a team member dropped the ball on something.
People refer to that second type of feedback as “negative.” I think that makes the task of communicating it more awkward and less effective. There’s more than a semantic difference between framing feedback as negative versus critical. Approaching it as critical feedback requires greater upfront work on your part. Ultimately, though, it will set you and your teammate up for success.
Critical feedback seeks to build someone’s skills. You’re not negating what they did. You’re critiquing it so they can improve. A true critique involves a thorough analysis of merits and faults.
That analysis is more time consuming than giving negative feedback. You have to take the extra step beyond identifying what was lacking in your teammate’s work. That identification is the first step: afterward begins the real work.
The most important piece of critical feedback is consciously and deliberately analyzing what could be done differently to improve an outcome. By doing that, you help your team member. You’re doing more than flagging poor work and walking away.
Once you’ve done that you need to take the next step. You have to look at different approaches in addition to what was already good about the existing work. Though an end result may be poor, it rarely means each and every step in the process was. When you take the extra step to clarify positive aspects you reinforce the right habits in your team.
When you clearly communicate what needs to change while succinctly stating what went well, you shift the conversation from negative to critical. You take an action that adversely impacted your team, identify it, and then clearly illustrate to your team member what must be done in the future to make the shift from poor to great. Do that enough times and you build a strong foundation for your team to grow.
Three types of support
When you’re working through a queue of support threads it can help to identify what type of question the user is asking. Doing this helps set the tone for how you approach your reply. In my mental model there are three broad types of support questions.
Users typically ask educational, technical, or transactional questions. Knowing which bucket their question falls in to helps guide your actions.
Educational questions boil down to unfamiliarity with the product. Your goal is to help the user connect the dots. You’re teaching them about how your product works and how they can use it to meet their project’s goals. Take these questions as an opportunity to point users to best practices, existing documentation, and ways they can get continued help.
Technical questions happen from a breakdown in expectations. A user knows what they want, but your software is hampering their ability to get there. Your goal is twofold: help the user get around the issue they’re facing and fix the root cause so it doesn’t happen again. These questions represent an opportunity to dig in to bug details. Maybe it’s an edge case. Maybe it’s widespread. In any case don’t just dismiss the question as a one-time error without verifying that it won’t happen again.
Transactional questions happen any time there’s an issue with purchase-related actions. When you accept payments you will get loads of questions in this bucket. Customers will want refunds, their cards won’t process correctly, they’ll want to pay by purchase order, and more. The goal here is to get the money issue sorted out as quickly and smoothly as possible. There’s no faster route to losing a customer’s trust than making payments and refunds difficult.
At its core, support is requests in one of these areas.
Before you reply to someone it can help to find what area they fall in to. The appropriate language, personality, and content all changes based on that. If someone’s question boils down to a transactional issue you’re better off handling the issue directly. They don’t likely want to read documentation about how to get a refund, for example. Next time you’re working through a queue of support threads ask yourself what type of question you’re answering. Doing so can help ensure you match your response to the user’s primary goals and concerns.
Apple’s cloud
Around 11:30 today I dropped my iPhone from about six inches off the floor. It somehow landed in the one spot of the corner where the screen doesn’t crack or shatter but also isn’t quite whole. It looked as if the adhesive bonding screen and glass loosened.
By 12:10 I had a Genius Bar appointment. After talking with a wonderfully helpful employee I had a new phone in my hand for free. 40 minutes later it was as if I never dropped my phone in the first place.
iCloud made restoring that easy. Every application, every photo, every setting was right where I left it. I had to re-enter my password in a handful of apps and that was it.
Apple may have weaknesses in their web services, but the safety net iCloud provides feels truly magical.
Documenting Conferences
Last week I attended Write the Docs. As with previous events I took real-time notes of the talks. Over the last two years that resulted in 32,515 words of notes. It seems fitting to spend so much time documenting a documentation conference.
The ephemerality of conferences frustrates me. Events bring a knowledgeable group of people together. During the conference energy and ideas are palpable but when attendees go home that all fades in to the ether. The occasional slide deck makes it online, but we lose so much. The context, references, and verbiage of a speaker are lost. Scrawled notes on paper are rarely, if ever, shared with those who couldn’t make the conference.
Freely available, web-based, text notes persist across time. Those not able to attend can still learn. Those who do attend can reflect and remember. Ultimately, when the conference ends the learning continues. When multiple people publish notes you learn what parts of a talk resonate with whom. You are able to collectively document a shared experience.
In the future I would love to see more people actively documenting conferences. Notes help us move our respective communities forward. With notes speakers can build upon the talks of others rather than reinventing the wheel with each event. Notes help us spread knowledge beyond the few hundred people fortunate enough to attend. With notes we assert control over the ephemerality of conference knowledge.