Productivity Icon


Getting stuff done. Better. Faster. Stronger.
78 Stories
All Topics

Jim Nielsen

Deadlines as technology

Jim Nielsen:

I heard Paul Ford, a professional writer for Wired and other publications, say something on The Aboard Podcast, Episode 3 that resonated. Referring to a moment when lots of folks online were looking for the perfect writing environment, he said the software tool, workflow, environment, whatever, it didn’t matter. You could do it with pen and paper if you want.

The only technology that you need is deadlines.

Ooff. Yup, that resonates. That’s been the best piece of technology for making me productive too.

See also arbitrary deadlines are actually awesome by yours truly.

Changelog Interviews Changelog Interviews #514

Beyond Heroku to Muse

This week we’re back for part 2 with Adam Wiggins — going beyond Heroku and the story of Muse (listen to part 1). After a six-year adrenaline high on Heroku, Adam needed time to recover and refill the creative well. So, he moved to Berlin, did some gig work with companies…dabbled in investing and advising. But he wasn’t satisfied. Adam likes to build things.

Ultimately, he was just waiting for the right time to reconnect with James Lindenbaum and Orion Henry — the same fellas he created Heroku with. Eventually they founded Ink & Switch, an independent research lab which led to innovations that made Muse possible. Muse is a tool for deep work and thinking on iPad and Mac. Today’s show is all about that journey and the details in-between.

Jerod Santo

Arbitrary deadlines are actually awesome

After reading Lucas da Costa’s Why deadlines are pointless and what to do instead, I agree with almost every point he makes, especially this one:

It’s about time we start calling deadlines by their real name: pressure

Lucas goes on to describe how deadlines can cause harm, can’t actually make people code faster, and so on. I agree with that too. But does that make them pointless? Not necessarily!

Sometimes a little pressure is just what the doctor ordered. Here’s what I mean by that.

Greg Kogan

Being swamped is normal and not impressive

Greg Kogan:

I used to think being swamped was a good sign. I’m doing stuff! I’m making progress! I’m important! I have an excuse to make others wait! Then I realized being swamped just means I’m stuck in the default state, like a ball that settled to a stop in the deepest part of an empty pool, the spot where rainwater has collected into a puddle.

Good analogy. Better sentiment. Reminds me of Woody Zuill’s thoughtson productivity vs effectiveness.

Martin Heinz

Data and system visualization tools to boost your productivity

As files, datasets and configurations grow, it gets increasingly difficult to navigate them. There are however many tools out there, that can help you to be more productive when dealing with large JSON and YAML files, complicated regular expressions, confusing SQL database relationships, complex development environments and many others.

Changelog Interviews Changelog Interviews #492

Two decades as a solo indie Mac dev

This week Jesse Grosjean joins us to talk about his career as a solo indie Mac dev. Since 2004 Jesse has been building Mac apps under the company name Hog Bay Software producing hits such as WriteRoom, Taskpaper, and now Bike. We talk through the evolution of his apps, how he considers new features and improvements, why he chose and continues to choose the Mac platform, his business model and pricing for his apps, and what it takes to build his business around macOS and the driving force of the App Store.

Changelog Interviews Changelog Interviews #491

Stacked diffs for fast-moving code review

This week we’re peeking into the future again — this time we’re looking at the future of modern code review and workflows around pull requests. Jerod and Adam were joined by two of the co-founders of Graphite — Tomas Reimers and Greg Foster.

Graphite is an open-source CLI and code review dashboard built for engineers who want to write and review smaller pull requests, stay unblocked, and ship faster. We cover all the details – how they got started, how this product emerged from another idea they were working on, the state of adoption, why stacking changes is the way of the future, how it’s just Git under the hood, and what they’re doing with the $20M in funding they just got from a16z.

James Simone

The life & death of software

James Simone ponders the relationship between healthy teams and performance in the software world.

Here’s what it comes down to: teams perform well when successes are shared and failures are owned… We don’t celebrate successes enough, and part of that (I think) is caused by the feeling of pressure that comes from working on a project that seems dooomed to fail without meticulous and ever-present attention.

He goes on to delve in to the source(s) of engineering failures, the dangers of “brightsizing”, known predictors for project success, and a bunch of related topics. Lots to ponder here alongside James, who’s seen a lot of software projects live & die during his eight years in the business.

Dominick Schroer

The joy of small projects

Dominick Schroer:

When was the last time you completed a project? When was the last time you started a project? Have you every felt that you were trapped working on something that you don’t enjoy anymore? Size is something that I’m sure most developers with the drive to do side projects have felt. Recently I have been completing more projects with more success than ever before. This is my new process.

His 4-step process is so simple it might be brilliant.


A plaintext file format for todos and check lists

For now, [x]it! is merely a file format specification.

You don’t have to use a specific tool for .xit files, the basic operations like creating items or checking them off can be done in every text editor. Tools can make the experience more convenient, though, and provide support for common use cases.

The cool thing is anybody/everybody can now develop integrations for their favorite tools.


Plaintext productivity on Windows

