some notes on pet projects

turns out, porting doom takes a bit, so i've decided to make smaller, more useful-to-me posts in the meantime as a way of getting myself in the habit of blogging.

today: a quick overview on some ways i've made project management work for my personal projects!

>>> the problem

tl;dr: tracking projects is hard, steal ideas from your workplace to do it better

if you work in engineering, generally speaking your place of work will have some kind of project management system in place. usually this involves

  • software tools
  • lots of timelines
  • various forms of techinical documentation
  • constant group communication
  • plenty of peer pressure to complete things on time

and other (potentially threatening) elements to taste, ideally with the outcome of completed projects mostly on schedule.

as someone who's been both a project manager and an individual contributor, i can say that when tuned right, these systems work wonders for my ability to get things done.

but what about when i'm at home?

as someone with [redacted set of neurodivergences], i can comfortably say that if a project takes more than an hour, and i don't have a way of tracking it, it's not going to get done.

hence, i've needed to find some way of taking systems that help me during the workday and (in a healthy, sustainable way) converting them into things that work for me on my own time. here's what i've found!

>>> prioritization

tl;dr: ferociously guard a slim active set of projects, and keep a backlog for ideas

the first thing difficult for me about pet projects is prioritization. i presently have 8 9 projects at various stages all vying for my attention, and the version of me waking up tomorrow is often motivated by an entirely different set of projects than the version of me right now.

what i've discovered: this is actually great!

companies have deadlines, but as a person working on pet projects, i (generally) don't. if

  • there's a consistent routine in place for working on pet projects, and
  • each project in that rotation gets attention regularly.

those projects will by necessity eventually be completed.

i've found it important though to (a) determine a set of projects that consistently catches my interest, and (b) put in regular time on that rotation of projects, making sure each one's receiving attention hit.

this requires a bit of self-honesty, but keeping a reasonably-sized project rotation as well as a backlog seems to work well. if i have a new idea, it goes on the backlog. if one of my projects isn't getting the attention it needs, it moves to the backlog.

the set of "active" projects should:

  1. contain at least one project that i'll be interested in every time i sit down to work on pet projects
  2. have few enough projects to be able to reasonably rotate among them.

this way, the projects in the active set see continued, sustainable progress for their lifetime.

>>> scoping pet projects

tl;dr: be intentional about project scope, but let it change

most of the time, when i dive in on a pet project, the first picture in my mind is the completed project exactly as i would ideally envision it.

this is generally not realistic, and often leads to disappointment.

fortunately, unlike a company, i don't have any stakeholders except myself. if i care about a project just to learn, it makes sense to be intentional and denote the project as "exploratory": i.e. however far i get, i'll be satisfied. if i care about a project strictly for the end goal, it can help to scope out a "minimum viable product" i'd like, and aim for that instead of some grand abstract vision.

the best part is that because i'm only beholden to myself, these scopes can change drastically.

around 2009, the cult of done manifesto started circling the internet, with the core idea of getting things done quickly and discarding them for the next task. it (naturally) found a cult following, because most people have an innate desire to be seen as consistent over time. there are a lot of things like the cult of done online. it's arguably one of the more commonly expressed views on personal projects you'll see.

when i work on something that takes more than a day, i find those views aren't helpful.

in 2017, i started a cs degree studying machine learning. i completely abandoned it. why? because it became mind-numbingly boring.

i switched majors to math, then got into cybersecurity, then ran and sold a startup. and i'm happy, and have a lot of great experiences to draw from, because i explicitly chose not to finish something.

all this to say: do what works for you. be disciplined about it, pick good times to pivot, and make sure you learn lessons as you go, but in everything you stop enjoying, keep your knife to the rope so you can cut and run.

>>> status/time tracking

tl;dr: keep just enough tracking to see progress

as someone who has seen tried numerous techniques for project management with small teams, i can say this with certainty: if you make tracking high maintenance, things will go untracked.

i use a kanban board so i can see the progress happening on longer pet projects. going further than that for personal projects is excessive and chews up time i could be building something.

time management can be good to get a sense of what projects are actually receiving focus--this is useful when updating the active set of projects. it can also feel nice to look back and think about the amount of time i've poured into projects if the material progress isn't there yet.

one project i'm working on right now is adding time tracking capabilities to my watchy so i can take care of this with the press of a button. hopefully will have more to share here soon on that. ^^

>>> peer pressure

tl;dr: make the project matter to others and you'l work on it more

this one's easy, and something a lot of people discussing personal projects online get right. i'll often make a point of telling my friends/coworkers about my projects. sometimes i'll ask them in depth about theirs, and often their enthusiasm will spark some of my own.

on occasion, i've found working with academic researchers can make sense when my projects are academically relevant. few people are more actively enthusiastic about their fields than those in academia (well, at least in math and PLT).

it can also be worthwhile to fit exploratory projects into existing open source work, or tie them into topics others personally care about to find fresh motivation.

by sharing with others, i've often learned a lot more from projects (and had a lot more fun).

>>> next steps?

tl;dr: more to come

this is just a short overview of some thoughts i've been accumulating on pet projects. i'll definitely include more as i continue refining what works for me.

til then!

-- kat

git commit -m "initial commit"

hiya!

i'm kat, and this is my new blog!

i work in cybersecurity and co-founded the startup radical semiconductor, which focused on designing next-generation processing-in-memory cryptography accelerators. radical was just acquired (!) which means i finally have time to write a blog.

if you're curious about the stuff i enjoy, here's some other things i've done:

heads up that in the above and news articles about me, my deadname (what's that?) shows up once in a while. i don't particularly care if you see it, but just know i'm the same person.

uh, yeah! working on a fun doom port right now, so hopefully that should be ready for the next blog post :)

-- kat