How to Program Yourself to Program Better

After more than a year of programming, I’ve started to notice some peculiar habits. For a while, these habits seemed like odd tics, until enough of them developed and a pattern emerged.

I had begun programming myself.

Strewn across my digital brain were programs for various parts of my life. When I went to the dog park, I’d reference my dog park program. Upon arriving at work, I’d begin my startup program. When I left for work, I’d execute my shutdown program, which made me feel an eerie kinship with my laptop.

What started as a minor oddity has become a bona fide part of my life. And a good one!

Today I’d like to share with you how to program yourself. And hey, if it doesn’t work for you, you’ll at least have gained some empathy for the computer you’re always bossing around.

A Self-Programming Example

Before we dive into how to create a human program, I’d like to start with an example of my most important program: startup.

Startup Program

– Do a “Write About” on Remarkable
– Review “Things to Know” for today
– Startup iTerm and login to VPN
– Startup Single Sign-On and login to AWS
– Sign in to Github
– Do Health Screener
IF WFH
– Open blinds
– Open “work” scent
– Play Nick Drake

My startup program is invaluable because I am not a morning person. If I didn’t have a 1-year-old dog and an 8:45 a.m. stand-up, I would never be awake before 9 a.m.

Thus, for bleary-eyed morning me, limiting morning thinking (and distractions) is critical. By giving myself a script, I make sure I don’t miss anything while easing myself into the day.

A good script can hardcode wins into your day early and start you off right. So how do you make one like my startup program?

Thankfully none of my self programs are as extensive as actual code.

What Doesn’t Work for Self-Programming

To figure out what makes a good program, let’s start with a bad one. While my startup program compiles and runs like a charm, my troubleshooting program has never once run.

I’ve spent months working on a coherent process for troubleshooting problem-specific problems. Not once have my labors produced anything useful. After seeing my other programs succeed, I know why the program never materialized:

• Consistency: What I am troubleshooting changes with the wind.
• Scope: I troubleshoot a wide variety of technologies across all parts of my projects.

Atomic is in many ways a company that self programs with smart processes.

Consistency

Programs that exist on shifting sands don’t work. In other words, if you can’t predict what you will need to do in a given situation, you can’t create a process for it. This is why we have a process for planning work (Agile) but not for implementing it. The planning process is (relatively) stable, while the development work is rarely so.

Scope

The scope is important for programs for the same reason constancy is: predictability. The larger the scope, the harder it is to create a reliable process. My current project has eight developers on it, which means the scope grows fast. My troubleshooting program never stood a chance.

What Does Work for Self-Programming

If you haven’t guessed it by now, what does work are programs that limit the scope and deal with stable domains. But, these conditions are not present in the wild, and you must create them with abstraction.

To give an example of abstraction at work, let’s look at my problem-solving process.

Problem Solving Program

1. Write your feelings.
2. Draw/write the problem.
3. Write a failing test.
4. Write down the next action.
5. Set a timer for 15 minutes.
6. Ask, “Do I need help?”

Why is the above process better than my attempts at a troubleshooting process?

It’s context-independent. By abstracting troubleshooting away from my specific project, I was able to limit the scope to problem-solving.
Problem-solving’s structure is similar wherever you go. You need to get to the root of the problem (deal with emotions and visualize). You need to identify success (write a test). And you need to create boundaries for your solution (in this case I use time).

Whenever you find yourself battling a program, whether, for a human or computer, it helps to take a step back.

Bonus for the Curious

As a reward (or punishment) for those still reading, here’s a couple of final steps to take your programs to the top.

Version your programs.

I version all my programs with the date of the most recent change so that I can see the trajectory of a program. If I see a consistent shift away from an attempted practice, I can pivot and keep my program up to date.

Link your programs.

I recommend trying out linked notes (Obsidian & Roam) regardless of what you are doing. Combining programs with linked note-taking software allows you to trace the evolution of your programs. There is a lot you can do with that, like writing a last-minute blog post without spending time tracing your sources.

Adapt your programs.

Your programs shape your behavior, but the process should go both ways. I’ve made the mistake of treating programs as gospel. Don’t do the same. Change your program when it stops working for you, or it will become meaningless.