How to take technical decisions for your side projects?
Some people allocate a sizable amount of time to this. My approach is much more simple.
First, categorise this decision. Is it a one-way door decision or a two-way door decision? Most of the time it is the latter. Being that the case, I dedicate 30-45 minutes to research what are my options. What analysis of the options already exist out there, medium, .dev, Reddit… If I think it might be relevant, ask in one of my core chat groups for an opinion. Most of the time it falls on one of two buckets, a) no opinion / educated guesses or b) extremely polarised opinions (pro or against particular options). People might reveal big hurdles or advantages for a particular choice.
By then I should be able to narrow it down to 2-3 options. Then I prioritise based on a series of factors that can be interpreted as gut feelings, but they are not. Does it look great and polished? Indicator of care and commitment behind it. Abundant documentation? lots of posts about it? great examples? good indicators of an existing community, up-to-date docs, easiness to find help when finding any blocker down the road,…
The next step is to pick the most appealing one and build a (VERY) rough version of whatever I need. Sometimes that means writing a basic script to test being able to solve a sample of the problem or a limited aspect of it. Sometimes means quickly integrating it with an existing project in a branch and seeing how it goes. The goal is to get a rough idea of how difficult will be to actually implement it at a production level, a proof of concept. As a rule of thumb, if I am not able to get a positive outcome in a short time, I discard it. The time can go from two hours to a morning, but no more than that.
The moment I hit a visible wall, I park that one and move to the next possible option. If I find a solution that is “good enough”, I just go for it, without exploring the next ones. My goal is to identify as fast as possible a viable solution for a particular problem I am looking to solve, minimising potential friction down the road. My process for not easily reversible decisions looks different (MECE, etc, but the reality is that those are indeed pretty scarce.
Avoid analysis paralysis with an approach that works for you.
To summarise this little piece of advice:
1. Simplify it and identify what type of decision you are taking
2. time-box your process
3. have a clear understanding of what success looks like before starting your analysis
How do you make your choices out there?
