Originally posted at michaelzanggl.com. Subscribe to my newsletter to never miss out on new content.
We all have obligations. And especially once you have kids around, it can become quite tricky to make time for doing some side projects.
But I wouldn't say it's impossible. In fact, there are quite a few things you can do to get projects done.
Note that the things I point out are even better when you DO have the time. Imagine how much time you save for other things.
Apply YANGI not only to code but to the product too
You might already apply the principle of YAGNI (you ain't gonna need it) to the code that you write, writing only what is essential and needed right now, and not things you might need in the future. We can take that same principle and apply it to the product we are building.
Say you are running dev.to. When people create blog posts they can add predefined tags to them. Now, say the predefined tags are not enough and dev.to wants its users to somehow be able to add completely new tags but only upon review.
There are two ways you could do this
The hard way:
- Let user add any tag and show warning that nonexisting tags will first be reviewed
- We now have to save the tag in the DB with a special "for review"-flag
- We also need a new UI on some form of CMS to go through these and review them
- We need to send an automated mail when a tag has been accepted/rejected
Or the simple way: When entering a tag, the tag suggestions already show a message that tags have rules and guidelines to follow. Simply extend this message to say: "To suggest new tags send us an email at yo@dev.to".
The problem with the first approach is that it has a bunch of dependencies like database, changes to the backend, even an admin panel. The second approach reuses something that already exists in the app, and only requires minimal changes on the UI. We might get to the first approach eventually, but we will know better what to build once we release a simple version of the core idea.
This leads us to the next point...
Work in small iterations
Like in the example above, think what is the simplest thing you can build. You don't want to spend 1 week on a feature that turns into 3 weeks because you suddenly run into all kinds of inconsistencies with dependencies. That can be quite exhausting. Think small, and you might not even need that perfect solution in the end.
Once the core idea is out, you will have a better understanding of how your users actually use this feature and you can better judge how to go from here.
Another example would be working on a new website. Start with a feature, the core thing. No reason for a header, footer, special font or sidebar right away.
Most have 2 hours a week
Try to block out two hours a week. Maybe one hour on Sunday morning and one hour on Wednesday night.
This tip goes to Jeffrey Way in his podcast episode Focus on two hours, not two years
Define your goal for each session
Say you split your time up into two 1 hour sessions a week. When you start a session set a goal and focus! That means no social media, no videos, no news, no twitter, no kids, no games. Block out all distractions!
Don't get stuck on the little things
This goes hand in hand with the previous point. Focus on your goal. This is not the time to refactor some random file you stumbled upon, or to play with lint rules, or to fix a type issue in an open-source library you are using. If you do believe these are important, take a note and turn it into a separate session! You can host your project privately on GitLab/GitHub and use the issue tracker to keep track of everything that needs to be done.
Know when to break out of a problem chain
This tweet tells it so nicely
What tools to choose
You don't need a fully dockerized scalable microservice architecture with GraphQL API and micro frontends with redux and TDD, BDD and DDD.
If you are productive with these tools, by no means go for it. Also, if that's exactly what you want to learn with this side project, again, go for it!
But if your goal is to build a product and the tech is just a way to help you get there, then you might want to choose a more high-level framework.
Coding, in the end, is kind of like building Lego's. Using a framework, you simply put together 64x64 instead of 4x4 pieces. They let you focus on actually building the product you set out to make and it doesn't keep you distracted on things like architecture, authentication, DB access etc.
On the backend there are some very nice "all-purpose" battery included frameworks like Rails (ruby), Laravel (PHP) or AdonisJs (javascript). I recommend reading the paragraph the menu is omakase from the rails doctrine.
To summarize it
- Work in small iterations
- Focus on 2 hours, not 2 years
- Define a goal for each session
- Don't get stuck on the little things
- Know when to break out of a problem chain
- Choose tools that help you get there faster
Top comments (0)