4

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.

Improve this question
2
  • 5
    Probably not worth posting as an answer, but another 'step' could be getting yourself into programmer communities / chat rooms / forums, where you can ask a "hey, I'm stuck on X, any ideas?" type question in a more free-form discussion environment than SO's stricter ask-a-complete-question-get-a-complete-answer format. A bit closer to brainstorming with colleagues. – Kai Mar 14 '19 at 14:37
  • Work on other things first. When you come back to the problem it may no longer be relevant or the solution may be obvious because you were stuck in a rut with your thinking earlier. Or you may see another way of achieving the same thing. Or you will have accidentally stumbled upon the solution while working on other things. – Martin Maat Jun 11 '19 at 11:04
8

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.

Improve this answer
5
  • The question isn't so much about the libraries that OP uses. OP's question also applies to cases where there are no external libraries or frameworks (related to the issue at hand). – Flater Mar 14 '19 at 13:56
  • 2
    @flater thats not how i read it – Ewan Mar 14 '19 at 14:05
  • "I am regularly hitting issues with less well known libraries or hard problems ..." It's also not just a matter of how you read it, but what OP is actively asking: how to remain productive when a roadblock presents itself ("What methods could I use to remain productive when hit with an issues I can't work out?"); rather than how to best avoid roadblocks (because no approach is perfect and roadblocks are always a possibility, even if minimized). – Flater Mar 14 '19 at 14:07
  • 3
    there no point in arguing about question interpretation. the OP can decide which answer is best – Ewan Mar 14 '19 at 14:11
  • This feels like the closest solution to my problem. Using new and cool stuff is fun but boring but working stuff is even better. – Qwertie Mar 14 '19 at 23:02
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.

Improve this answer
2

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.

Improve this answer
2
  • That sounds like a great strategy for dealing with the hard problems. Probably not so great for when the problem is just one line is wrong and the error message is not helping. – Qwertie Mar 15 '19 at 3:14
  • What does this term in the error message mean? How does this part I copied and pasted actually work? Who has had this same error message? What did they think was the problem? What was the actual problem? Are there examples of people using this function successfully? What's different about their solution compared to mine? Can I find the code that actually throws this error message? ... – Karl Bielefeldt Mar 15 '19 at 13:46
1

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.

Improve this answer
0

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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.