Search and Distract

All of humanity’s problems stem from man’s inability to sit quietly in a room alone

Blaise Pascal

There’s a process that is always running in the back of my brain. It’s probably an artifact of the internet. But I’m not ruling out the possibility that it’s a part of the human experience.

Whenever there is a hint of boredom, my brain makes it the primary process. It’s pretty simple. I call it Search and Distract:

  1. Search for a distraction
  2. Give a reward for the distraction
  3. Become bored of the distraction
  4. Goto 1

The problem isn’t the desire to be entertained. Engaging entertainment can be incredibly rewarding and inspiring.

The problem is that even the distraction isn’t enough to hold my attention. Instead, hours disappear without anything happening. If you tap me on the shoulder and pull me out of this stupor I’d have no answer to “what have you been doing?”

I’ve found there are a couple of ways to break this loop.

  1. Exercise
  2. Doing nothing

Exercise is great for a lot of things (including staying alive). But it also does wonders for mental clarity. For whatever reason, going for a run can quiet the desire for a distraction more than the distraction itself.

Doing nothing is the more interesting concept. You could call it meditation, but I call it taking a shower. By doing nothing, you can take advantage of your brain’s inability to be bored. Just sit and wait for the loop to churn up something that might actually be productive.

Anything new on Instagram?
Anything new on Hacker News?
Youtube must have something interesting to suggest
Anything new on Twitter?
I have an idea about <project I should be working on>

Doing nothing is fine. But I’ve found that if doing nothing is the only alternative to productive work, the work gets done.

The Edit Is What Matters

Everyone participates in the creative process. If you’re a writer, filmmaker, graphic designer, or one of the other traditional creative types, this is a given. For the rest of us, it’s not so obvious. But if you squint hard enough, every email and power point presentation follows the same creative steps.

Loosely, the act of creating something can be broken down into:

  1. The idea
  2. The raw material
  3. The edit
  4. The release

In my experience, the edit is the only step that truly matters (although the rest can help).

It’s a cliche in the startup ecosystem that “ideas are cheap.” There’s some truth to that. No idea is truly unique or original. Every idea builds off of previous work. This means that just about every idea has been tried before. While a bad idea can certainly kill a project, a good idea doesn’t guarantee success.

Raw material is where most folks get stuck. It’s the part that’s most easily used for procrastinating. Tools live in this category. And as we all know, not having the “right” tools is a convenient excuse for not proceeding. A hopeful film maker can spend unlimited time assembling the right camera rig. Writers will fiddle with software and note taking indefinitely. My peers, programmers, can jump from stack to stack without making any progress on the original idea.

Even if the tools aren’t the problem, hopeful creatives might not make it past step 2. The initial step of assembling raw material (words, photos, video, audio, colors, etc.) can be so intimidating that they leave the page blank. There’s too much pressure to create an instant masterpiece.

The irony is, the raw material is not what matters. The edit is what matters. The edit is where decisions are made. It’s where the idea can be expressed effectively. It’s where tradeoffs are considered and where a lot of the raw material is cut away.

Remixes are a perfect example of this difference. With the same instruments, vocals, and theme a skilled music producer can create two completely different songs with the same sounds.

This shouldn’t be intimidating. It should be a license to breeze through assembling the raw material. Write nonsense. Take photos of your front yard. Create a hacky python script. Remove the pressure.

Then you can get to work on the edit. Keep a high standard. But make sure it’s in the right place.

Stress Driven Development

Small teams that are creating something new have no shortage of problems. Among those is the question: What should be worked on right now?

I ask myself this question a lot while working at CaseFleet. One of the benefits of being on a (very) small team is autonomy. Autonomy, unfortunately, comes with the stress of responsibility. I get to choose what I work on because I’m also the person who is responsible for a large part of the company. That means support requests, maintenance, bug fixes, and many other tasks are also my responsibility.

So what gets done? How do I create any sense of priority from the endless stream of demands?

The answer to that question is: “I just know.” By necessity, the responsibility I carry comes with a large knowledge of CaseFleet’s product. I know where the product is missing a feature, poorly designed, or what parts of the infrastructure requires upgrades.

I can scroll through Clubhouse and feel the stress associated with each incomplete task. The one that creates the strongest response is the one I work on. Typically I don’t need to reference the list of outstanding tasks at all. I know for a fact which task is most important.

