In the Tiny Experiments framework, the first step is to list and sort your ideas or unfinished projects into three categories:
- Drop it: It seemed like a good idea at the time, but it's just not.
- Defer it: Possibly a good idea, but you don't have the time or resources to work on it right now.
- Do it: A good idea that also has the potential to either be profitable, build an audience, help a lot of people, or take you to the next level of your career.
A few readers of Developer Microskills have written in asking me to go a little deeper on this, specifically: how do you decided what goes in the "do" bucket? How do you prioritize projects and decide what to do?
Of course, I can't give you a perfect formula for this. If we humans could know exactly what to prioritize at any given time, we'd have solved all of the world's problems by now. I can tell you what I've learned through research, experience, and observation.
Determining What's Most Important
When you're looking at projects to take on -- and that could mean feature development, content, or side projects -- there are a handful of different modalities or lenses you'll want to consider with regard to their benefits:
- Learning: starting something for the first time or digging deeper into a skill
- Impact: especially useful for dev rel, but could be quantitative (views, followers, impressions) or qualitative (positive feedback, community goodwill)
- Revenue: money made or money saved
- Maintenance: building or repairing systems, improving processes
- Happiness: sometimes you just need to have some fun
The reason prioritizing projects is so difficult is that it's a moving target. Priorities change over time. Sometimes you need to optimize for learning, sometimes for revenue, sometimes for maintenance, and sometimes for impact. Sometimes you just need to have some fun so you don't burn out.
The trick to prioritizing is getting a sense of balance. I like to ask myself three questions:
- What's the most important focus right now?
- What's the most important focus over the next year?
- What's been neglected lately?
Often the most important focus right now is "whatever is on fire," which is frequently driven by money (directly or indirectly): getting more customers, getting that new job, or starting some sort of side hustle. These things do need to get done, but the other two questions help balance that out so you're not constantly chasing urgent tasks and neglecting underlying important issues. Maintenance is the classic example of this: ignore maintenance on any system long enough and it will demand your attention when it breaks someday.
Estimating Projects
Once you've got a handle on your priorities, you'll need to determine how big a potential project is and how much time it's going to take you. This is important as you'll want to scope projects according to how much time you have. If you've got a full time job and only have a few hours a week to put towards side projects or content, you want to use that time effectively. Often, "just work more hours" isn't possible or beneficial.
Estimating in the world of software development is notoriously difficult and that tends to hold true for non-development work like writing or video production. What I've found most helpful in this is to measure and time track in order to establish a baseline, then estimate based on that data. I know, for example, that a big tutorial might take me a couple of weeks, while a small blog post might only take me a few hours.
If you have no idea how much time to estimate for a project, it can be helpful to set aside 90 minutes for focused work to build a small proof of concept. See how much you get done on that project in those 90 minutes, or see how quickly you can build a tiny version of it. This will at least let you discover some of the difficulties that might be waiting for you when you tackle the real thing and will give you some estimate of the true scope and length of the project.
Going All In
Of course, there's only so much prediction and estimation you can do. At some point, you're going to have to Just Pick Something and work on it. I've found that for me I need to limit my focus to very few projects and go all in on them until I can get the MVP launched (whether that's a piece of content, an app feature, or even a dev rel program improvement). I typically focus on around 2-3 projects at a time in my day job (not including the tasks that are just "part of the job") and only about 1 or 2 business and personal projects at a time. That might not sound like much, but this baseline comes from hard-earned experience where I tried to take on way too many things and started dropping balls and losing quality.
Prioritizing and picking projects is tough, there's no doubt about it. By using some of these techniques, you should be able to at least save yourself some time and make your best guess. Remember that what you're trying to build is the meta skill of good judgment. That happens gradually as you build experience and measure your results. It's an ongoing process that takes practice, so don't get frustrated with yourself when you choose incorrectly. As long as you practice scoping your projects correctly, the loss of time shouldn't be too bad.
This article began its life as an issue of the Developer Microskills Newsletter. Each week, I send out a practical, actionable way to improve as a developer and developer advocate. Sign up below!