Personal programming projects are a great way to explore new topics. They can allow you a scaffold for exploring new technologies or techniques. They can use a personal interest as a motivator to overcome the trials of learning. But they compete for your limited time with your responsibilities, friends, and family. Sitting down for a large chunk of time to work on your project may be infeasible. So, how can we learn to manage a personal project on a time budget?
Why don’t we work on personal programming projects?
If we’re going to fix a problem, we should understand some of the causes of the problem.
The fuzziness of purpose leads to a feeling of ineffectuality. If you don’t have a clear purpose when you have time to start working, you have to spend all your time rebuilding your to-do list and reprioritizing it. This can take the wind out of our sails, dampening our enthusiasm and momentum.
There is a cost to switching context. Let’s use a cooking example to illustrate common hurdles:
- How likely are we to cook a healthy meal when we have to get out the correct pans, utensils, and ingredients?
- And then laboriously break down and process those ingredients before waiting for the cooking to complete?
- What if a microwave meal is close to hand and minutes away? What if the pots you need are unwashed?
- And if you don’t have a planned menu?
The choice to do a task is weighed against the TOTAL time to do the task. And often, we put more weight on the time spent BEFORE we even begin what we see as the actual work. If it takes 20 minutes to set up a five-minute task, it stops looking like a fun five-minute diversion.
Existing habits are hard to overcome. If our routine is to scroll social media when watching TV, we often start scrolling before we have picked up any alternative fidgets we may prefer, such as our knitting, sketchbook, or guitar. Soon, the time we planned on spending following our passions dwindled and was unexpectedly used up before we even began.
These are some of the forces that compete to keep us from successfully managing personal programming projects on a time budget.
Small Ways to Fit Personal Coding Projects Into Your Time Budget
Scope Down
Before we sit down to work on our project, it would be helpful to have a clear idea of the concrete steps we need to take to ‘complete’ it. I put ‘complete’ in quotes because the purpose of our project might not require it to be perfectly polished and feature-complete.
If the project fulfills a personal need, for us or for a friend, we can focus on solving the most pressing part of the need. Not only to we begin to see value from our work sooner, but like any MVP (minimum viable product), we can stop once the value of a new feature is less than the opportunity cost of a different project or other activity. And if it solves our own problem, we don’t need to make it ‘user friendly’ for a general audience.
When the point of a project is learning, we can focus our task list on driving out that learning. We can start with tasks that address fundamentals, followed by what has the most learning potential. In this case, leaving a wake of half-realized features riddled with partially solved corner cases might be good enough. Does it matter that I don’t have a ‘Forgot Password’ implemented when we’re the only one using it and we can reset our password via database access? Do we need to save our ToDo list items to a database if we really only want to learn how to handle animated interactions?
By remembering the mission of the project, we can prioritize our tasks to extract value out as quickly as possible. After all, we are managing this personal project on a time budget.
Work Smarter
The time we spend on a personal coding project doesn’t isn’t only the time we can be behind the keyboard. The time we spend in the pick-up lane or the doctor’s office can be spent researching APIs or algorithms. We can fill our phone’s browser with pages from API documentation, StackOverflow, and blog posts. We can write notes and clip the relevant details for later. When it is finally time to sit down, we now have a clear hypothesis of what we are going to try.
Our dev environment should be fast. Not necessarily fast to compile, but fast to get started. CloudFlare uses the phrase Time to First Dopamine to remind themselves that we need to see results quickly. If we need specific environments, we can try using dev containers to coordinate databases and other environment needs. If we have several tools that work together, like Postman, a browser with specific pages, Xcode, and the iPhone simulator, we can script their launch using a tool like Bunch. That way, when we sit down to work, all our tools are right to hand.
Focus on small commits. The smaller the diff from the last commit, the less time we spend trying to figure out what just went wrong. We should be thinking of our commits as quick saves, not as completed features. If your limited time doesn’t result in forward progress, you can always reset and not worry about remembering what you were in the middle of when you finally get another chance to work on this project.
Our ideal to-do list is a stack of short tasks with no dependencies. We don’t want large tasks that may take a whole month of calendar time because we only have an hour a week to actually work on the project. If we do have dependencies, consider using the Mikado Method and using a Directed Acyclic Graph to track your tasking.
Rome wasn’t built in a day.
The amount of change you see in your project will be reflected by the amount of time you can afford to spend on your personal coding project. You can invest more time by carefully noting what you can do in the moments between. You can increase your return on the time spent by carefully choosing what’s next. And that is how you manage a personal project on a time budget.
Build awesome things for fun.
We love to make things. That’s why we host hackathons, game jams, and maker weekends throughout the year via SEP Makes.
You Might Also Like