As a result of this process, the overall feeling of stress within the project should decrease over time. Eventually it will settle into an equilibrium where the amount of stress added by new projects is offset by the completion of others.

So, that begs the question: what is the task you know needs to be completed?


The internet has made us all venture capitalists whether we like it or not. Venture capitalists play a game of asymmetric returns. The vast majority of investments fail. But a few winners more than make up the difference (and add a healthy profit margin).

In the same way venture capitalists place bets knowing most will fail, internet creators play the same game. Most content created on the internet will never be seen. It will never be shared. It will never be noticed.

But a small fraction will explode. The exposure drawn from the 1 out of 1000 going viral is enough to make the other 999 worth the effort.

So how do you play the game to win? Take a lot of chances. Ship all the time. Create prolifically. Create deliberately. Don’t take shortcuts, but don’t self edit. The content that doesn’t make the cut won’t be noticed anyways.

On Choosing Your Stack

Note: The advice below applies when you are creating a product you intend to ship. It does not include investigating alternate technologies as learning opportunities or for fun. It also paints products with a broad brush. Sometimes technical decisions are made for you based on the requirements of what you’re trying to build.

Filmmakers and photographers often ask “What was that shot on?” Writers ask what software or note taking system is best. Musicians can spend days researching the best plugins for their production software. These are all very productive forms of not creating anything.

We web developers have an equivalent: What’s the best tech stack?

Tech Stack: a list of all the technology services used to build and run one single application.

I’m not one to prescribe technical solutions to folks who take sides in the stack argument. But there seems to be a lot of discussion around what stacks are “best.” Many times the most accepted advice is a mix between “it depends” and “whatever you know best.” But right behind that advice is a long list of trending libraries and buzzwords that are enticing. I find it very easy to get sucked into these discussions. I often find myself wasting hours of time trying to decide on the next best tech stack for a project.

To avoid falling into that trap here are some guidelines that I try to follow and need to be reminded of before I go down the rabbit hole.

Domain logic is what matters

Domain logic (or business logic), is what makes up your product. It requires that you understand a market. It fills a need or solves a problem. It’s what users interact with or what they would identify as a product. This domain logic can live in a myriad of frameworks. It can run on any number of cloud providers that in turn run any number of operating systems (read: linux distros).

Everything that would be considered the tech “stack” is at best one degree removed from the domain logic. It’s a means of delivering the domain logic. Perhaps it even facilitates a lot of the domain logic. But it is never what makes your product useful.

All other things equal, optimize for development speed

Rails vs Django vs Laravel. MySQL vs Postgres vs Mongo. AWS vs GCP vs Heroku. While each of these decisions have tradeoffs, many are subtle. But more importantly, problems typically only show themselves “at scale.” But that kind of traffic is hard to get in the first place. If you make it your mission to have “scale” problems, you’ll have your hands full for quite a long time.

So if those decisions are effectively inconsequential at the start, optimize for development speed. Choose the framework you know best. Choose the platform that will offer you compute credits for bigger, faster machines. But make those decisions quickly and get to building product.

Focus limited brain cycles on product

This is probably a more personal point than others in this post. However, I find that I have a time limit on the number of hours I can spend on development tasks in a week or in a month. Fiddling with infrastructure or writing out boilerplate depletes that reserve of time as much as building a feature or designing an interface.

The problem is that building product and solving domain problems is difficult. Often infrastructure and framework decisions seem more attractive. They’re endlessly optimizable. They don’t deal with the messy world of customers. But it’s important to remember why the stack is there in the first place.

Infrastructure should reflect a problem solved in production

There will come a time when the product pushes up against the tech stack of choice. When this happens, it’s time to shop for solutions elsewhere. In this way, your stack evolves to the needs of the product. You might even realize why so many large companies have built these hyped technologies as they have grown.

This requires some discipline and honesty about how to solve certain problems. Does your frontend performance problem need to be solved with a react based, redux backed, GraphQL calling, but server rendered interface? Or could you get by with some smart caching and basic jQuery? I can’t answer that question. Perhaps you do need that kind of setup. But you probably don’t. Facebook built React when it reached Facebook level problems. If you reach Facebook level problems, those are great problems to have.

What’s missing from this list? Drop me a note on Twitter and I’ll amend it.

Hello World

While I don’t find myself with a lot to say to others, I do find myself wishing I had more written down for myself. That’s the primary purpose of this website.

Categorized as Misc