I'm a code monkey first and foremost, so here goes....
Zamfir wrote:So, no regrets for me, but it did make me wonder: suppose I had strongly wanted to switch to software development, what could I have done to improve my entry position there?
Yup, having something you can point at is huge. Ideally, something that demos well, or that they are conceptually familiar with, or at least something respected as very hard(actual hardness rarely corresponds to actual difficulty). Better, a couple of different things. That will indicate variety/versatility more strongly than a single, harder thing. Have a mental list of a few things you've worked on handy. If you haven't worked on a few things...invent a few. Quick and dirty apps can be done very quickly solo when you literally have no requirements forced on you by anyone else. Just beware of adding complexity for no good reason.
Third: experience working with better developers than me. I am used to being one of the best programmers in a company, because software is not a core skill of the companies. Presumably, I have bad practices that I am not aware of because they're not pointed out. And a lack of experience in working in smooth, efficient development teams. I don't think a formal degree would help much in this respect.
Smooth, efficient development teams are *mostly* a myth. Read some Agile books, scan some buzzwords, but remember, the primary function determining how well a team works together is size. The smaller, the better. Some amazing stuff has been made by teams of 1 to a handful of people.
Learning standards is good...but working with teams is not necessarily a healthy way to learn standards, even. If I had a dollar for every team I've run into that has obscure standards specific to themselves, I think I'd have a dollar for every team I've ever worked with.
Fourth: languages and frameworks. I have always done my programming work on a basis of ' I am smart, I'll learn the specific tools when I need them'. Which works well for engineering positions with a programming aspect to them. Such jobs typically involve obscure frameworks that no applicant knows well, especially if the applicants also need be trained engineers. For those positions, a wide experience with various frameworks shows flexibility.
Figure out how to maximize cool buzzwords in this area without burning lots of brainpower on stuff that'll fall out of fashion anyway. Just shotgun your way through a bunch of interesting, quick to learn tech. A lot of it is actually super easy, and step by step guides exist that'll get you basic proficiency. Don't stress memorization. In any actual job, you will use google for obscure crap.
I'm a mediocre coder. I've met a bunch better than me. But...I've *never* been turned down in an interview for a coding position, and am probably way overpaid. Why? Because interviews are a wierd little game unto themselves. Odds are good that plenty of entirely competent people got interviewed for them, and just didn't make it through the interview.
One thing I do is that I simply don't list half the crap I've messed about with on my resume. Let it come up in conversation during the interview. If your resume is solid enough to get the interview, and they discover apparently hidden, unimportant competence in conversation, it works well. This also allows you to be honest and downplay stuff you've used, but don't know that well.
So, what should you know? It's going to vary a *bit* depending on position, but there's a formula for the basics. First off, it isn't all code. A *lot* of what you do won't actually be programming.
Everyone's Agile crazy now. It's...not a complicated thing. Skim an outline of it online. Be aware that odds are good any actual implementation will be by someone who has never formally studied it anyway, and will look relatively little like the idealized versions written about. Stand ups sound good, but standing doesn't make talkative people shut the hell up. This will probably rotate out eventually when the new thing arrives, and Agile will end up in the dustbin with Seven Sigma and whatever sillyness came before. This can be as simple as "I've read up on this and am eager to try it out". It ain't code, it's project management BS,
Some sort of code management. I'm a fan of SVN, because it's newer than CVS, and thus, cooler. Other systems exist too. Realistically, they all work 90% the same, they all have integrated webapps that allow button pushing for project management, and as long as you understand the basics, you'll be fine.
Coding Languages. Java is pretty huge. Sector will determine primary language. Some like C. Some will be chasing flavor of the month crap like "Ruby on Rails" or whatever. Rails just means "it does webapp shit". I think Ruby's fading, but...there's an endless cascade of this. People will talk cloud, or distributed computing, or whatever. However, the concepts behind most of them are almost identical. You make webpages displayed by an application. You have a webservice API. You should learn how certs work within a basic HTTPS context. Learn a basic one good, and you can skim the hell out of the rest and just transfer knowledge.
I suggest you(the OP now, really) start with something like visual basic, churn through some starter guides with that(classics are some progression like "hello world", a number guessing game, a basic calculator). Then, do the exact same sequence in another language. I'm fond of C# and Java, but there is some personal preference here. Your first language is your toughest one. Your second is significantly easier. It rapidly gets increasingly easy from there. There ARE significant differences at higher level coding, but coding is very subject to a 95/5 rule. Most stuff is easy. You'll use the exotic contents of data structures classes or what not pretty much never. Those will be already implemented in any language you use, and you will, if confused, simply google them. More importantly, they're MOSTLY the same. Yes, syntax will vary, and there are edge cases, but the concepts are very consistent. A basic grounding in several languages is more useful than fiddling around with theoretical stuff(which will be a LOT of getting a degree).
Next, frameworks. I suggest you start with XNA, for C#. This is not because you will use it in a job. You probably won't, unless you're into obscure indie game dev. I suggest it because it's made by microsoft, for a reasonably popular language, and it'll look good as padding you'll never be asked to use. Additionally, it is also very easy to use, and very, very simple guides exist for it, which are often graphical in nature. It's training wheels for learning to use a framework. Also, it, like all training things I'm suggesting here, is free.
Learn to use CamelCase. Learn to use web containers(Ie, download tomcat, learn how to build a war, drop it into the folder and watch it work), learn to use build tools(*sigh*, Maven is currently the cool thing for this in java) appropriate to your language. Learn to use the appropriate IDEs. Most of these are also free. All of this glob is pretty much just good practices/application use, not actual coding, so it's really easy, but it's expected. Don't put all your effort into checking the hard boxes and neglect the easy ones.
Most of all, interviewers are looking for someone who'll mesh with the team and start producing something without needing a great deal of handholding. If you seem to understand the environment, you're halfway there before you even talk code.
Now, back to your original question: If you have the time and money to get a degree in addition to all of the above, it's probably nice. An online degree is better than no degree. However, I've literally never known a coder who wasn't largely self taught. Almost all of them were coding long before receiving any formal education. Many of them also went to college, but tech changes rapidly, is extremely varied, and college tends to pad with a lot of theory you rarely use. It's not a BAD thing to know, but it's...almost orthagonal to gaining the skills to get hired. And gaining actual coding skill in a self taught environment is way faster, especially if you're already dabbling in it. Then, you've already gotten over the toughest part.
Jeeze, I've been rambling. But the short answer is that a degree really isn't essential at all.