First and foremost turn off all notifications or, at a minimum, silence them so they don’t interrupt your flow state. The kinds of notifications you want to disable is social media, syndicated feeds, email, group chat, source code issues/reviews, and so forth.

You might think you can tackle multiple things at once but the human brain isn’t wired to work like that. What’ll you end up doing is a lot of shallow work with a higher chance of introducing issues which could have been mitigated if given your full attention. This creates more work which is the opposite of the desired outcome you started with.

Your super power is to remain deeply focused on your task at hand, completing it, and moving on. Even better, this gives you the space to see connections to other aspects of your architecture which can be refactored or improved upon further because you have the time to think deeply, detect duplication, and optimize your code base further rather than trying to complete as many tasks in as little time as possible.

Any interrupts, while working in this flow state, should be immediately added to your second brain (example: Obsidian) so you can tackle after your task at hand is complete. Interrupts in this context, would be new discoveries, new solutions, refactorings, deletion of dead code, etc. Important to identify but better to address afterwards.

When you turn off notifications, you put all the power back in your hands. You dictate when and how you’ll tackle interrupts not the other way around. This is the first step in being proactive instead of reactive. Welcome, friend.

At one point, The Changelog used to sign off with the adage: "Open source moves fast, keep up!" They are correct because the minute you fall behind, the technical debt rises which makes updating your software projects that much harder.

The best way to stay abreast on what’s changing in the world is through Syndication. This empowers you to manage your own curated sources of information while your feed reader works tirelessly, in the background, to inform you of updates.

At a minimum, your feeds should be checked morning and noon every day via this simple workflow:

As with notifications, you control when you catch up on the news, not the other way around. This allows you to fold in changes as you see them with minimal effort. For example, upgrading to the latest Ruby patch or gem update because it’s a lot easier to address changes as you see them rather than upgrade a bunch of gems at once. This is made even easier when your test suite is at or near 100% code coverage so you have even more confidence to upgrade early and often.

As done with personal hygiene, physical exercise, eating healthy foods, and getting plenty of sleep, your Machine Upkeep is equally critical to augmenting your mental and physical abilities. This means the upkeep of your machine should be performed every other day. On a weekly schedule, this means Monday, Wednesday, and Friday at a minimum. Do this before the start of your work day.

In addition to keeping your machine up-to-date, the same must be applied to all projects you maintain. Bash or Ruby scripts are extremely valuable in automating this workflow. For plenty of examples, feel free to pilfer from the following projects:

Having this kind of automation in place reduces the friction of upgrading your projects so you can quickly resolve any issues and move on. This also means you’re more likely to perform upgrades, once detected, instead of pushing off until later. This is exactly the kind of workflow you need in order to prevent tech debt from building up.

To illustrate further, each RuboCop release almost always takes time to read through the release notes because the project doesn’t adhere to Milestones or always has documentation updated in lock step with each release. This then requires chasing down the source code to get better examples of what has changed and/or testing out each cop individually so you can make atomic commits to your own code to explain the what and and why of the change(s). Doing this work per version release is less time consuming than putting this off and tackling all changes at once which can take a day or more.

There is another benefit, not often discussed enough, which is retaining and attracting new talent because the joy of working in a well maintained codebase increases productivity due to less friction of fighting with broken aspects of your tech stack. Fixing a bug or adding a feature should be enjoyable and effortless as possible. This doesn’t mean the problem you are tackling isn’t a challenge or takes time to accomplish, only that you shouldn’t be constantly fighting against the software stack you are working in.

As written in Atomic Habits by James Clear, ensure you turn all of the above into habits. Ideally, you don’t want to think about them but intrinsically do them as part of your daily flow. To aid in this endeavor, lean on your second brain (or task managing software in general). For example, consider using the following workflow at dawn and dusk each day:

💡 At dusk, one key difference is not to reflect on yesterday’s learnings but the current day’s learnings instead. This is also a good chance to capture any further notes from the day in which to reflect upon tomorrow.

The above should be on a reoccurring schedule that appears at dawn (Example: 6am) and then again at dusk (Example: 5pm). Any task managing software (trusted system) can automate and ensure these actions are front and center.

The above framework puts you in control so you can do what you do best with a strong emphasis on high quality output. Most importantly, you are in control which means you are being calm, collected, and proactive in your actions rather than reacting without having time to think.

Once you have your daily habits in place, make this a core part of your culture. You do this by avoiding hiring anyone who doesn’t have (or can’t learn) these habits and fire anyone who can’t maintain this discipline. Remember, each person you add to your team should raise bar and reinforce the culture, not lower.

In this Age of Slopware, Enshittification, and lack of code quality in general, we need more engineers that show up day in and day out with professional etiquette that doesn’t tolerate anything less. Being proactive puts you in control by allowing you to tame the chaos and have a solid structure in which to build amazing cultures, teams, products, and services.

We can all do better and being proactive aids in this endeavor. Make this a priority so you can enjoy the work and the people you work with.