Why So Many Searches for “2600″? (Hint: It’s performance evaluation season)

Our recent site analytics reveal that Flow users have been searching for the phrase “2600.” In the past month, we’ve had over 70 unique searches for variations of the term. At first, none of us around the office knew what “2600” meant…. Are Flow users looking for information on the long-running hacker quarterly? Or searching for books and videos on the beloved video game console?

Neither of those, it turns out. In fact, they’re looking for help on everyone’s favorite annual ritual: performance evaluations. Specifically, they’re searching for a book in Flow titled 2600 Phrases for Effective Performance Reviews, which is exactly what you think it is—copypasta for evaluations.

Whether for your boss, your employees, or (perhaps worst of all) yourself, this is the time of year when you’re likely to be writing a professional evaluation of some kind. If you’re like us, you could probably use some help. We’ve put together a list of 5 bits of advice so that we can all stop stressing about it.

image of book coverCommunication and Cooperation from
2600 Phrases for Effective Performance Reviews by Paul Falcone

As you’d expect, this chapter suggests phases related to communications skills, for example: “cultivates a culture of openness in information sharing.” Even if you don’t care for the exact phrases, they can help you generate ideas. It’s easy to imagine how a single phrase can generate a more substantial paragraph about, say, how you or your employee needs to improve on communication across departments in order to achieve certain OKRs (see next suggestion).

image of book coverFocusing on Key Performance Indicators from
Advanced Web Metrics with Google Analytics by Brian Clifton

Setting goals for the upcoming year is one of the challenges of writing evaluations. You usually want to set goals that are measurable and realistic, but also challenging. If you use a tool such as Google Analytics to track and help analyze data about your sites and products, you probably have a few key metrics that you care most about. This chapter describes how to align those key performance indicators (KPIs) with the objectives and key results (OKRs) of your organization, which can help you create your goals for 2014.

image of book coverPerformance Reviews from
Perfect Phrases for Coaching Employee Performance by Laura Poole

Once you write your appraisals, you have to deliver the results. Many managers have a hard time with this part of the process, especially if they have to deliver negative reviews. This chapter on performance reviews takes you step by step through the best things to say to your employee. Sections such as “Giving and Receiving Feedback,” “Acknowledging Good Work,” and “Learning from Challenges” include questions that you can use as a guide (or use word for word, if you’re really stuck). More generally, this book dives into the psychology of appraisals, which can be surprisingly helpful.

image of book cover
Feedback from
Coaching for Performance by John Whitmore

We wish we had read this succinct, practical, smart section years ago. The advice found here is useful for anyone who finds herself needing to evaluate and help improve another’s actions and motivations, be it a manager or an employee who is looking to “manage up.” The section starts by identifying ways in which feedback is typically delivered and how those methods fall short, before arguing for a superior approach. From there, the section describes how this approach works well regardless of the format of the evaluation. A subsequent section on self-assessment is equally useful.

image of book coverDevelop your CV writing skills from
The One Page CV by Paul Hichens

While writing a performance evaluation, you may find yourself evaluating your career more generally. Maybe it’s time to make a change? Writing a resume might be the only thing worse than writing a performance evaluation, and this chapter provides examples to make it easier. Even if you’re not interested in updating your resume, the chapter includes tutorials for how to improve your writing more generally. We especially like the tips on how to write concisely.

Do you have a favorite resource for writing performance evaluations? Let us know in the comments or on Twitter.

Agile Authoring

To some, November brings to mind the beginning of holiday cooking season, with massive feasts, multiple dishes, a neverending list of ingredients to buy at the grocery store, and possibly a house full of visitors who want to be useful but usually just get in the way.  To others, November is the month of NanoWriMo, a ritual amongst amateur writers to shut yourself away for a month and crank out that novel that you’ve always wanted to write (usually poorly, and usually alone).  At Safari Books Online, we went into November engaging in our own mammoth writing exercise, with its own massive list of things to do and its own eager crew of contributors wanting to be helpful.  This was our Book Sprint.

The challenge: describe an application that had evolved over time through the contributions of a dozen developers, where documentation had perennially lagged.  It wasn’t a simple matter of asking one or two people to set aside two weeks to properly document their code, but to get a bunch of individuals who were each experts at different aspects of the application to sit together and pool their knowledge.  

What we hoped would emerge: a comprehensive software manual that didn’t read like it was written by a crazy person.  It was a very interesting challenge, so we approached Adam Hyde from BookSprints to help us focus our efforts.