This guide is meant to document the things I have done, the software I have used, and the decisions I have made to be really fast and really well-organized at work, and to help prioritize and maintain focus on my current activities. One key decision, made for speed above all else, is to capture as much of my thinking and work in plaintext as I can. Thus the name: Plaintext Productivity

This article speaks my language, but does so to a corner of the software world that I don’t visit too often: Windows

Windows is a critical element in this system because it is hard to find good productivity software that runs on Windows, especially if you want to run it outside of a web browser. Windows, in my opinion, is far behind Mac OS X, iOS, and Android, in having thoughtfully designed and efficient software—both in general, and in particular for writing, organization, and task management


Write plain text files

Derek Sivers:

I write almost everything important in my life: thoughts, plans, notes, diaries, correspondence, code, articles, and entire books.

They are my extended memory — my noted self — my organized thoughts. I refer to them often. I search them, update them, and learn from them. I convert them into HTML to make websites, or LaTeX to make books.

My written words are my most precious asset. They are also a history of my life. That’s why I only use plain text files. They are the most reliable, flexible, and long-lasting option. Here’s why.


My thirty years of dodging repetitive work with automation tools

Conor O’Neill:

I blame my life-long work obsession with automation and avoiding repetitive drudgery on my first boss and mentor Danny in S3. He was horrified to see me doing the same thing over and over in a VAX code editor and introduced me to the magical world of macros.

From that point onwards, I was a man on a mission to save us all as much time as possible in our working days.

From Yahoo! Pipes to IFTTT to Node-RED and beyond: this is quite the journey.


Effortless personal productivity (or how I learned to love my monkey mind)

Jakob Greenfeld:

I recently discovered a simple step-by-step process that significantly increased my personal productivity and made me happier along the way.

It costs $0 and no, it’s not some note-taking or to-do list system.

The steps are:

  1. develop meta-awareness of your state of mind.
  2. pattern-match to identify your mind’s most common modes.
  3. learn to pick activities that match each mode.

But that probably won’t hit home until you read through his explanation of each step.

Changelog Interviews Changelog Interviews #472

AI-assisted development is here to stay

We’re joined by Eran Yahav — talking about AI assistants for developers. Eran has been working on this problem for more than a decade. We talk about his path to now and how the idea for Tabnine came to life, this AI revolution taking place and the role it will play in developer productivity, and we talk about the elephant in the room - how Tabnine compares to GitHub Copilot, and what they’re doing to make Tabnine the AI assistant for every developer regardless of the IDE or editor you choose.


The "5 whys" productivity technique

When your productivity takes a nosedive, it adds stress and anxiety, as you don’t have enough time to accomplish your goals and do what really matters to you. Understanding why your productivity is flailing will help you get back on track.

The idea is simple: ask “why” 5 times, until you get to the root cause of your issue. It’s not dissimilar to a kid who exasperates their parents by continually repeating “why”… but the benefits can be transformative!

The "5 whys" productivity technique


A simple script to print the last 10 commands you ran in this directory

What was I doing the last time I was here?

We’re linking to the repo, but the idea is where it’s at. The code is a one-liner (if you’re using zsh)

grep -v "jog" ~/.zsh_history_ext | grep -a --color=never "${PWD}   " | cut -f1 -d"|" | tail

Then you add this to your .zshrc

function zshaddhistory() {
	echo "${1%%$'\n'}|${PWD}   " >> ~/.zsh_history_ext

Now you’re all set for the next time you need to jog your memory!


Slow down, finish faster

Brian Di Croce writes a few thousand words saying SLOW DOWN in different ways. And it’s good!

Don’t race yourself to a burnout or a weaker desire to work in this creative field. Slow down. Know what you’re doing before you start typing the first line of code. Make sure that you understand what needs to be built. If what needs to be built isn’t 100% sure by anyone, then accept the reality that it might have to be built incrementally. It’s not the ideal, but sometimes it’s real.

If you’ll allow me to pick one nit with this post: successful software is rarely finished. And if you’re making successful software you likely won’t finish either. So, I would suggest wording this slightly different: Slow down to go faster 😉


Speed matters

Jamie Brandon on improving how fast he can work.

There are ~33k characters in the rematch repo, most of which are tests. I type ~500 characters per minute. So if I could sit down and type the correct code first time, without making mistakes or getting distracted, it would take 66 minutes. I don’t see any fundamental reason why I shouldn’t be able to at least approach that bound for such simple code - maybe get within 3 hours, say. So there is potentially room for another 10x speedup.

So let’s suppose a 10x speedup is within reach…


TODO apps are meant for robots

The opener on this post by Alex Kotliarskyi spoke to me so deeply I felt like I wrote it myself:

In my lifetime I’ve tried a dozen todo apps. In the beginning they all seem different, novel and special. Slick UI, shortcuts, tags, subtasks, the list goes on and on.

But all our stories were the same: I start using the new app, then after awhile I stop using it.

Even my most minimalist system ever eventually fell by the wayside. Alex is on to something here, and whoever figures it out will be able to check “succeed” off their TODO list.

Player art
  0:00 / 0:00