Hey all,

Figured I might as well post here and see if anyone has any experience or advice. I'm currently in the IT field (windows sysadmin) but trying to jump into programming. I took some CS courses in college (originally going for CS degree, but made a dumb decision and went for a different degree) and did 1 software dev internship (java doc/qa). It's been a couple of years since graduating. Right now I'm just trying to teach myself more about programming using the MIT OCW. I'm aware of the advice to contribute to an open-source project, but this'll have to wait until I shake off the dust from my programming skills and catch up to where I would be if I got a CS degree.

TL;DR: lots of sysadmin experience, some dev education. wanna be a dev

There's lots of work doing this kind of thing if you have experience, it's pretty rough these days without it. I'd suggest finding a headhunter shop that isn't run by scum and seeing if they can shop you around.

If you want to stay on the Java course, maybe webapps or some such, I'd suggest: Spring, jQuery, Wicket, Hibernate. This area is always moving, Guice is gaining some steam these days, for example, and NoSQL is becoming popular.

Ironically, your sysadmin experience may help as you get experience, a lot of devs are terribly ignorant of how networking and the like works (average devs, the superstars could probably explain Arp tables for 3 hours).

I'm a .Net Dev myself dude, one word that'll seriously help get you to/through the interview stages is Portfolio. If you can put together a few minor projects and show you've got the mindset for both the programming and system design on top of the CS degree you should be looking pretty good to get a start. If you can, try writing a few apps to help with the job you're doing at the moment. Should show some inititive and that you've had an interest in the field for a while :)

Are you looking to go into any branch (web, desktop apps, OSs etc.) specifically? either way getting some experience with some of the common languages and some SQL really can't hurt. I came out of uni as a C# Programmer and coded in many languages since, and from what I've experienced most employers generally don't care what langauge you code in at the moment, only that you understand the fundamentals and coding paradigms which pretty much means you can pick up a new language easily.

There's plenty of positives with coming from a sysadmin background, so don't be afraid to call on that knowledge. It puts you in good stead to have seen and used alot of programs that could do with improving. Keeping these in mind will help you not to make the same mistakes.

Best of luck dude :)

Thanks for the responses so far, they were pretty helpful.

To clarify, I don't have a CS degree... I started working towards one but went off in another direction. I don't have any plan to stick with one language, but I'll probably try pursuing (in order of preference): webapps, desktop apps, mobile apps, system apps.

Could you guys elaborate on how the sysadmin experience could tie in and help me with finding dev opportunities? My problem is mainly how to get across the no-dev-experience barrier, not really the knowledge barrier.

Yeah, the fact that you know basic networking is already better than a lot of devs. These days AJAX callbacks and a bunch of other networking stuff is going on all the time under the hood, but it's abstracted away by the platform/language, so often people make pretty basic mistakes.

Just knowing how things hook together is a big advantage that your average dev doesn't have (again, there are exceptions).

As far as learning, I'd just say write lots and lots of code. And practice your problem solving skills. The difference between successful software engineers and those who wash out really comes down to the ability to solve difficult problems, in a general sense. All the programming books in the world will do no good without problem solving skills.

The other thing you'll need is the ability to think on your feet. The first barrier of entry will be the job interview. Interviews for decent developer positions nowadays are often 3-4 hours long and involve standing at a whiteboard answering coding questions. These are often quick simple problems, but ones that involve on-your-feet (literally) problem solving.

Those same thinking-on-your-feet skills will be needed in meetings once you actually get a job. The first time you are in a two hour meeting that involves intense technical discussion, it can be a bit of a mindfuck, and leave you a little bit numb. But you have to adjust over time and become a contributor.

Also, get a book that's purely focused on software design rather than just the syntax of a language. "Head first design patterns" is a good one. You could also go with some of the classics like the Gang of Four design patterns book or something on process, like Mythical Man Month or something from that realm. Having an awareness of what project management is doesn't hurt either. What you want is a general knowledge of the whole software life cycle, from requirements gathering, design, coding, and testing.

Having some knowledge of different approaches to the process doesn't hurt either. Specific examples are Waterfall, Agile, and Extreme Programming.

