I have a bachelor's in pure math and a master's in applied math, and I currently have a pretty good job. But the industry I work in is tumultuous, so I worry that massive layoffs may come without warning.

Long story short, I'm starting to seriously think about getting a second bachelor's degree to make myself more marketable, in particular Computer Science. If there's a degree program that focuses specifically on software development, I might consider that because I love writing code. (My current job involves a lot of VBA, which I love using.) It's worth mentioning that I've also considered, and am still open to, learning everything that a CS major would learn, but on my own, reading the textbooks.

At any rate, to get to the point, would it be a mistake to get a second bachelor's degree online? I have zero intention of leaving my current job to work on a second bachelor's, so getting the degree online would be much more convenient than going to a university campus. But I worry that getting a degree online would make me less marketable instead of more marketable, if a lot of employers frown upon online degrees.

I read some articles online, but I thought it would be better to get information directly from the horse's mouth, as they say, from people at a place like this.

Sorry for not responding more promptly. I do have an answer for you: Forget about the second Bachelor's degree. Instead, focus on training and certification programs for professionals and postgraduates.

Computer Science is what it says on the tin: Science. Programming is not computer science; programming is a technical pursuit. There is a well-known quote, possibly apocryphal, attributed to one of the most notable computer scientists of the last century, that describes the distinction between computer science and software development (of which programming is a major part) in terms of astronomy (the science) and telescope design/manufacture (the technical pursuit).

Your existing education indicates you can probably absorb many or most of the major concepts of computer science through informal study. Graph theory, predicate logic, asymptotic runtime—many of the "big ideas" that undergraduate CS students are introduced to are nothing more than applied mathematics.

Programming, on the other hand, is a creative pursuit. It's something you need to practice. It's something learned best by doing. And thanks to the internet, you have an incredible breadth and depth of resources available to you to explore programming as a pursuit and a career. You have MOOCs, OCW, Stack Exchange, open source projects, GitHub et al., free editors, free IDEs, hell even Microsoft is giving away Visual Studio now.

And if you like VBA, there are a bunch of languages out there you'll like even more. VBA is a gateway drug; I've written my share of macros as well, but once you get away from having to work within the confines of MS Office software, you may never want to go back.

Or maybe you'll figure out that you like scripting more than working on full-fledged software projects. In which case, the inflated expense and bureaucracy associated with a Bachelor's Degree will have been a waste. If you really want a program affiliated with a university, there are tons of certification programs out there for working professionals who want to make a move into programming. A really great program will do more than just teach you some languages; it'll involve significant project work and expose you to concepts like the software development life cycle, version control, unit testing, build automation—not all of these, but at least some. If you just want to learn a language, do it for free with a MOOC; edX has some good basic ones for Python (MIT) and C (Harvard), Coursera has a course in Machine Learning (Stanford) that's been going for years, plus an entire specialization sequence for Data Science, if you're interested in the current Sexy Thing.

My degree is in civil engineering, but at work I spend most of my time working with databases and writing code. I have almost no formal training in computer science or programming; I took one really shitty Java course at a community college. Programming is something that I'm comfortable with, and that goes a long way; it's also something I find satisfying, which is equally important. I was literally hired for those reasons, and because I had been very casually fooling around with computers and programming for a long time, and because I had written some VBA macros as an intern that helped the office do a few things more easily in Word and Excel. I was hired to do something that required skills I did not have, because I convinced the interviewers that I could learn them given a little time and some resources, and—here's the kicker—because they didn't want to pay for someone with a "real" programming background.

But, I also work in the public sector, and after doing that job for about a year I got hired as a permanent engineer, at right around the median entry-level wage for the field on my diploma, doing something I like. And I have a side of my resume that most CS graduates don't, thanks to my civil engineering background.

So forget the BS; you don't need any more letters. At most, get a certification that'll cost you a few grand, and before you commit to that, try some free stuff (but treat it like the real deal; you get out what you put in). You'll do fine. You'll be way more hireable at the end of the day than most 24 year-old computer science MS grads.

I was recently in almost exactly the situation the OP fears: I am an engineer by education and trade with some work experience writing software, and I lost my job.

At the time (a few months ago), I thought that software engineer might be an attractive alternative career path. From your post, I think I have more software development experience there than you, but not massively so.

I have talked to various software firms, mostly in fields with a relation to engineering. They were interested enough to talk with me, but I found the result disappointing. I got less job offers than I expected, for more junior positions than I hoped for. In the end, I found a far better job as engineer than I could get in software development.

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?

The main thing I learned from the interviews: recruiters would have liked to see more evidence that I was serious about software. Doing most of the software work in non-software firms was nice, but they wanted to see more. A formal degree would have worked great in that respect, but it might be overkill. Smaller training programs like Bakemaster described would have had the same signalling effect. Spare time contributions to open source projects would have helped as well, I think.

Another lesson: My jargon was not up to scratch. Even for software design choices that I think were very good, I lacked the vocabulary to describe succintly in an interview why I made those choices. Self study does that to you: you miss out on some common knowledge that people with more formal training take for granted. In-person courses would have helped here, even if a degree might be overkill.

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.

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.

The software people put some value on that flexibility, but they are obviously happiest with people who can start right now. That would override most doubts about lack of formal education, or lack of high quality work experience. If software development is your backup plan, it might be a good idea to approach a software company that you like, and ask them directly: if I want to work with you guys 1 year from now, what would you advice me to learn?

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.

Don't stress this overmuch. Yeah...they're good, but they're also faddish. I use the shit out of Struts because it's in my brain from way back when. But, Struts(any version) isn't really cool any more. Does it work? Yes. Excellently, for about 95% of webapps. But I get more respect for familiarity with D3, which, really, I facerolled my way through in about two days before I had to give a presentation on it, and learned it entirely by cribbing stuff from their site and online tutorials. It, like a bunch of other stuff, is just a javascript library. It's not super spectacular or anything especially strange code-wise, just kind of handy, and happens to fit well into Web 2.0 or whatever the hell that is now. There are a great many other similar javascript dealies.

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.

From there, find what's currently sexy in whatever languages you're targetting. Java in particular has a metric ton of these. Hibernate had a period of popularity, but I think it's fading. Whatever you pick, make sure one of them is for webapps, and one is for webservices. In web services, REST-based services are the current hotness. So, something that falls into that. You will need basic HTML knowledge for webapps, along with basic javascript stuff. These are both very, very easy, and well supported by free online tutorials. Get firefox, install firebug. Complex javascript is hell to debug without tools. Never use IE again except for compatability reasons. A certain disdain for IE is basically required in technical fields.

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.