In my younger days, I had a blog I used to write some stories in. They were usually drawn from reality but dressed up for dramatic effect. I thoroughly enjoyed the process of sitting back and letting my fingers do the typing. It's almost like I could switch off one part of my brain and use the other. Sometimes - rarely in fact - I would get writer's block. It wouldn't take me long to get over it, but it definitely happened. Imagine my surprise years later when I realised software engineers could get writer's block too. I'm ~3 years into my professional career as a software engineer and I've only ever had 1 side project that I "completed".
What usually happens is this:
- I start brainstorming a new idea
- Eureka! I'll go with this idea
- Let's break down the work
- Oh...I might need to go learn xyz
- This task is pretty big
- I can't do this project justice
- flips table and opens YouTube to watch fail videos
- Repeat process in a month
Does this sound like something you do? Let's focus on points 6, 4 & 5 respectively.
"I can't do this project justice"
Ah yes, impostor syndrome; my old friend. The symptoms present themselves in different ways as detailed below. Whenever you feel like this about a project, it's often helpful to write down why you feel this way. It could be bullet points or a brain dump - it doesn't have to be organised. Alternatively, switching context to something completely different is a great way of allowing your brain to background process. Kinda like
"Oh...I might need to go learn xyz"
This is common amongst people who strive for perfection (weird flex, but okay). You feel like you need to learn everything in a particular domain before you tackle a project. This was a misconception I had to get over at my first job. Startup world demands that you develop and iterate rapidly - you don't always have the luxury of stopping everything to learn a new technology unless the project demands it. Moreover, getting stuck in this learning loop (aka tutorial hell) means you won't actually ever build anything.
So what's the solution? Strike a balance between learning and building projects. If you needed to set up a CI/CD pipeline, you can purchase a course on it and develop said pipeline while watching the course. If however you were looking to get up to speed with cloud computing (AWS, GCP, Azure, etc), perhaps it would be wise to get to a decent level of proficiency before architecting solutions.
"This project is pretty big"
I think this way too often both in a professional and non-professional setting. Whenever I have a grand idea that's exciting, I get overwhelmed with the scale and simply avoid taking the project on because "it's too big".
If you were standing at the foot of Mount Everest, of course it would be daunting. But the only way to climb the mountain is to take it one step at a time - have checkpoints, milestones, etc. The same is true with projects. You must be able to break down your project into smaller pieces of work. You can also consider an MVP (minimum viable product) - what is the most basic version of what you're attempting to build? If it's a website, put aside the UI styling - focus on having functionality first. If building the backend would be too complex initially, mock the results so that you can work on the project as if you have the APIs good to go.
What if you're blocked at work?
The same rules apply, but perhaps you might not have the luxury of context switching as you would on a side project. But if you're stuck on a ticket/feature, it might be good for you to get an extra pair of eyes to take a look at the problem. Alternatively, you could pick up a completely different piece of work, or write some documentation - I'm sure it's needed 😉
You might also be burnt out. In which case, take 👏🏾 a 👏🏾 break 👏🏾.