Focus-mode considered harmful

I have, at times, been a practitioner of turning off notifications, superfluous applications, and other distracting computer softwares so I could “get things done”. Sometimes it works! However, I have come to suspect that perhaps it is obscuring a greater problem.

I’m just not focused.

Maybe my task is tedious, my project is poorly-defined, or I don’t have a thread to pull on in order to get started. Whichever it is, the world’s greatest distraction-free, focus-enhancing software isn’t going to fix it.

What I really need is something imminent. A show-and-tell with my team, a milestone to deliver, an item to cross off a list, something to publish for the world. I need a goal and it really helps if I need to achieve it in the next few hours.

Yesterday, I worked for a couple hours towards a show-and-tell with my team. I had Twitter, Campfire, and Rdio open. One or more of these are a possible distraction. But, I knew none of them was going to make my demo better, and so even though I flicked over to them occassionally, I flicked back immediately and got back to work.

No one wants a deadline, but a date and an expectation can prove more useful than I had previously thought.

Ideas for living and creating differently

Try thinking about living and creating a little differently today. Advice for beginners: push through the shortcomings of your early work until your ability catches up with your taste. Slow down, lead life at a slower pace every now and then, it’s good for you. Stop telling us how much everything sucks; not everyone makes the same decisions and trade-offs you would when they create something.

Gimme clarity

Wise pal Brain Bailey, along the way to writing about Woody Allen, perfectly articulates my challenge in thinking about how a team should work:

The combination of clarity and freedom is what makes work a joy; one without the other is where you find frustration. When you have great freedom, but an incomplete understanding of the goal, you’re likely to invest hours of effort in a futile attempt to hit a target you can’t see. You know this is the case when you see revisions requested again and again, or products that are perpetually delayed.

On the other hand, a clear goal with little freedom in how to achieve it produces uninspired work by dispirited people. The lack of freedom is experienced as a lack of trust and confidence. People in these environments will eventually seek out new places to work.

Personally, I oscillate between attributing failed projects to too much freedom or not enough freedom. It’s not about that at all. It’s about the balance of that freedom and clarity. If I’m given freedom without clarity, I run off and invent something interesting but impractical. If I’m given over-constrained clarity, I get discouraged.

(Freedom is a funny thing on teams and projects. I have a lot more freedom than I usually think, but I’m still very conservative in acting on that freedom.)

I recently asked my team lead to give the team I’m on a stronger direction in which to go. We already had most of the freedom we needed. We talked over how we could proceed as a team and came up with a direction that was useful for the other teams around us and not so far afield from our current momentum as to discourage us. My morale immediately doubled and I think our team did some good excellent work once we had that strong direction.

Whether you’re managing yourself, managing a team, or managing your manager, asking for clarity is a thing I you should do!

The feel of a commented program

Opening a nicely documented source file is like opening a well-designed, nicely printed book. The main text is obvious, but the side-notes are there to help you when you aren’t quite catching where the author goes or when the author wants you to go read up on something else for context.

Opening a file that needs few comments is like opening a notebook. It’s the raw form of an idea. A few people can pull this off, distilling a program down to its essence.

Both are charming in their own way. The challenge is to know when you’re producing a book and when you’re writing in your notebook. Write for yourself first, then edit it up or down for the reader.

Some productivity winners

Three things that are making me more productive lately:

  • Pick a thing and do it. Whatever you want to accomplish today, do it immediately after you wake up. No social media, no food, nothing. Work on it for 30-60 minutes and then get on with your day. I’d mentioned this before, but I fell off the horse and needed to get back on.
  • No visible clocks. Not in menubars, not in toolbars, not on walls, not on screens. I totally perceive time in a different way when I’m don’t perceive each minute as it passes.
  • Pre-work pep talk. Before I sit down to do something, I talk myself through how I’m going to solve the problem, what the scope of this session is, or think through how I want to structure the thing I’m making. If I do this, I’m much more likely to stay on task, shrug off roadblocks, and avoid distracting myself.

Go forth and crush it.

Sit on the fence between abstraction and practice

Theory and Practice is about a fence. It’s tempting to steer all the way towards the abstract, academic side, or all the way towards cutthroat practical side. Some of the most intriguing, productive people I’ve known sit on either side. Both sides like to accuse the other of not producing results, but that’s subjective. An academic’s results are wholly different from a practitioner’s results.

