I'm not sure if you were serious about this question or not, but it actually points to what seems to be the real point of this topic. Learning good programming practices. Early versions of BASIC had an arbitrary GOTO statement that could go to any line of code, not just those that were labelled. That may have been what was meant, but when I think of an "arbitrary" goto, I tend to think of something else. To me, the problem wasn't the language, but the way it was used. I would, therefore, say that an arbitrary GOTO statement is one that doesn't follow a well known and easy to follow pattern. One that leads to what's called spaghetti code. I learned BASIC on my own and learned very quickly to organize my IF, GOTO, and GOSUB statements so that they were easy for me to follow. I was never told to do this, but I learned by example from seeing programs that had been well written. When I got into high school and took a computer programming class (which was a joke for me), I would finish my projects so quickly that I ended up helping other students. That's when I saw the importance of what I had already learned by example. In fact, I ended up polishing my programming style from the examples presented to me in that class (the only thing I did learn from that class). Some of the other students tried to imitate those examples as well and generally had well written and relatively easy to debug code. It would look something like this:

10 x = 1
20 if x <= 10 then goto 60
30 print x
40 x = x + 1
50 goto 20
60 end

This is the BASIC encoding of a while loop (a bad one, since an FOR loop would be easier, but I didn't care to do something more practical for a while loop, such as reading a set of values until no more values remain). I forget what version of BASIC it was now (I learned so many =p). What the other students wrote (those who didn't catch on to the examples)... well, its hard to show with this simple of an example, but when you had more complex statements with any level of nesting, they would fail to structure their code in a way that made it easy to tell what was going on and they would have goto statements that crossed one another (loops would overlap instead of being nested, for example). I could still pick out the path of logic that their program would actually follow, but they couldn't. And my first step in fixing it would have been to organize it into meaningful structures in any case. Of course, when I was helping other students, I couldn't do that for them, and so I spent most

It seems to me that most of this discussion didn't address the original question, roughly paraphrased as "do you need to be unemployed to be a really good programmer?" The reasons cited being to get away from the various problems that come with having a job and working with other people. Of course, it might help if we had an idea of what was meant by "a really good programmer." That being said, to my mind, you can't be a really good programmer if it isn't a vocation for you, your primary occupation, the way you answer the question of what you do, and what you are passionate about. As to whether or not that is a job and/or your primary source of income is another story. As for a job, I think its common sense that whether it contributes or detracts to that varies from job to job with too many specifics to give a general answer. For a positive example, at the job where I am currently working it is just me and one other developer and I was forced to learn many new things and develop new techniques and a new understanding of programming that, despite having programmed professionally before, I had never previously developed. Now that I don't know that I'm a "really good programmer," but certainly having a job has moved me in that direction, whereas all the free time in the world before that (I was unemployed for several years before that, and programming applications with the intent to sell) did not. As for a negative real life example, I don't yet have one, but it seems to me that it is possible to get pigeon holed and never develop any new skills. This, of course, is eventually a death sentence in the IT field, which I've seen happen to administrators, but haven't yet had the experience of seeing it happen to a programmer.