A Book Sprint, as the name might imply, takes its name from a code sprint and is, in many ways, a method of taking agile software methodologies and applying them to the collaborative task of writing a book.  We sat down with Adam and had him lead us through a discussion session where we started raising topics that needed to be discussed in the book.  Each of the topics were all written down in a sticky-note, then posted on a whiteboard.  Once posted, we grouped the notes into common themes, and as the groupings evolved, the a basic chapter-and-topic structure emerged.  This was organized into a rough table of contents, and each of us picked out a few notes that we felt comfortable writing about, and we set to work putting down our thoughts into a collaborative online document which was the beginning of our book.

Replace the notes with tickets, the table of contents with a backlog list, and the periodic status checkups with a standup, and you can see how this authoring process mirrors the  workflow of an agile software development team.  Indeed, at its core, agile development is a process and mindset for organizing a group of talented and motivated individuals who are all contributing to a project that may evolve over time, and there’s nothing that says that this approach only applies to code.  

Writing books can benefit from collaboration and must evolve as ideas and information emerge through the writing process.  By switching out the conventional model of a rigid outline in favor of modular topic cards, multiple contributors can start writing independently—working on individual pieces of the book in parallel—then backfilling continuity and flow afterwards as part of integrating chapters together.   If a new topic needs to be covered, treat it like another requirement, write up a post-it and stick it into the appropriate chapter.

Similarly, one could envision an agile kitchen where, rather than having a hierarchical set of chefs and sous chefs, a set of discrete tasks are put up on a whiteboard like: “mince garlic”, “boil potatoes”, or “brine turkey.” Individual contributors note the tasks that need to be done, pick them up as they are ready and then add new tasks as the evening evolves (“open another bottle of wine”)… 

…this may or may not describe a standard dinner party between Safari employees.

Screen Shot 2013-11-07 at 3.24.04 PM

Screen Shot 2013-11-07 at 3.22.54 PM

We’re big fans of agile development at Safari, not because it’s a cool, hip thing to do in the world of software, but because we genuinely enjoy the human interactions that can emerge from deep, thoughtful, and genuine collaboration. There’s nothing that says that it has to be limited to “writing the codes.”

Got Issues?

Safari’s Content Team has the dubious distinction of having the highest volume of tickets in our company-wide issue management tracking system (we use Atlassian’s JIRA). We easily win this competition, with more than 1,500 open issues on any given day. But do we buckle under the psychic weight of all these tickets? Nah… go ahead, bring ‘em!

Content Issue Pie

Content Issue Pie

Why So Many, You May Ask?

The Content Team has quality-checked 12,729 brand new titles loaded onto Safari Books Online from April 2011 to last week. For the past 6 months, we averaged 753 titles/month, or 177 titles/week. We track only issues that are clearly errors (e.g., a title-cover image mismatch) or issues that seriously impact readability (e.g., all images are random color bitmaps like this one from a real book).

Mangled image

Mangled image

Each time we find an issue like this, we stop the title in the pipeline before it goes live, and follow up one way or another to correct it. We track all of these issues in JIRA, so we can manage the corrections and move each title live as quickly as possible.

At this time, we only check brand new titles, but our publishers are free to update titles at any time without oversight. And, since we only started quality-checking new titles in April 2011, but Safari launched way back in September 2001, there are quite a few titles that we haven’t scrutinized. Various problems get reported: the unavailability of practice files referred to in the text, teeny tiny images too small to make out, or broken links. An average of 200 new content issue tickets are created each month.

Issues Created Monthly

That explains where our issues are coming from. So, how do we manage them?

Standardization, Automation, and Elbow Grease

Well, managing these issues has been an evolving process. We are fortunate to have on staff not just one, but several JIRA experts, who are always willing to help us out with custom fields and productivity brainstorming.

We’ve been working our way up to several key improvements, which are now at a point where we are starting to realize the benefits. With >1,500 issues, global improvements don’t happen overnight. It’s easy to add new fields to help us organize and track issues, but then those fields need to be populated – a daunting task. And of course, in order for this system to work, everyone has to use it the same way — which means a bit of documentation, training, and oversight are needed. Here are the keys to managing this type of issue volume:

  1. Standardization: custom fields, boilerplate language
  2. Automation: QaQ, automated email
  3. Elbow Grease: Monthly issues export & follow up
  4. NEW: Greenhopper

