Ask HN: What do you do when you get stuck while working alone?

Pretty much Stack Overflow and good unit tests. Normally I don't write games, so the unit testing may not necessarily apply as much to you as it does to general software development.

Firstly, don't be so hard on yourself. Cheers to you for building something.

Secondly, be sure to test functionality fully and often. Like, when you start a method, after any big functionality in the method and at the end of the method? Or whatever works for you. In this example, when you overloaded the init method you'd probably have seen the error pop up? Just a thought, it is a bit of a pain though.

However, in general the best bug breaking strategy is simple... Take a break! Grab a coffee, walk your dog, get some groceries... Just get your mind off the problem and come back to it with a fresh pair of eyes... It's the next best thing to a new person. Just make SURE you aren't thinking about the problem while you're taking your break! It's gotta be a real break.

You might also consider looking into co-working spaces in your area?

Good luck! Have fun.

Oh yes, I know this feeling very well. First, I try to google sites with people who had a similar problem. If I wasn't lucky I check Stackoverflow more extensively, then the api documentation. When I still stuck, I try to find other examples try to run them and try to read and understand their code and finally I am reading the sources of the respective api. If it still doesn't help direct questions on IRC or Stackoverflow.

Stack Overflow, google search. I also go through the mailing lists which often will not show up in google results.

I develop apps using Android, so I have two workspaces, one for the product and another one to test the individual functionality so that I don't screw up the existing code.

Cheers

This is completely normal for development work, so its like asking, "what do you do when everything is normal." In your case you have a tricky bug, so tests are the best bet. When you are making the test, the cause of the bug will probably become apparent before you finish writing the code.

I talk to other people and tell them about my problem. It doesn't matter if they're a domain expert. The act of explaining the problem frequently causes me to see it from another angle and sometimes that's all it takes to get things going. It's the "stuffed animal helpdesk" effect.

I've been on both sides of this. Sometimes people talk to me just to get another take on things and they wind up finding it just by explaining it. Once in a while, I end up making a guess based on general knowledge and wind up being helpful anyway.

I got this idea from reading Usenet way back, and wrote about it more recently: http://rachelbythebay.com/w/2012/06/14/crash/

If none of the solutions work, then try taking a shower. Somehow magically this solves the problem for me most of the time.

As already answered here I start by a few google searches, changing words multiple times as it is not always easy to sum up an issue in a google search. Then I look in my contact list on gtalk/skype trying to find someone who could have a fresh view of my code/problem. Most of the time, explaining my bug and my code to them leads me to a "oh snap that's it moment" or they provide some general ideas.

But I also still use IRC a lot. Depending on the framework/language there's always one or two IRC channels where you'll find people who can help you or at least point you in the right direction so you should search for some good IRC channels specific to obj-C development and hang there while you code.

Working alone sucks. The learning barrier varies every day. Some days, you feel you are a superman coder doing simple stuff. Other days, you feel like a drained out rat stuck on a syntax error. So, I understand how you may have felt when you found out the root cause.

Perhaps, this is a cliche. What works for me is the 'rubber duck' (http://c2.com/cgi/wiki?RubberDucking). It helps me not only while coding but also solving life problems. No really. I am not ashamed to say, I talk to an inanimate object to work through few problems. I learnt that the very few simple things you think you know turn out to be difficult to explain. Who better than the soft toy to listen and not judge you?

Yep, search online, join chat rooms, work on something else, or take a nap and return to the problem later.

If the bug ends up being that annoying that it takes that long, then I take a break to ensure my mind is clear and fresh, then I literally walk through everything step-by-step until I find the problem. If I don't see the issue with what I wrote, then I suspect a bug in the deeper layers or a lack of understanding of the deeper layers on my part, so I begin to isolate everything and do the equivalent of unit test each part to ensure it works as expected. Even if it's the most obvious thing I check it anyway.

Needless to say I sketch things out a bit beforehand (sometimes by writing throw away code), then I write the code little pieces at a time, then I immediately test each section of code I've written while it's fresh in my mind. This helps ensure that what I'm writing doesn't run away from me.

Sometimes I write large amounts of code just to get better at debugging when the amount of code written is large, and to beat myself into make less mistakes, and to improve my ability to hold more in memory without getting confused or losing track of what I'm doing. Sometimes just to prove to myself that I can do it. I just do it again and again until I beat myself into submission. After every mistake or failure to do things the way I expect I say, "No, it's possible. No, it's possible," then I start again.

Working at a 9-5 for sometime, especially at a large shitty company, is often enough to have the ability to do this beaten out of you by less capable or stuck-in-their-ways Engineers who insist on saying you have to do things this way or that way or you'll have problems. Eventually you may get sick of their stupidity and begin to act out to find ways to keep yourself sharp, to prevent being watered down, and to keep things moving.

Just remember it's possible to get better at cranking out line after line of code without making very many mistakes, and it's possible to adjust the way you write code in such a way that if errors are introduced they'll be blatant and easy to identify.