Wynn Netherland

Shipping and the art of Getting Thing Done

2013-04-15T08:14:06-05:00

tldr; Bigger blocks of focused time results in more ships.

My career began in a cube farm over fifteen years ago. It seemed everyone at that time had a Franklin Planner and could enumerate their big rocks for the week on commmand. These were those high priority tasks that just had to get done. The analogy held that if you were filling a jar, you'd put the big rocks in before the smaller pebbles and sand.

Some years later, as Getting Things Done reached near cult status, we sought not only to prioritize tasks, but squeeze out every bit of productivity from the rest of our schedules by assigning a @context to all the pebbles and sand. The thinking was, if you've got just five minutes before the next status meeting, you check your pre-categorized task list to see what phone call, email, or airline reservation you could get done.

When applied within the constraints of typical corporate culture, both of these philosophies aim to bring efficiency to a system under internal pressure from excess meetings and a fixed workday.

Flex and defrag your schedule

It's well known that at GitHub we have few meetings. Tom and others have written about how meetings kill productivity. I saw one of the best analogies for this just last week on Twitter:

"a meeting is essentially a write lock for your organization" @littleidea love that analogy #hangops
— kate matsudaira (@katemats) April 12, 2013

While much has been written about the death of productivity in a meeting, we often overlook what pressures fixed blocks of time put on the rest of our schedules. It's not really even about meetings as much as it is about all fixed blocks of time. Meetings and appointments definitely qualify, but so do fixed workday boundaries. I'm a morning person and will often start my workday way earlier than my teammates. Some Hubbers are night owls and their workday doesn't really get going until I'm headed to bed. A flexible work schedule means each person can maximize their schedule for long uninterrupted blocks of time.

As my schedule fills up, what happens before each block of scheduled time? No matter how good I get at multi-tasking, that important thing gets pushed out because I don't have time to fully context shift and work on it effectively in the time available. The more fixed items I have on my sechedule, the harder it is to jump into a large task.

Meetings especially have some rather insidious effects. For programmers, not all time is created equal. There's something about communicating with others, especially verbally, that drains your mental energy. Have you ever paired with another developer for an extended period of time? Compare your mental state after a four hour solo hacking session to just two hours of pairing. If you're like me, pairing is rewarding yet very draining.

Meetings work the same way. That block of time after the meeting isn't prime time for getting much done. There's no way to avoid meetings and appointments, but the less you have, the larger focused blocks of time you have.

Real focus - what are you shipping next?

Time pressures aren't the only thing that can fragment your schedule and impact your productivity. Too many priorities lead to a divided mind and less ships. Every month, someone from each GitHub team will create an issue along the lines of "What do you want to ship in April?" along with a short list of their goals for that month. Everyone from the team piles on with their lists so everyone gets a sense of what everyone else is doing.

What makes GitHub culture unique from everywhere else I've worked, though, is the emphasis on what are you shipping next? Everyone has the freedom to choose what they're working on inside the framework of the company's goals. Everyone also has the freedom to work on that next thing until it's done.

I don't know jack (yet)

2013-03-03T13:18:25-06:00

My head is still spinning from Tim Caswell's lightning talk at Big Ruby where he showed off jack, his new programming language. (I'll post a link to the video when it's available. The gamepad-driven demo was amazing.) The simple yet powerful syntax looks like an excellent starter language for new programmers. I'm intrigued especially at the function syntax:

{arg1, arg2, arg3| body } is Function --> true

I want to see how my seven-year-old picks up something like this since she's shown interest in Ruby already.

Hypermedia APIs - less hype, more media, please

2013-03-01T20:40:43-06:00

My slides from Big Ruby: Hypermedia-driven APIs are all the rage, but what do they mean for API client developers? Are resilient APIs worth the performance and complexity tradeoffs?

How to get great support as a technical user

2013-02-14T09:32:32-06:00

One of my favorite parts of working at GitHub is helping our Supportocats answer support requests. Since I focus mainly on the GitHub API, I get to work with our more technical users. I've shopped at BestBuy enough to know what it's like when you think you know more than the staff.

Nearly nine months of helping technoweenie pursue Inbox 0 at the API Help Desk has changed the way I ask for tech support for other products and services.

Use the right channel

In the software industry, many of us have friends who have founded or work on some of our favorite services and tools. With those personal relationships, it seems easier to shoot an @reply or DM on Twitter. For site down questions, that's often good enough, but 140 chars just isn't conducive to describing (much less troubleshooting) most issues.

For GitHub, our support form makes it simple to reach out and say Halp! Sending an email to support@github.com works, too. Including "API" in the subject line routes you straight to the API team.

Many open source projects have mailing lists, issue trackers, and IRC rooms to talk about issues. Find the right channel before you send a flurry of questions to a project maintainer.

Get to the point

Once your request makes it to the top of the support queue, it has to be grok'd by a human. Verbosity is your foe here. The more you write, the longer it takes to distill your words into your actual issue. Not just once, but each time your ticket is passed to someone else on the team, it has to be reinterpreted.

Include details

Your chances of getting speedy help go up substantially if you can avoid that dreaded "more info please" follow up. Photos, screenshots, URLs, stack traces, and other facts help speed up the six stages of debugging. If you're calling a HTTP API, the developer has a hard time refuting curl output.