Standardization. Custom JIRA fields help us slice and dice the issues into manageable groups. For example, we added a publisher field, which allows us to export all the open issues for a given publisher. We use a component field, which allows us to sort that publisher’s open issues by whether the issue relates to the source PDF, the source EPUB, the metadata, companion files, etc.

Component Pie

And we have boilerplated the language we use in certain fields, which serves two purposes. First, it saves the ticket writer time – she doesn’t have to consider how to explain a given issue, she can rather just copy/paste the explanatory text from our (constantly updated) JIRA Issue Map. Second, we make sure our boilerplate language is clear enough for publisher-facing communications, even if our primary publisher contact is a rights person who has no need to speak the lingo of CSS or toc.ncx, for example.

Automation. Our stellar engineering team has built us an QA Queue application (we call it the QaQ) to manage our daily load of new titles to quality-check, and this system hooks right into JIRA. After we check a publisher’s new batch of titles, we follow up via email to let the publisher know which titles are live, and which need a little more work before they can go live. The QaQ automates the creation of lovely formatted emails; for titles with associated JIRA tickets, it exports the text from key fields which detail the required fix in easy-to-understand language.

Elbow Grease. We are now rolling out a monthly export of issues for each publisher. When a publisher receives a spreadsheet listing their issues in detail, sorted by issue type, it’s a lot easier for them to follow up en masse, so they can get as many new titles live (or corrected, if they are already live) as quickly as possible. We did a pilot of this new process with a select set of publishers, with very promising results. We don’t want our publishing partners swimming in the JIRA sea, nor should we require them to rely on email alone for making sure all their titles are working well on Safari.

New: Greenhopper. This plug-in to JIRA has us really excited. We are doing a trial run with a Kanban workflow for the subset of Content issues requiring engineering work. In 2010, we were managing the long list of engineering Content issues via JIRA and email alone. Well, that doesn’t work so well once you have more than a handful of issues. So in 2012, we switched to a shared Google doc so we could be sure we were all working off the same songsheet. But even that has its shortcomings – we meant to keep notes in the Google doc and ALSO update each JIRA ticket as we worked. In theory. Often, only one or the other would get updated, and sometimes the priorities in the doc didn’t match the priorities in JIRA.

But with Greenhopper, we plan to kiss the Google spreadsheet goodbye, for the most part. We created a Kanban board with a few key buckets: Pending, In Progress, In SBO QA, and Completed. We are strictly limiting the number of In Progress tickets to 10. (If you go over 10 tickets In Progress, the whole board turns a distressing bloody red.) This way it’s very clear for engineering to know exactly what must be worked on. And the Kanban board is very easy to work with – in our status calls, we can discuss the entire board, and update each individual issue as we discuss it from the same board. No more getting lost in a sea of dozens of browser tabs or windows.

If this Greenhopper experiment works well for our Engineering tickets, we will explore creating boards for other types of Content Issues. The sky seems to be the limit in terms of how you structure your boards; they seem fully customizable based on the fields you want to use.

OK, now that we have these great tools in place and are starting to use them, we can start setting some nice aggressive goals to get our overall numbers down. (The team is going to kill me when they hear this.)  Let’s beat our current created-to-resolved ratio by summer, guys!

30 Day Summary to Beat

Conference-driven development

TL;DR — Release products at conferences. The products will be better and you’ll be happier.

Test-driven development is a technique that helps programmers build large applications from small, working components. It has been successful enough to unlock developers’ innate love of acronyms, ranging from ATDD and BDD to MDD and UGG. TDD is important in the industry because it forces a mental shift inside the programmer’s mind. Like most humans, programmers are all too willing to succumb to really lame brain bugs. Instead of falling for the trap of designing and implementing a grand cathedral in one single volcano of brilliance, TDD focuses on a continuous stream of achievable, minor, functional bricks. Conference-driven development offers similar rewards for virtuous choices, but works for the whole product development team rather than just programmers.

Continue reading

Invest in your engineers; build Connect4 in four hours

Last year, my group decided to invest a certain amount (5%) of time to unstructured self-directed activities – we call it “investment time.” We do this on every other Friday afternoon.

This isn’t a new idea. The concept has been widely touted, and according to this post, it has been in vogue, or at least in use, as far back as 1948 (at 3M). There are also many well-documented flaws with this idea; see these comments. The comments on coding horror’s post are full of examples of how this can fail.

But there are good reasons to try: In a client-driven consulting organization, engineering work is tightly constrained: by feature requirements and/or by budget. Often it’s an engineer’s role to be the grownup on a project, reminding everyone about technical constraints that will lead to scope growth and cost overruns. It can be tiresome to always be the person that says “no,” and every now and then we need a chance to think expansively, try new things, and exercise our creative juices.

