

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

I'm in the process of learning Obj-C and the cocos2d framework in my free time after work.  I'm building a game incrementally.<p>I spent about 3 hours troubleshooting why one of my layers was not displaying sprites while another layer would even though they were seemingly identical.  Turns out that by overwriting the init function to enable touch for the layer I overwrote something that dictates sprite behavior (seems obvious in hindsight).<p>This led me to ask, how do you guys manage bugs and problems when you're on your own and inexperienced?
======
tylermauthe
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.

------
joelmaat
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.

------
rachelbythebay
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/>

------
codeonfire
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.

------
tferris
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.

------
justlearning
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?

------
koopajah
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.

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

~~~
xauronx
Agreed. If I get stuck on something and nothing I try makes it work properly
I'll go shower or take a bath. 90% of the time just relaxing and getting away
from it will be enough to make something click.

------
andrewmunsell
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.

------
jkd
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