On occasion, you’ll run into someone who can actually explain complicated theory stuff to you in an accessible way. If you find someone like this, make sure to hold onto them closely, as they’re really rare. But they can help provide you with some insight that will really boost your productivity, without having to invest all the time in figuring out all that wankery that the priests of theory love.

This is a really nice way of explaining why someone like Richard Feynman is awesome. He was equal parts discoverer and explainer (plus another equal part mischief). This is exactly the thing I aim to achieve when I write here, make code, or present at conferences. There’s a whole bunch of ideas that aren’t in practice but, presented and packaged properly, can help move a lot of practitioners forward while recognizing the work of academics and nudging them to keep working in that area.

A lot of good things come out of connecting the people on opposite sides of the fence. Sitting on a fence isn’t exactly graceful, but sometimes it’s the only way to move ideas along. Don’t be afraid to eschew purity or pride for progress.

Pop discovery/rediscovery

Programming is like pop culture in the sense that Blondie gets reinvented every decade and every decade client-server computing is rediscovered. But it’s also like pop culture in that every once in a while something radically new, like hip-hop or STM, appears and eventually is absorbed into the mainstream of the pop culture. I’m ok with that.

Know a little hardware


  1. Google’s intricate and massive data center operations, wherein Google is not only leading the pack in building distributed computing and database infrastructure, but building massive operations to run those systems.
  2. “People who are really serious about software should make their own hardware.” Alan Kay, creator of Smalltalk, object-oriented programming, and many other things that are good in your software development life, said that.

I think Alan Kay’s quote could be rewritten for modern times to say, “Those who are really serious about large applications should make their own datacenters”. Assembling hardware, putting it into racks, putting the racks into data centers, and building out your own data centers are the analog of building your own hardware for software service companies these days.

You probably don’t need expert-level knowledge of these disciplines to write software today (e.g. I know diddly-squat about how packets find their way through the modern internet). You will, however, have a leg up if you’re aware of the possibilities and know how to take advantage of them. Even if you’re building applications with modest capacity needs, knowing how to set up a failover database and when to pay for physical hardware instead of virtualized hosts is a thing that will make your customers and clients happy.

More concisely: when it comes to running your software on hardware, one size does not fit all; know how and when to tailor your application to the hardware, no matter what size your application wears.

Invent the right thing

You have to invent the right thing. Some things you might invent:

  1. A solution to a problem. Nothing novel, just an answer for a question. Eg. any Rails/Django/etc. application.

  2. An application of some existing techonologies in a novel way. Eg. integrating a library to avoid inventing your own solution.

  3. An incrementally better, specific kind of mouse trap. Eg. building on top of existing infrastructure to solve a problem better than any existing solutions.

  4. An entirely new kind of mousetrap. Eg. building wholly new infrastructure because you face a high quality, unique problem that you are imminently required to solve.

Inventing the wrong thing means you’re operating at the wrong level. If you’re too high, you’re spinning your wheels on problems you hope to have. If you’re too low, you’re spinning your wheels on building something that isn’t sufficient to solve your problems. If you’re at the right level, you’re mostly solving problems you actually face and not solving too my coincidental problems.

This doesn’t mean new problems shouldn’t be tackled and new techonologies should not be invented. It applies mostly to reinventing wheels. That is, a project starts with level 1, not level 3 or 4. Apply a technology and improve it before you push the edge. In fact, you must push the limits of an extant technology before level 4 is the right answer. No skipping allowed.

Don’t let imposter syndrome lead you to the wrong technology decision. I’ve tried to build at the wrong level in the past because I felt like I had to fit in with the level of what others working on larger systems were building. Wrong answer.

It’s OK to build a scooter instead of a spaceship if all you need to do is go pick up the mail.

A better shared space

Remote teams are hard. Not impossible hard, but running uphill hard. It’s hard because people are used to interacting face-to-face. Given the opportunity, they’ll interact with those around them rather than those in virtual spaces.

The trick, I think, is to make a better shared space for a remote/local team than the physically shared space they already have. A space that is just as fluid, fun, and useful as a physical space and available anytime, everywhere is more compelling because it affords its occupants (aka team members) more hours in their day (no commuting, flexible hours) and permits all sorts of non-traditional work locations (coffee shops, trains, sofas at home, a summer trip to Europe).

Decoupling work from location and time is a big deal. I hope more companies, in software and outside of it, attempt to solve it.