So the idea isn’t new, and 5% of our time isn’t really enough time to launch major new initiatives: gmail isn’t going to get invented every working other Friday afternoon. But I want to talk about this practice because I think it has had a lot of value for us, we’re a small organization without the resources of a Google or a Microsoft, and this gives us a different  perspective. In these sessions, we have a chance to try out new things, to work with different people, and to think creatively, but it hasn’t necessarily been easy to realize these benefits. I’d like to reflect on how this has worked and not worked for us, and then I’ll describe what we did in our most recent session.

Since we started this six months ago, we’ve had mixed experiences. Sometimes interesting things that provide tangible benefits have happened. We built an XSLT code coverage tool and integrated into our unit tests. We worked through some incompatibilities in our core platform so we could deploy <a href=”http://newrelic.com”>NewRelic</a&gt; to monitor it (which by the way has been a huge help). Other times people drift off and work on their regular work. A few times people have left early. My feeling is it’s OK that that happened because this is an experiment, but we do want to get the most out of the time we’re spending and so we try to learn from the failures as well as benefit the successes. Here’s a quick run-down on what seems to work and what doesn’t:

1. Celebrate success. OK this is just like mom and apple pie, but it’s easy to forget to do. We follow up each session with a report out to the whole company about what happened. It’s a good opportunity to let people know what the engineers are wasting their time on so they can see just how
useful it is.

2. Do it on a regular basis, at a predetermined time. This is really critical: it ensures that it will actually happen. The whole idea is to be open to new ideas, so you don’t know *what* you are going to do exactly, which lends a bit of an air of unreality to the whole enterprise. To combat that, you have to be very concrete and specific about when you are going to do it, who’s going to be involved, and where it will happen. Beer and food help too.

An important corollary is: no Friday releases. If you can make this part of your company culture, you will benefit regardless of whether you also have investment time. Friday releases are bad because nobody tests them until Monday except your customers – nuff said. But it’s especially important to keep releases away if you are trying to reserve some unscheduled time.

3. Have everybody in the same place together. This has been really important: the best weeks have seen a low hum of activity in the office, and significant exchanges have occurred from people spontaneously walking around the office and looking over other folks’ shoulders. However, one thing we need to get better at is involving our remote developers. There’s a tension around encouraging collaboration: some people work better alone; others in groups. We’re still learning the right balance.

4. Don’t force people to be creative if they don’t want to, or feel like they’re too busy. People shouldn’t be made to feel guilty if they’re not inventing a cure for cancer in their spare time.

Also, sometimes there is a monkey on someone’s back that they need to shake. Ideally this shouldn’t happen, but if it does, delaying work you really absolutely need to do just so you can take time out to come up with other freakin’ stuff to do obviously makes no sense.

5. Find a way to encourage everyone to generate good ideas in advance of the investment time. We’ve run an exercise with colored markers and sticky notes that was fun and generated all kinds of great ideas. Sometimes just going around the room and having everyone say what they’re planning to do
is enough.

6. Add competition to the mix. From time to time we like to issue a programming challenge to the engineers at our company. This gets folks thinking about work in new and creative ways, and well – it’s fun. We
strove to build the fastest sudoku solver; we competed in robocode matches. Hilarity ensued: programming chops were rewarded.

The Connect4 Challenge

Recently one of our engineers, Mark LeMay, came up with the idea of a framework showdown. The idea was to learn more about different programming languages and web application frameworks by devising a simple problem, applying various tools to it, and comparing notes.

The problem we chose to work on was Connect Four. This is a simple two-player game, familiar to many. You drop disks into a 6×7 array of cells, where they fall to the bottom of their column with the object of getting four in a row of your color before your opponent does the same. It seemed ideal from the perspective of being easy to program, but would require some server side programming in order to manage the game state, since it must be shared by multiple players.

We came up with a scoring rubric for evaluating entrants that awarded points for everything from “return HTTP OK” to stress testing and unbeatable AI. Pretty ambitious for 4 hours on a Friday afternoon. Yes, well it turns out that 4 hours is not enough to learn a new language, and a new framework, and to code a perfect Connect4 AI that can run while being stress tested by North Korean hacker bots (actually we didn’t try that last one, but I’m pretty sure all the entrants would have failed it).

