How to deal with getting stuck on solo projects [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 1 year ago.

Improve this question

There are a few questions similar to this one but I feel the situation is a little different because I do not have the methods available to me or they are not working. I have been working on a solo project for 7 months now and the thing that is really killing my productivity is getting stuck on one little issue like an error I can't figure out or trying to get a library to do something.

My normal steps to deal with this are in order:

• Search the internet for solutions
• Ask a coworker
• Post a question on stack overflow

Because this is a solo project I have no one to ask in this case. Searching the internet and stackoverflow help in a lot of cases but I am regularly hitting issues with less well known libraries or hard problems where you can't pull an answer out off the top of your head and no answers are posted until I figure it out 5 hours later and post one myself. This is a major issue because usually these 5 hours are actually spread out over much longer with all the breaks needed to think about the problem.

What methods could I use to remain productive when hit with an issues I can't work out?

One I have not tried is using multiple branches in git to work on multiple things at once and switching to a new task when I get stuck for too long. This may help keep productive in the short term but I don't know if I am just pushing the issue down the road where I will still be stuck when I come back.

Answer 1

Theres no magic fix. Your only choice is to limit your exposure to these types of problem.

This is obviously a general rule, but I think its especially true with solo projects. Where you really don't have time to fix problems with your tool set, libraries or odd edge cases.

1. Only use mainstream, mature libraries and frameworks

2. Don't use a thrid party product you can do without

3. Use third party software only for its designed usecase. Don't try and make them do something they are not designed to do.

4. Be ready to replace out things that dont work.

Answer 2

Your "normal steps to deal with this" are still valid, even as a solo developer, assuming that you have some coworkers, even if they're not developers. Often, the act of defining the problem well enough to explain it to another person is at least as helpful as anything that the other person might say. So, go ahead and explain the problem to a non-developer colleague anyway and you'll likely obtain most of the benefits you would've otherwise obtained by talking to another developer. I'm the only developer on a team of scientists and I find that explaining my code to others helps to clarify issues with the code in a way that simply thinking about it by myself does not.

Answer 3

It's not just solo developers that get stuck. Often an experienced developer that works on a team can only get a minimal amount of help on a problem, because he or she is working on the team's most difficult problems, and is the only person with the requisite amount of knowledge about the code.

My process when I get stuck with no one to turn to is to write down the question I'm trying to answer. Then below that and indented, I write down the questions I need to answer in order to be able to answer my main question. Then at another level of indentation, write the questions I need to answer in order to answer my secondary questions.

Sometimes I will go four or five levels deep, but eventually I get down to a question that is easy enough to google or research in the code. Finding the answer might spawn more questions, or it might let me start moving up the question stack. Sometimes I reach a question that I can only answer with more general background knowledge, so I end up just spending some time learning that.

What I like about this system is it provides a way to do something to make forward progress, even if it seems far removed from the primary goal at hand.

Answer 4

I'm in two minds about this.

Initially, I wanted to comment that when you are the solo dev, and the current work blockage is not that you're waiting on information from other parties, that there's no reason no to handle the work immediately.
The main reason for this argument is that hopping between tasks tends to cost you extra time, because interruptions cost more time than the interruption itself took. For that reason, you want to minimize the amount of "hops" you take between jobs, so you don't have to spend time getting in the zone for each distinct task.

But I've also been a solo dev (sole employee of a company), and I know that you need to distance yourself from a problem and come back to it with a clearer head. Or, as you mention in your case, waiting for an answer from StackOverflow; which, in my previous paragraph's defense, counts as "waiting on information from other parties".

---

Summing it all up

I suggest that you minimize the amount of times you switch between tasks, because you'll be more efficient when you focus on one task at a time, as opposed to trying multitask.
Ideally, you never hop between tasks, which is the most efficient approach.

However, there are some valid reasons to put a task on hold. The three main reasons I can think of now is that you are waiting for feedback from others, need a break from the problem, or are waiting for a long-running process (e.g. build pipeline).
When you encounter such a reason, branches are a good way to keep work separated.

I tend to stick to a priority ranking:

1. An unforeseen emergency task which cannot wait
2. The current task you're working on
3. Any task you've already started but have put on hold
4. Any task you haven't already started

The main thing to take away here is to not pick up any new tasks (4) before you've re-evaluated whether you can finish tasks that are on hold (3).

Never leave a task that is on hold lying down in favor of starting on a new task, because the old task will be forgotten or ignored, and you will start forgetting contextual details, which will cause you to take longer to get it done when you finally do pick it up.

Answer 5

I'm not sure what exactly you're working on or with, but something that often helps me when I'm dealing with a new library or method of doing something is to make an empty app and deal with just that issue. This way you completely remove everything else you're working with, both in code and from your mind, and be able to concentrate solely on the issue you're trying to solve. If things work out, you'll end up with good code that you can import into your project.