I'm starting something new. Read the manifesto →

The War on Developer Productivity (And How I Intend to Win It)

Do you remember the first time you used Slack at work?

I vividly recall the impact it had on our mostly-distributed startup crew. For the first time ever I felt connected to my remote colleagues as if we were in the same building.

“Now we’re cooking with gas,” I told myself.

Anytime I had to ask my co-founder a question, he was just a quick DM or @-mention away — the digital analog to a tap on the shoulder. This proved to be much faster than firing off an email and waiting for a reply.

I realize this is not news to you now, but five years ago it was pretty ground-breaking.

Slack felt like the much-needed grease in the gears of our budding startup. It brought visibility to conversations that would have otherwise been trapped in an email silo. It lowered the barrier of formality that plagues email correspondence. It increased the velocity of communication.

Simply put, it ended the need to wait.

In the beginning, this seemed like an indelible leap ahead. Fast forward five years, and I’m convinced it has become the single greatest threat to developer productivity in the modern workplace.

The problem is that today’s chat tools are amplifying the troublesome parts of human nature, rather than minimizing them.

  • We are impatient.
  • We feel anxiety for “unread” badges.
  • We are addicted to push notifications.
  • We think things are more urgent than they really are.
  • We care about our team’s perceptions and don’t want to look like we’re slacking off.

Don’t get me wrong, chat is not intrinsically bad. It’s part of what made Slack feel so magical at first, and it’s a key ingredient that is here to stay. The ability to engage with your team in real time is vital — but only when the discussion must be synchronous.

Chat is a greedy mode of communication.

  • It doesn’t care if you are deep in flow.
  • It begs you to incessantly clear its notification badges.
  • It buries important conversations among idle chatter when you snooze it.
  • It must be used with restraint or it becomes toxic.

You might be thinking, “Slack is not broken, you are just misusing it.”

In theory, I agree with that sentiment. Slack is built for synchronous communication. If your team has the discipline to only use Slack for real time conversations and hold asynchronous discussions elsewhere (via email, inside a project management app, etc.), then you have achieved a rare feat.

For the rest of us, that is simply not our reality. I co-founded Drip (acquired by Leadpages in 2016) and led engineering there for the last five years. In that time, our use of Slack scaled from just me and my co-founder to over sixty people. Despite my attempts to redirect discussions to their “proper” forum, our team’s use of Slack only escalated.

The cognitive overhead of always choosing the ideal place to hold a conversation proved to be too high.

The truth is that makers feel the pain much more than managers. A manager’s job is to be available for interruptions by their team. An effective manager is one who provides servant leadership and strives to keep their team unblocked.

Even the most respectful manager will inevitably interfere with maker time because Slack does very little to prevent it — in fact, it encourages it.

As makers:

  • We know that most discussions are not so urgent they warrant breaking flow
  • We know the painful cost of context switching
  • We’d much rather be “addicted” to our craft than our chat tool
  • We believe that unmitigated access to our push notifications is damn near criminal

Having spent most of my career crafting and architecting software to make companies more efficient, this is not merely a business challenge worth solving — it’s a personal mission.

We are undeniably standing on the shoulders of giants. Slack (and other similar chat tools) have made many great contributions to the fabric of the modern workplace. They’ve proven the value of housing team discussions in a central place. They’ve demonstrated that it’s possible to feel connected even when distributed. They’ve served me more animated GIFs than I ever could have imagined.

And yet, their flaws are killing developer productivity. We must establish a healthy balance between asynchronous and real time communication, and restore the promise of connecting teams without all the chaos.

Isn’t it time your main productivity tool actually made you more productive?

If this resonates with you, I need your help! Drop your email address below to voice your support. I promise, no spam. I’ll keep you in the loop about new developments in my quest to solve this problem. 🌟🌟🌟

Continue reading →

Transactions in Phoenix

I recently set out to implement user registration for a project I’m working on in Elixir/Phoenix. It wasn’t long before I encountered a challenge that I have stumbled upon with every other ORM library: accepting a collection of form inputs and saving it across multiple (related) records in the database.

There’s more than one way to tackle the problem (with varying degrees of elegance), but I discovered that Ecto lends itself particularly well to solving this problem once you are familiar with tools available.

Continue reading →

Announcing: The Art of Product Podcast

Since August 2016, I’ve had the pleasure of being a regular guest co-host on Giant Robots Smashing into Other Giant Robots along with Ben Orenstein. I’ve been a long-time podcast consumer, but was initially reluctant to try my hand at recording myself. After some healthy prodding from Ben, I agreed to try a few episodes and, lo and behold, we’ve been recording ever since.

A few weeks ago, Ben dropped the news to me that he was moving on from Thoughtbot to start his own business. This left us an interesting new storyline to tell and no podcast on which to tell it!

So in true scrappy bootstrapper form, The Art of Product podcast was born. We plan to release one ~30 minute episode per week and continue with the same format from Giant Robots, discussing whatever interesting things we’ve been up to recently.

Have a listen and leave us a 5-star review in iTunes if you dig it!

Solving Our Slow Query Problem

One of the core features of Drip is the ability to segment your subscriber database by tags, custom fields, events performed, campaign and workflow subscriptions, and so on.

As our Postgres dataset has grown into the multi-terabyte size range, these ad-hoc segmentation queries have become increasingly expensive to run, especially for accounts with many thousands of subscribers and millions of subscriber events.

Continue reading →

When To Build Your Own Billing Engine

Back when we started Drip in 2012, it was customary to write your own recurring billing engine.

Fundamentally, a SaaS billing engine is simply a scheduled task that runs each month for each customer and hits a payment API to charge them. Layered on top that is the concept of pricing tiers, trial periods, failed charge retry, proration, annual plans, and invoice generation.

Most developers these days choose not to build their own billing engine, as free platforms like Stripe subscriptions promise to rid your application code of complex billing logic. It seems like a no-brainer, right?

Continue reading →

Choosing the Perfect Tech Stack

Nothing quite compares to greenfield software development. The canvas is blank and you finally have the opportunity to do it “The Right Way” from the ground up. If you’ve been building web apps for a while, you’ve undoubtedly found yourself working with technologies that you’d never use again, given the luxury of a blank canvas. And if you follow the open source world, there’s probably a brand-spanking-new boutique framework you’ve been itching to take for a spin.

With all the excitement of a blank canvas comes an equal amount of anxiety. You know you are one ill-advised choice away from being stuck with the “imperfect” tech stack. You have a hunch about what you want to use, but being the dutiful engineer that you are, you spend a few hours verifying your assumptions by Googling “Ruby vs Go” and “nodejs vs haskell” only to find yourself with net loss of clarity. (Don’t do that.)

Take a deep breath, it doesn’t have to be this hard.

Continue reading →