However, it is almost enough try out some new tools and get a feel for what it might be like to do some real work with them. Here are the ones we tried: Ruby on Rails, Grails, Google Web Toolkit, Node.js, Lux (XQuery), Go and Google Apps, Clojure, Wicket, and Django. Some newish stuff, a lot of stuff that is not super new, but this was an opportunity for folks who don’t get out that much to try out a newer, younger model, um as it were.

A few things people wanted to or suggested trying were but never got to were: Scala, ChicagoBoss/Erlang, and HapiJS. Maybe we’ll check them out later.

I’m not even going to attempt to give you a run-down on all these tools in this post, but in some later posts we’ll cover some of them (we’ve already heard from Robert Hall re: sockets in node.js).

Building Distributed Teams: Driving meetings with Google Docs

Over the last few years, Liza and I have had the pleasure of building an ever-expanding engineering team. We’ve managed to find great people from across the country and were 100% distributed & office-less until a few folks moved into the new Safari office in Boston two months ago. Because our team was remote by rule rather than by exception, we’ve been forced to develop a culture that exploits new tools whenever they can help us cooperate and collaborate. One particular habit we’re fond of is running meetings through Google Docs.

As is typical with developers, we are not generally fond of meetings, especially recurring meetings, so we have tried to distill them into their productive, fundamental essence1. While our meetings are still far from perfect, I think we’ve developed some conventions worth sharing with other distributed teams.

One minutes to rule them all—in real time

Google Docs sometimes makes it too easy to create and share new documents, so the first lesson is to fight against this: use the same Google Doc for the same meeting week after week and write it during the meeting. This practice is laughably simple, but it removes the biggest threats to useful minutes:

  1. the attendees (claim) to not know where the minutes were/are
  2. the minutes feel worthless because they’ll be ignored forever after
  3. the attendees (wrongly) feel that someone else will write the minutes
  4. the attendees claim the minutes did not accurately capture the discussion

To set this up, just use an extremely clear title for the document (“{Team} {Purpose} Rolling Minutes”) and then add the new minutes at the very top for each meeting. Make it clear from the very first meeting that everyone is expected to help write the minutes in real time (plant some willing collaborators beforehand, if necessary).

It’s worth rotating to a new document every 6–12 months or Google Docs will be crashy.

Collect agenda beforehand (the “Pending” bucket)

Once you’ve established that the same document will be used for each meeting in the series, it is time to start turning the rest-of-the-week time into a lever that makes the meeting itself shorter. We keep an (empty) bulleted list under a Pending heading at the top of every minutes document. The Pending list gets filled by folks as something occurs to them throughout the week. In more extreme cases, the Pending list must be filled beforehand or the meeting itself is summarily canceled (depends on the meeting). Developing the Pending list asynchronously can also make it easier for less outspoken people to make sure their topics get some space in the larger forum.

Establish a repeating structure

While it’s easy to screw up, a carefully crafted meeting structure can help everyone understand when they’ll be actively participating and when the thing is nearly done. The problem is that you have to frequently evaluate the structure to make sure it still actually helps the team communicate rather than being wasteful boilerplate.

Our “big” meeting looks like:

(social pressure to finish what you promised)

(*extremely* short Before/Now/Next updates from each person
 don't skip this, as it gets every single human to actually say words at each meaning, 
 forces people to write down what they did [more social pressure],
 and establishes a basic record of what the team was doing in any given month)

(a heading for every item that was on the Pending list, plus anything emergent)

(every time a meeting ends without meaningful tasks assigned to specific humans, a kitten loses its wings)

A repeating structure also helps answer questions about who promised what. You just go down far enough to find it in the expected place in the minutes of a previous meeting. While this is a simple act, doing it consistently makes it clear that the minutes serve a purpose and that the each member of the team is accountable.

Force collaboration and attention through humor

The biggest benefit of cloud-based minutes is the opportunity to use a meeting as a way to help the group gel a tiny bit more, week after week. For distributed teams, the chances for true collaboration and team-building are already extremely limited, so we take whatever we get. Specifically, I want to use the minutes as a tool to have the team:

  • see each other actually (visibly) contributing to a shared project
  • laugh with each other
  • pay attention

A screenshot of a Google Docs document with humorous images and silly fonts

To achieve these goals, we need only two things: silly cat pictures, collaborative authoring. When the team knows that their colleagues are humorously defacing/lolcatting their section of the minutes, ignoring the document is nearly impossible (we don’t actually use Comments in minutes as much as you would expect). Juxtaposing the boss’ description of a particularly rough moment in the release process with a sad panda provides a rare moment to let off steam for people who almost never see each other face to face. And watching a document being written and edited by 5–10 people at once is really quite enchanting.