`curl -v` or it didn’t happen.
— Wynn Netherland(@pengwynn) December 18, 2012

Don't piggyback issues

Many request tools thread messages by subject or ticket number. You might be tempted to reply to that six month old email because the person who helped you last time seemed to know what they were talking about. Unless the issue is directly related, chances are you're delaying your new ticket because there's more previous conversation to wade through on the other end.

Don't be insecure

Most support queues use plain old unencrypted email. Please, please, please never send passwords, API tokens, credit cards, or other sensitive information in email. Always mask or omit sensitive info in email. Be sure to scrub that stack trace or log snippet you're including, too.

Be classy

You might have justified rage because a certain feature has been long broken and no one seems to care. Just don't let frustration undermine your own cause. Name calling and insults might make you feel better in the moment but it won't bring you any relief. Most support folks are extremely professional. They like to help or they wouldn't do what they do.

That said, humans are more inclined to help when they're treated like, well, humans.

Oh yeah, we're hiring Supportocats.

Project badges: ease or sleaze?

2013-02-12T12:54:18-06:00

Erik and Mislav have an interesting discussion going on a Faraday commit on the merits of those badges in GitHub repository READMEs.

I use them in a few of my projects, but lack of consistent size and Retina support have me leaning towards removing them.

What's your take? Ease or sleaze?

Rdio-cli does lyrics

2013-01-31T12:45:22-06:00

In another dotfile discovery, I ran across makeitpersonal in Artem's dots. makeitpersonal makes it easy to fetch lyrics in plain text using curl. Naturally, I didn't waste time adding this to rdio-cli. By default, it looks up the current track, but you can override artist or song title, the former being quite useful for covers.

$ rdio current
Now playing: That Old Time Feeling / Rodney Crowell / This One's for Him: A
Tribute to Guy Clark

$ rdio lyrics
Sorry, We don't have lyrics for this song yet.

$ rdio lyrics --artist="Guy Clark"

And that old time feeling goes sneakin' down the hall
Like an old gray cat in winter, keepin' close to the wall
And that old time feeling comes stumblin' up the street
Like an old salesman kickin' the papers from his feet

And that old time feeling draws circles around the block
Like old women with no children, holdin' hands with the clock
And that old time feeling falls on its face in the park
Like an old wino prayin' he can make it till it's dark

And that old time feeling comes and goes in the rain
Like an old man with his checkers, dyin' to find a game
And that old time feeling plays for beer in bars
Like an old blues-time picker who don't recall who you are

And that old time feeling limps through the night on a crutch
Like an old soldier wonderin' if he's paid too much
And that old time feeling rocks and spits and cries
Like an old lover rememberin' the girl with the clear blue eyes

And that old time feeling goes sneakin' down the hall
Like an old gray cat in winter, keepin' close to the wall

You can install rdio-cli from Rubygems or from the source on GitHub.

Bootstrapping consistency

2013-01-28T08:30:50-06:00

One of the best features of Rails is its consistent project layout. Thoughtbot recently shared how they use a ./bin/setup script to bring consistency to the project setup.

Regardless of the bin/setup file’s contents, a developer should be able to clone the project and run a single, consistent, reliable command to start contributing.

At GitHub, we use script/bootstrap, but the idea is the same — a consistent user experience to get from zero to productive on any new project. Whether I'm writing docs, extending GitHub with service hooks, or hacking our internal support tools, I know I can just clone the repository and run script/bootstrap to jump right in. Thanks to a patch from Matt Emborsky, this works for my dots, too.

We also don't stop with the project bootstrap. Our projects normally have script/test for running the local test suite, script/cibuild for running tests on the continuous integration server, as well as the usual script/server, and script/console scripts where applicable.

As a result, I spend less time thinking what to run and just run.

Speaking at Big Ruby

2013-01-25T19:57:17-06:00

I'm excited to be speaking at Big Ruby next month. The organizers have put together a stellar speaking lineup, and the Palace Theater in Grapevine showcases the small town feel I love about Texas. I hope you'll join us.

Photo credit: GrapevineTxOnline.com

Open Government book now open source

2013-01-19T00:00:00+00:00

As a contributor to the Open Government book from O'Reilly a couple of years ago, I was thrilled to see Laurel and Daniel release it on GitHub as part of the #PDFtribute to Aaron Swartz.

Aaron contributed Chapter 25 in which he argues that government transparency doesn't go far enough:

Perhaps even more useful than putting government documents online would be providing access to corporate and nonprofit records. A lot of political action takes place outside the formal government, and thus outside the scope of the existing FOIA laws. But such things seem totally off the radar of most transparency activists; instead, giant corporations that receive billions of dollars from the government are kept impenetrably secret.

You can read this chapter and the entire book in PDF, ebook, and mobile formats.

TIL: Easy UPSERTS in MySQL

2013-01-11T00:00:00+00:00

I've long loved upserts in MongoDB, but I suppose my desire to keep my SQL vanilla for Rails caused me to overlook easy upserts in MySQL using ON DUPLICATE KEY UPDATE:

INSERT INTO table (`user_id`, `some_expensive_count`) 
  VALUES (1, 333333)
  ON DUPLICATE KEY UPDATE `some_expensive_count` = 333333;

If the INSERT would cause a duplicate value in a PRIMARY KEY or UNIQUE index, an UPDATE is performed. Easy peasy.