A simple programming productivity trick: leave work unfinished to reach flow

4 simple programming habits that transformed my productivity

“Your outcomes are a lagging indicator of your habits.” - James Clear

As I became a better software engineer, I noticed 4 key habits in my daily workflow that had made me much more productive.

---

Dev Starter Packs (Sponsored)

Dev Starter Packs has 100+ pre-built, interactive, beautiful React Native components to help you build your mobile app faster. The components are used in mobile apps today with thousands of users and are constantly being updated weekly with new ones.

Similar to Tailwind UI, these components are lifetime access with more 200+ more components planned to be released. Dev Starter Packs also has a full-featured Next.js boilerplate and a fully-integrated React Native boilerplate, both offering easy payments, auth, logging, and error monitoring setup. With a holiday sale ongoing, don’t miss out - build your ideas in 2025.

---

1. Leave work slightly unfinished for easier flow the next day

“Flow” is the root of productivity when programming. 

Since software engineering is a “maker” activity where I’m producing something, I generally perform best when I have a large block of uninterrupted “flow” time to work on a project.

However, it can often be really hard to get into flow if you’re stuck scrambling on what tasks your project goals entail. Ambiguity is difficult to deal with. Not even knowing where to start can make reaching that “flow state” much harder.

Each successful action snowballs into more.

There are a few techniques I use to do this:

• Stop right before a “sticking point.” A sticking point is a task that’s part of a project where I know the steps to do to complete it, but I don’t know if there are hidden costs. 

  • For example, if my sticking point is deploying my ML model and HTTP server to a dev instance and verifying that it processes requests properly, then the hidden costs are deployment errors, authentication errors, resource constraints, etc.

• Write down the next steps extremely clearly. Writing down steps makes regaining context and the state of mind from the day before easier.

  • Make them actionable and unambiguous.

2. Get better at keyboard and mouse shortcuts

My first experience with a real “shortcut ninja” was actually not with a software engineer. It was with my investment banker friend, who sped around his Excel sheets without ever touching the mouse. 

This, except I finally did appreciate it years later. Source: Work Chronicles

After that, I took the time to learn keyboard shortcuts, to the point where I grab my mouse ~60% less than I used to. (Yes, I tracked this.)

It’s not just me! Sam Altman has a quote on this in his Productivity essay:

I also made an effort to learn to type really fast and the keyboard shortcuts that help with my workflow.

Every editor and tool in my workflow has keyboard shortcuts for pretty much any action you can think of. This doesn’t just apply to your IDE, but also your version control systems, your web browser, and your docs.

For example, my IDE has a linter/formatter/cleaner all in one shortcut, which I use often as I write code to make sure lines stay neat.

I commonly use Command/Ctrl + Shift + V to paste in text without formatting in docs and chats.

Pressing . (period) on a GitHub repo page will automatically open up the repo in a VSCode Web instance.

Source

When I do need to touch my mouse, it’s configured with shortcuts also. I’m lucky enough to have a mouse with buttons on the sides. I’ve programmed these buttons to switch between Spaces on my Mac, though you can program them for whatever feels intuitive for you. (You can even program them to be different per program.)

The best way to learn shortcuts? Introduce the most common parts of a program that you use, one a time.

For example, if you find yourself right-clicking to format your code often, that can be the first one you “practice.” Every so often, add a new shortcut to your repertoire and use it naturally as you code throughout the weeks. Over time, the shortcuts will be muscle memory.

3. Keep a list of searchable commands and links handy

I commonly have to run a set of common commands on my terminal.

I have certain pages that I always visit and some notes about various languages that I always come back to. For example, I simultaneously use templates too rarely and yet too often when writing C++, meaning I usually need to reference the docs when using them.

Instead of digging around documentation pages or constantly looking through my terminal history, I keep commands and common doc lookups in a giant doc with one word describing the command. I call it my Big Book of Commands, which is around ~10 pages long now. I’m easily able to find any command I need with a quick Ctrl+F. Then, a Shift + Command + ➡️ is a full line-select for an easy copy-paste.

I also have a few common macros programmed into my keyboard for the commands and terms, like hard-to-remember ACL groups. Sometimes, I utilize Terminal aliases.

My friend

Jordan Cutler

wrote a great article that dives into his own workflow tips, which starts off with a great primer into aliases, keyboard shortcuts, and tools: The top 7 software engineering workflow tips I wish I knew earlier 🧰

4. Say “no” more

This is less directly programming related, but I learned to say “no” to things.

I said no to novel technology when boring technology would do the job.

I said no to automating something when it only needed to be done once manually.

I said no to more tasks when I knew I was already overloaded with work (even though my people-pleasing mind pleaded to take them on).

I said no to scope creep suggested by our designers.

I said no to low-impact tasks.

There’s an xkcd and a Work Chronicles comic for everything.

Learning to say no was harder than I expected, yet one of the most valuable skills I’ve applied in both the workplace and in my personal life.

Sometimes, it’s painful to say no to things. In both my career, hobbies, and personal life, there are times I say no to things I really want to do. But I don’t because I know my time and energy is better spent on what I’m currently focusing on.

It’s a cliche to quote Steve Jobs, but I remind myself of his famous quote “focus is about saying no” often.

My friend

Irina Stanescu

also has a fantastic article about saying no, which I highly recommend: The Software Engineer's guide to saying "no"