1 Andrew, our CEO, bought a huge stack of these and forced us to read them, before, ahem the next meeting.

Eight Great Tools Simple Enough for a CEO

Much of the early part of my career in publishing was spent writing and maintaining scripts used for automating book production. Applying the tools that developers use to manage code to managing manuscripts was a big part of the strategy behind the XML publishing toolchain I helped build (alongside @abdelazer) at O’Reilly (work now being impressively extended by Adam Witwer and Sanders Kleinfeld).

These days I spend much more time in spreadsheets and video conferences than in Vim, but I’ve never lost the appreciation for quality tools. I rarely write my own anymore, but here’s a list of tools I use every day that are indispensable for effectively working with a growing company that has team members around the world:

Google Apps for business

Get your discussions out of email (or worse, email attachments)! @liza and her team introduced us to using Google Docs for tracking running meeting notes, and from there our use of shared documents for everything from meeting agendas to press release reviews to training videos to board reports has grown dramatically. Some days the volume of documents getting updated feels overwhelming — until I remember that the volume of conversation hasn’t actually grown, it’s just been pulled out from where it was hiding in email. The full Google Apps suite is cost effective, easy to administer, and makes it simple to integrate authentication with third-party and internal apps.

Google Hangouts are a simple and easy alternative for video conferencing and screensharing — and Google Voice is a lifesaver for anyone who gets a lot of unsolicited sales calls.

Bonus tip: Comment notifications. It’s not well-documented, but you can use the Google plus “+” convention (or the Twitter “@“ convention) to add notifications to Google Docs comments. For example, if someone includes “+andrew@safaribooksonline.com” in a Google Doc comment, I’ll get notified by email.

Gmail keyboard shortcuts

I’ve used Outlook, Thunderbird, and Mail.app over the years, but I’ve never been faster than when using Gmail right from Chrome — because of the extensive keyboard shortcuts. In general they mimic the Vim convention of modal editing, so they don’t require a lot of complex key combinations. To see the keyboard shortcuts from Gmail, just press “?” (that’s “Shift-/”) while your cursor isn’t in a text field and you’ll get a popover.


The concept is similar to Google’s Priority inbox, but the results are much better. SaneBox connects to your social media accounts to help it filter your email. It works great with Gmail, and is compatible with most IMAP-based email systems. My favorite feature is a folder called “BlackHole” — drop an email in there, and you’ll never see another one from that sender again.


The one feature I missed most from Outlook and Thunderbird when using Gmail via Chrome was the ability to schedule a message for later, so I was thrilled to find Boomerang. Boomerang’s main feature is to send an email from your inbox back to you later, but I use it almost exclusively for scheduling messages to send in the future. Unlike with Outlook, you don’t need to have your computer on for the message to go out. I often catch up on email in batches during odd hours, and it’s nice to be able to queue up replies for Monday morning while working on the weekend, for example.


While I’m not quite ready to compare them to polio, passwords are a constant aggravation. Having strong, unique passwords for everything and not having to remember any of them is wonderful. 1Password stores credit card info and other info (securely), and syncs with Dropbox to your phone. The Mac version is $49.99 and worth every penny (as is the $14.99 extra you’ll pay for the iOS version).


Expanding short abbreviations into longer text snippets sounds like a small thing, but it makes a big difference over time. Email salutations, phone numbers, addresses — it’s the closest thing I’ve found to Vim’s imap feature for use with everything else.


I tried Quicksilver a number of times, but couldn’t get myself over the learning curve. Alfred is similar, and I use it dozens of times a day for launching apps, looking up contacts (the PowerPack is worth the investment), and even doing quick calculations.


A theme with the tools on this list is that most of them only do one thing (or a small number of things) but do them very well. This last one is perhaps the best example of that. CloudApp puts a small icon in your menu bar. You drop files (or folders) onto that icon, and CloudApp creates a shareable link and puts it on your clipboard. I’ve been thwarted enough times by overzealous corporate IT departments with excessive restrictions on file attachment types and size that this is a very worthwhile preventive measure — since you can just send a link instead of an attachment.

There’s a lot more great apps on my laptop and my phone, but these are the essentials I depend on day-in and day-out to help keep the small stuff from getting in the way of the important stuff. Leave your own suggestions for indispensable tools in the comments below.