Short version: Learning to program is 40% of what you need. The other 60% is problem solving, thinking on your feet, and the process of software engineering.

I went from graduating straight into software development, and I found that just doing the job was enough to skill up. So you just need to get your first job. There are a couple of things you could do here. Firstly you could target software consultancy firms that cross both the engineering and development areas of the market. It's easier to switch departments from the inside. Otherwise you can look for software companies that are quite small, they tend to recruit more generally than the larger firms that will just blanket require a good level CS degree.

I don't know how the U.S system works, but in the UK it is quite easy to cover up a non--industry specific degree by doing a conversion course to turn it into a masters. I knew two people who right after uni then went on to do masters in other subjects, then simply put down they had were at uni for 4 years and ended up with a masters in computer science, simply ignoring the fact they only did one year in that subject (one of them got his bachelors in CS at a 2:2 and then converted to the same course and got a masters with distinction).

The MOST important point in my view is to approach companies directly. Don't trawl the job pages, find a place that will work well for you, contact their HR department and express an interest in working there. If possible see if they'll show you round so you can better get an idea of the place (it then becomes an informal first interview). There was some research into how people get jobs (as trustworthy as any such anecdotal research can be), by a long way at the front, people got jobs from having friends there recommending them. Then it was people that actively pursued a career with a company, then quite a way down the list was cold applications through agencies and job sites.

<applies flame retardant suit>

One last thing you could try, is lying a bit. I'm not saying fake some qualifications, but I don't even know where my degree certificate is, and it's never come up. Perhaps classify your degree in terms of modules taken, and therefore was basically joint honors. Alternatively you could embellish your role at your current firm, put down a friend there who'll back you up, as the reference. Be careful if you do, there's a fine line between creatively massaging your CV and fraud.

<still have suit on, I'm flame proof right now guys>

Hope that helps.

QFT.

I might argue with the split, though. It might be more like "Learning to program, 20-30%: a talented parrot can do that much; problem solving and thinking on your feet, 70-80%: that's what Homo sapiens is good at."

I detest interviewers who ask coding questions. They so often concentrate on what they know and ignore the requirements of the position. We almost lost a good candidate because one of our interviewers asked him about coding in C when we were looking for a human factors engineer.

What I do is ask problem solving questions. The problems are always variations of ones we currently have in an unsolved (or recently solved) state, so they're current and relevant to the position. I always give a lot of context beforehand, so the candidate has a pretty good idea of what we're doing. Then I evaluate based on whether he or she can work out a plan to solve the problem, with extra marks for taking advantage of the context, showing creativity, and apparent ability to learn the technology involved.

So much good info I don't even know what to say but thanks. :)

The whole software dev cycle is something that I'm obviously going to be lacking in since I didn't do CS in school (and subsequently did not get the good CS internships / course projects which would've given me experience). How can I make up for this? So far the only plan I have is to learn the basics from MIT OCW...

Gotta love the Gog forums ethos :) and that most devs are more than happy to have a lil geek out on demand! lol

As for the lack of projects and experience with project management and the development cycle, this might not be as big a hurdle as you think, especially for a junior dev. Having at least one project with you as the solo dev, documented from start to end is a good idea and would be enough to show you understand the development cycle. Realistically, they’re not gonna expect you to lead a team from the offset but showing you can work under your own steam can only help. I'm sure between us we could give you a basic structure (like a list of section titles for the write up) and the general gist of what contents expected. Hell I'm pretty sure most on here would be happy to critique it for you when you’re done too :)

There are so many areas of project management, with different methodologies and countless buzz words (oh so many buzz words :'| Check out 'scrum' for some of more elborate ones...) but as a general overview (and I'm sorry if this offends or belittles any project managers) but on a solo project, good project management is quite simply budgeting your time properly so that the systems finished and tested by the deadline. Simplest way is to split the project into sections, and distribute the time accordingly, leaving some spare time for when things overun. That’s pretty much it :) The Development Cycle sits inside this and follows common sense, basically testing as you go and ensuring you're on the right track with the agreed specifications and requirements.

In all fairness to them, large team project management can be very similar to herding cats tho :P