The balance you choose to strike between shut-in rockstar open source programmer and irregular contributing social butterfly is a personal one, and I can't advise one way or the other.
If you do choose to develop code in your spare time, prioritising is the tough part.
For me the process begins with having an overactive imagination that chugs away generating ideas for new software or enhancements to existing ideas.
Once you've ideated enough, you have to prioritise. I've heard this likened to refining your palate. Prioritising 'well' is whatever leads to self-actualisation (the psychological notion of realising your potential).
What and why?
- Who are you trying to impress (if anyone)? Are you hoping to post it online (beyond GitHub), or to share it at a user group/meetup, or to send it to someone directly?
- Are you looking for an excuse to learn a new language or tool? Are you trying to reposition yourself at your job? Are you trying to quit your job? Improve your existing skills? Maybe in response to anxiety when you do certain tasks?
- Are you just trying to build something cool?
- Are you going to write high quality or ship fast even if low quality? Are you making decisions like that consciously?
Who?
Consider your audience, i.e. who are you doing this for?
- Are you doing this to get better at work?
- Are you doing this to have more of an identity outside of your work?
- Are you doing this to contribute to open source?
- Are you doing this to connect with other programmers?
- Maybe you're kind of a big deal on LinkedIn? or HN? or the bird site?
- Maybe you'll end up discussing it at local tech meetups?
- Maybe you're making developer tools?
- Maybe you're testing software for developers who've asked for feedback?
When?
You're not prioritising abstract concepts in computer science, you're prioritising your time.
- What is the most important thing to get done? What can wait?
- What are you actually able to do a little of and what needs a significant effort?
- What will never get a look in without being reprioritised?
How
Dump your portfolio out onto a whiteboard, starting with the projects you've worked on recently.
Software is more often than not a living beast, growing and evolving, not so much a finished product.
Juggling multiple projects is therefore a big support task, and while you shouldn't spread yourself too thinly, jugglers is definitely a skill that can be mastered.
Next to each item in your list, write the defining feature(s) about them that might differentiate them (e.g. if you care about the technology stack enough to prioritise based on that, note that).
Rate the items in your list according to whichever of the goals outlined earlier you identified with:
- How energised you are at the thought of them.
- How easy are they? (Are there any glaring opportunities here to make any of them easier to work on?)
- How much potential do they have? It's OK for ideas to not work out, or conversely to be early stage but high potential.
- How technically impressive they are.
- How helpful they could be to other projects.
- How much they are expanding your skills (or could). Note any potential tools you're curious about alongside them.
Be ruthless, are they "strong", "mid", "meh", or "weak"? Try whatever works for you. Maybe they're all solid ideas: if you can't pick a least favourite, pick a favourite, and so on.
Maybe in your head consider multiple dimensions, but just give a simple rating.
Hopefully this exercise will identify a few strong ones and some that can be deprioritised. Conversely, if you disagree with the ratings, and really care about some of the projects you don't rate highly, you can brainstorm ways to boost their rating.
This post is part of Supporting and structuring personal development and open source contributions with GitHub Projects, a series covering how I began using the GitHub Projects tool for tracking my personal development and shipping outside of work. Read on for part 2, discussing how to create a GitHub Project to support your personal development goals