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.

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.

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.

Jerod, KBall & Nick “Holla!” at React India, share what we’re excited about these days, and then take up a KBall topic that goes off the rails but manages to climb back on them, power through, and end up in a good place.

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.

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.

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.

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.

This excellent “pragmatic guide to getting things done” distills down many of the teachings in David Allen’s best-selling book that popularized the system.

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.

A ranty story from Kitze on a time when he didn’t ship the app he was working on and somebody else did!

It’s not their fault. I was just slow. I didn’t ship on time. I’m gonna go ahead and tattoo “JUST SHIP IT” on my forehead. Nah I wouldn’t be able to see it there. On my arm maybe. Nvm, let me go back to scrolling their landing page.

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.

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.

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

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.

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.

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.

It’s like having Alfred all up in your browser.

Manage tabs, bookmarks, your browser history, perform all sorts of actions with a simple command interface.

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.

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!

If Microsoft can rip off be inspired by Notion, what’s stopping open sourcerers from getting in on it? 😜

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!

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 😉

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…

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.