Considering Career Change to Software Development

[KingsWeBe]

Hi DaniWeb Community,

I am considering a career change to Software Development Engineering and found DaniWeb in my first attempt tonight at learning more about the field and how to get started.

I have 6 years employed experience as a MS Access Developer and Administrator that I am hoping can be a base to start from into other languages, platforms, and employment (!), specifically in Sofrware Development Engineering.

Three years ago, I transitioned out of database development into a Forecasting Analyst position because 1) this role allowed me to become a direct employee with better benefits vs. an outsource employee, and 2) I was scared about programming work drying up for me because of the increasing overseas outsourcing that was (and still is) going on. It was particularly an article in Wired! magazine that really pushed me over the edge with this fear. A few years later now, I realize Development-type work was something I enjoyed much more than the Business-related role I have been in, and that the bleak job-prospects outlook I had for programming and development wasn't totally grounded in fact. So, now I am beginning to try to find out what languages I should learn first; what non-programming skills are valued/required; education requirements; what are, if any, the various job positions that fall under the heading "Software Development Engineering", etc. etc. I think DaniWeb will turn to be very helpful and a fun experience.

With that, I welcome suggestions and information from anyone who knows about the Software Development Engineering field, and I thank you in advance!

Happy Posting,

KingsWeBe

[zandiago]

Glad to have you here!

[selfhelpebooks]

Hi there,
Thanks for the detailed intro.
Welcome, by the way!

[jwenting]

ever more you'll notice that if your main skill is plugging away at code, turning technical designs into source using an editor, that you're quickly going to become an interchangable resource easily replaced by some cheap kid from India or some other low-wage country.

Develop domain knowledge, interpersonal skills, management skills, design skills.
Learn how to not just hack away at that code but find out from vague requirements what it's supposed to do.
Learn not just what the customer wants (he'll often tell you that) but what he needs (he may not even know what he needs...).

Remember that commercial software development is no one man show. And the programming is only a part of the equation, and usually the easier part (though often among the most time consuming).

I at the moment spend probably only about 2-3 hours a day on average with my nose in code, and only half of that is spent writing or modifying code.
The rest is spent testing, trying to reproduce problems, communicating with customers and colleagues, analysing requirements and problems, etc. etc.

But then I'm no junior, so my tasks are more varried than those of a beginning programmer (and you'll likely notice that there is precious little work for those in north America or western Europe, unless you have good skills elsewhere so you're flexible).

[KingsWeBe]

ever more you'll notice that if your main skill is plugging away at code, turning technical designs into source using an editor, that you're quickly going to become an interchangable resource easily replaced by some cheap kid from India or some other low-wage country.

Develop domain knowledge, interpersonal skills, management skills, design skills.
Learn how to not just hack away at that code but find out from vague requirements what it's supposed to do.
Learn not just what the customer wants (he'll often tell you that) but what he needs (he may not even know what he needs...).

Remember that commercial software development is no one man show. And the programming is only a part of the equation, and usually the easier part (though often among the most time consuming).

I at the moment spend probably only about 2-3 hours a day on average with my nose in code, and only half of that is spent writing or modifying code.
The rest is spent testing, trying to reproduce problems, communicating with customers and colleagues, analysing requirements and problems, etc. etc.

But then I'm no junior, so my tasks are more varried than those of a beginning programmer (and you'll likely notice that there is precious little work for those in north America or western Europe, unless you have good skills elsewhere so you're flexible).

Hi jwenting, Your reply was very informative and helpful - thank you. I do consider one of my key passions and skills is my ability to identify application requirements the customer overlooks or has not realized himself. I also have a strong ability to communicate with customers in non-technical terms as needed.

Could you elaborate on what you mean by "domain knowledge?"

Thanks!

[jwenting]

you need knowledge about the business and business processes of your customers.
If you're writing warehouse management software, learn about logistics.
If you're writing software to do bookkeeping, learn bookkeeping.
etc. etc.

[KingsWeBe]

you need knowledge about the business and business processes of your customers.
If you're writing warehouse management software, learn about logistics.
If you're writing software to do bookkeeping, learn bookkeeping.
etc. etc.

Ahh! understood - thanks

[iffEngineer]

If you want to become a valuable resource and not a commodity then learn a niche. In that I mean learn something that very few people know or know how to do. For example, my main niche is being able to communicate with PLCs via .NET and write HMI applications for clients while automating their manufacturing lines or assembly lines or general processes. There just aren't that many people that can do that sort of thing. But then again I have an electrical engineering background and taught myself programming several years ago. Plus I tend to try and stay on the cutting edge of software development and also try to find ways to use software to make someone's job easier. Just some suggestions but hopefully it will help you.

[jwenting]

no, do NOT get stuck knowing only a tiny little thing.
You're setting yourself up for a career of looking for jobs that aren't there.

Niche players are overall idiots who try to make every problem fit that tiny little thing they know rather than look for the best solution to a problem no matter what it is.

[iffEngineer]

Learning a niche does not mean that you isolate yourself to only knowing one thing. It's a funny thing but to get into a niche requires several years of doing a multitude of various projects that touch on several aspects of not only programming but full life cycle development, testing, technical writing and even business analysis. Without the knowledge of many areas you will fail at trying to learn a niche. But if you have the patience and are willing to learn many areas of IT then you can pick up a good niche and even many niches together. For example I know a couple of guys that were in IT for a very long time and just sat around and programmed financial websites for a living. They were very good at what they did but were becoming bored so they decided to start writing components that plug into major financial software packages and then turned those components into SAAS. And now they run a very successful company just sitting around developing components that make the financial sector of a company run smoother and speed up month end close events in companies. Therefore, niches can and will continue to be a very large section of the IT community especially if you are interested in starting your own company someday.

[oshipi]

ever more you'll notice that if your main skill is plugging away at code, turning technical designs into source using an editor, that you're quickly going to become an interchangable resource easily replaced by some cheap kid from India or some other low-wage country.

Develop domain knowledge, interpersonal skills, management skills, design skills.
Learn how to not just hack away at that code but find out from vague requirements what it's supposed to do.
Learn not just what the customer wants (he'll often tell you that) but what he needs (he may not even know what he needs...).

Remember that commercial software development is no one man show. And the programming is only a part of the equation, and usually the easier part (though often among the most time consuming).

I at the moment spend probably only about 2-3 hours a day on average with my nose in code, and only half of that is spent writing or modifying code.
The rest is spent testing, trying to reproduce problems, communicating with customers and colleagues, analysing requirements and problems, etc. etc.

But then I'm no junior, so my tasks are more varried than those of a beginning programmer (and you'll likely notice that there is precious little work for those in north America or western Europe, unless you have good skills elsewhere so you're flexible).

I'm impressed, but I'm not so sure what you mean by the term "commercial software development" could you please be more specific? because it seems interesting for me.

[jwenting]

any development done by professionals for pay,
Most larger "free" projects follow similar structures (hardly surprising, as most of them are run by professionals rather than schoolkids thinking they can create the next blockbuster game in their bedroom with a few weeks' experience).