Software Engineering vs. Systems Engineering?
An anonymous reader asks: "I recently graduated with a master's degree in computer engineering. I am currently a software engineer for a defense contractor. They (same company) have now offered me a position as a systems engineer. Any advice? What are the long and short term ramifications of the change, in respect to job duties, advancement, compensation? I am pretty much fresh out of college, with only a year of co-op experience. I am a little over whelmed by the choice with no experience to go by, but I also don't want to pass up a great opportunity. Thanks for the help."
Do you like to write code? Do you like to do analysis and design of systems? Which one do you like better?
I think that I would find Systems Engineering boring. Of course, I am a Software Engineer.
If you are in defense contracting, get the highest clearance level that you can, preferably T.S. That will give you more job security and demand on the contracting market if you do need a new job. That is way more important that Software or Systems engineer.
IMHO, you all should be worrying about your computer jobs over the next 10 years, EXCEPT in defense because they can't outsource classified projects to India.
A Software Engineer will be closer to the code, though in the defense industry there are software engineers who don't do alot of coding.
As far as career advancement, I don't see a whole lot of difference. It all depends on what you want to be doing....
In systems engineering they focus on killing the whole person.
Sorry. Can't help it. Consider the ethics of what you'll do for a living in either position.
There are no trails. There are no trees out here.
You know, with a MS, you can make more money working at Borders Books...
Walking in the door, takes about 1.5 to 2 years to get a TS, a little less for a Secret. But they are worth gold, there are many jobs that regardless of your quals, a potential employer will just walk away if you don't already have at least a Secret.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
During my long years I've been both a software engineer and a systems engineer (and a brief stint as a manager that we just won't talk about, mmmmkay?)
Anyway, the choice basically comes down to what you prefer. Both are heavily analytical but software engineering is probably a little less "dynamic" (not in the good sense) than systems. The reason is that systems primarily deals with hardware and operating systems; stuff that changes often. You get behind and it's tough to catch up. It's not often that you get a new language to work with as a software eng, but sometimes concepts change.
I personally have gravitated recently toward being a systems engineer (R&D) because I actually get a kick out of the dynamic nature of systems at the moment. However, stability isn't really there; there's plenty of people younger than I who are quite willing and able to do some of the same stuff I do... but often I bring a level of experience to the table that they can't beat. On the other hand, software engineers are easier to outsource / offshore!
Do whatever you think you will enjoy. Myself I find that systems engineering can be tedious; I've just spent an entire day at work troubleshooting problems with Lights Out cards on HP Blades (turned out to be another engineer had cocked up the IP subnets on 2/3 of them!), and so to be honest I feel like I've come full circle and accomplished next to nothing today. I must admit I had fewer days like this in Software because at the end of the day no matter what I had usually made strides in the code I was working with.
I guess this might help; if you enjoy massive bugfixing sessions in your current software engineering job, then you might be a good match for systems engineering. If you prefer the creative element to software engineering then systems is probably not for you.
Hope this helps!
There are a lot more openings for software engineers than there are for system engineers.
The title (system engineer) is misused across the
industries. In some sectors it means field tech
support, sales support, and customer trials
monkey.
So some clarity of job description might be needed.
In Telcom equipment industry your definition would be called a systems architect.
And NO you won't make more money at Borders...not unless you own the store.
Watchin oWo
What do the job descriptions say? What are you likely to spend your time doing during, say, the first 6 months? What are the prospects going forward? Which do you think you might enjoy doing more?
You haven't really been specific enough for me to answer this question as well as I would like to. But I'll try anyways.... So if you've been offered a system engineering role after working in software, my guess is that it could be 1) a software-integration role. This possibly implies putting together different parts and making sure they work with one another. OR 2) a role that requires you to take customer requirements and translate them into code. In terms of compensation, I think it will be better. Also there will be more of such jobs in the future with the actual code writing being done in Bangalore or wherever. I would however take it upon myself to stay in touch with coding either on company time or on my own time. The onus will be on you to stay current so that you can understand what is going on at the so called 'lower level'.
This is 'Ask Slashdot' isn't it? And this is definitely more postworthy than the recent spell of inane google posts. Chill out..............
Consider quitting your job. Take a serious look at what the military that your industry supports is doing to people all over the world. This post may be flame bait, but as an American, I think we all need to take a look at the ethical implications of our economic actions.
------ Take away the right to say fuck and you take away the right to say fuck the government.
Get a mechanical enginering degree and move on from there. That's what I'd have done if I wasn't so stupid and poor 25 years ago. Learn to love learning stuff other than ones and zeros before you start designing software. Programmers are a dime a dozen and pretty replaceable.
"Also try asking people that already have the position what they do and decide if you would like doing what they do"
/. lately and the Ask Slashdot threads, post an Ask Slashdot about it. I mean, Ask Slashdot, in my mind, is all about getting information from peers and other professionals. If it isn't that just what on earth is it good for?
Gee, that kinda looks like what he's trying to do, in a slightly more abstract sense. He IS fresh out of school, he says. He probably doesn't have many connections and more experienced peers to look to. I think it's a perfectly appropriate question for Slashdot because there are lots of professionals here who can tell him about what they do.
"Then grow some balls and make a damn decision by yourself."
What, without information? Let's have a leap of faith. But wait, you painted a path to this decision in your post. It involved querying others who do that kind of work. Thus he turned up here.
If you're so pissy about
If you go to systems, you'll be working high level requirements pretty much all the time. You will attend meetings constantly, one-on-one or group meetings, and will mostly bicker over details. Granted, you are trying to hash out what a system (hardware or software) does, and this is part of it. Sometimes this can get out of control and that can be very frustrating. Systems moves slower and is not as aggressive as software, so you lounge for a while and then its pain time.
System people do the same thing, forever. They get stuck in a routine which consists of tools and process. Arguments over tools and process can be daunting, especially when you're switching tracks or attempting to improve your organization (or team).
You may also find your technical skills becoming dull over time. This is really speculating since I don't know what you do. If you're a systems engineer working on displays, or flight controls, or something complex like that, you most likely will have to keep your domain knowledge and engineering skill sharp. If you're a systems engineer, analyzing requirements for software, I think my prediction for "dulled" skills may have a higher probability of coming true.
If you stick with software, you may end up helping the systems engineer. If you're working on the hot project the army currently has, then mostly likely you will help your systems group as some of them may be busy with subs, or they are organizing large meetings and reviews. Your systems team will also most likely lack the skill in the (software design) methodology the project is pushing on everyone, and... most likely they are kicking and screaming about switch their toolsets, and processes. I've wearing a systems a hat for a few months now and in a few more I will be wearing my software hat (ah...). I know methodologies and the tools, understand the targets very well. So I help and mentor the systems guys until they get accustomed in working differently. I also get to make sure I can understand my requirements as I wrote them =).
So if you want the "systems" experience, you will most likely get a good taste of it taking the software engineering role. You will also get to write software and tackle those problems. You will also be using all the tools that are developed to unify your platform. With that, you have mobility to other contractors working different projects in the same program (as a whole). Considering most programs are very long (sometimes 10+ years), this will be good since you want to move around, get your increases in salary, and eventually find your comfort zone.
Switching to systems is the easy part, you can always do that. Switching back to software will be more difficult. Also keep in mind that any new defense program will fund large amounts of training for you. Free training is good, and looks great on your resume. You will get more as a software person as I can attest to this. Granted the defense industry is slow to grab up new techniques, tools, frameworks and methodologies, the newest ones are, and they are still very popular in the commercial industry. So you have mobility there too.
I'm in a similar position. I have my MS in CS (its been a year). I've been working a program since I graduated for less than a year, as a software engineer. I have a friend who working at a higher level org as a systems engineer. He has an MS in EE. He's organizing meetings with primary contractors and subs. So after 6 years of academia in EE, he organizes meeting. I wonder what he will do if he find defense boring as he's not practicing EE at all. Just food for thought. Good luck.
As somebody with a "real" engineering degree (MSEE) now working in IT (I call myself a "systems consultant") I wouldn't dare call any of this stuff "engineering".
There's barely any theory (and whenever we have good theory, such as the relational model, it's soundly rejected by pretty much all of the people you'll run into, who view ignorance as an asset to be treasured). Design is possible, but has little to do with the final product. UML is Satan's Notation. Development platforms and languages are ill-defined and full of bugs. Security holes are now *expected*, people don't even bother trying to design systems without them. Rigorous design and construction is a foreign concept to many of these "engineers" (yes there are exceptions, but they seem to be randomly distributed).
Any fellow engineers wanna back me up before I get modded into oblivion?
Comment removed based on user account deletion
Thanks for TROLLING, but we won't play. A very large proportion of the readership will be interested in the replies to this query, and a remarkably large number of readers will compose a broad spectrum of persons with peculiar experience pertinent to the reply.
This was a sweet rarity, a truly useful Ask Slashdot. The whining critique is neither sweet nor rare, but a predictable stink.
-I like my women like I like my tea: green-
Frankly, either one and you're screwed.
Pick door number 2.
-I like my women like I like my tea: green-
Dude, this is a no brainer. Take the JOB, not the dirty, blue collar, life limiting, chicken shit cop out. You can always code for free on the weekends on some open source project to get your ya yas out.
"This mission is too important to allow you to jeopardize it." -- HAL
This post is an agregate of posts that I've read in this discussion, filtered through MY filter based on MY experience. Take it as that.
As a systems engineer, you will be doing a lot of writing. This writing will be specifying how systems will work. In order to do this job competently, you will need a lot of experience with how the system has worked in the past. In order to write the correct stuff, you will need experience that you have not yet had.
My advise is to tough it out with a real-world company (i.e. not government contract work) for a bit and see what real-world engineering entails. After you get sick of that, go back to the government contracts and change the way they waste money.
Private industry teaches you a lot that you will not learn working at Boeing/Lockheed/whoever.
Well, the change is simple. Put away the 80-column cards, take the soldering iron, and start engineering the systems.
Anagram("United States of America") == "Dine out, taste a Mac, fries"
I have studied Computer Science, but my programme included a good amount of system engineering. I regard system engineering, especially real-time systems, much simpler than software engineering. However, be warned that a small bug can have catastrophic effects in real-time hardware-based systems, so if you work as a systems engineer you must be very careful.
I'd much rather have the "I don't know what job to take, help me". Doing tech support on slashdot sucks. There are dozens of forums for hardware/software support, use them. Reading crap about people who can't get thier winmodem working in thier hylafax server is kind of boring, and more suited towards a site specific to hylafax/winmodems. A question like this one is far better IMO. Of course, maybe you've not graduated college yet, and don't care about job titles or thier duties, or how they may affect you for the rest of your life. I think this makes for a far better discussion than trying to find an obscure driver.
what a "systems engineer" does.
Clear, Dark Skies
You'll find that in the "real world" particularly in big government or corporate projects, your title indicates little more than your paygrade.
Theoretically, a "Systems" engineer focuses on more abstract design and the interaction between various modules of a system. In reality, you're the new kid and you'll get whatever project your boss has that nobody else wants.
Sometimes being in particular titles can help or slow your promotion prospects. At one gov't employer that I was at, a IT Project Manager started making slightly more than the typical Network Analyst or Computer Programmer/Analyst, but getting promoted was alot more difficult for someone in the Project Manager track. YMMV.
Conformity is the jailer of freedom and enemy of growth. -JFK
No.
In systems engineering, you focus on how you go about making you kill more of them instead of you.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Software Engineer = Monkey with a PC making code System Engineer = Monkey Trainer IT Consultant = Monkey Trainer with expenses (oh yeh!)
In the not too distant future, next Sunday A.D.
Software Engineer = Monkey with a PC making code
System Engineer = Actualy analyses, designs and defines the system (sometimes codes with the monkeys)
In the not too distant future, next Sunday A.D.
It's often more about the journey than the destination. The goal here isn't just to get an answer for the submitter, but to start a discussion, exchange ideas, and possibly introduce 'systems engineering' to people who haven't heard of it. The fact that it means different things everywhere is even more reason to get people talking about it.
At least I'd like to think that's why the editors posted it...
If you have an MS in CE, why aren't you doing CE?
Systems is very tedious and abstract... if you're used to being low level with HDL or whatnot, SW will be more fulfilling to you - actually solving problems, instead of creating them.
For my TS, although I already had S, they talked to all my friends, interviewed all my neighbors in every place I've lived over the past 9 years (9 years?), employers, and so on. Credit check, IRS, fed, state, and local cop check... Took 18 months end-to-end. And the work I do is not that exciting.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
There is a big difference between "Systems Engineer" and "Operating Systems Engineer". Several other people who have posted here (besides yourself) seem to be confusing the two.
To the Slashdot editors and coders:
Slow Down Cowboy!
Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment.
It's been 1 hour, 5 minutes since you last successfully posted a comment
Chances are, you're behind a firewall or proxy, or clicked the Back button to accidentally reuse a form.
No, I'm not behind a fucking firewall or proxy, and I didn't click my fucking "Back" button. What happened was that you fucking idiots don't fucking tell me in advance (when I fucking click the fucking "Reply to This" link) how fucking long I have to fucking wait to fucking post. Instead, you wait until I have composed my reply and try to submit it, and only then do you tell me that I should have waited longer. This is totally fucked up. If I didn't have ad blocking turned on, I would email your advertisers and complain about how you treat people who post anonymously when they post useless crap because they are afraid to compromise their kharma.
Oh, and when the fuck are you going to fix the punctuation in your obnoxious message ("It's been X minutes since you last successfully posted a comment" should end with a period/full stop, you stupid motherfucking hamster fondlers)?
Please note that the above is meant to be friendly helpful criticism. Please interpret it in that spirit. Thank you.
It really depends on what you want to do, of course. If you're a "big picture" type, go for systems, they get to figure out how all the parts should interoperate, and get to irritate the software guys to no end. The downside is that there's a lot of inane requirements writing (almost as bad as legalese.)
I'm in software currently, and of course we deal with the details, the "small picture." We take the wishful-thinking requirements and make them actually work, while suggesting useful features back up the chain.
There are merits both ways, of course, but if you choose systems, please be sure you keep familiar with software techniques. There are few things more annoying than an incompetent Systems Engineer trying to push bad requirements on you and not listening to why it won't work, or why it would be easier and more effective to do it slightly differently.
...at a military contractor so perhaps I can provide some insights from my experience. Generally the job of a systems engineer at a military contractor is to define requirements at the beginning of a project and integrate the parts of the system toward the end of a project.
The majority of this job does not require technical competency except for perhaps some of the requirements definition phase (depending on your level of seniority, you may have an opportunity to make important architectural decisions) and the integration phase (troubleshooting, and assorted pandemonium). You may expect to spend most of your time on the phone arguing about part numbers and other activities that seem like secretarial work.
When you are a software/hardware/whatever engineer who actually writes code, pushes polygons, or grinds lenses you are usually involved in a highly technical organization (superiors, and subordinates typically have technical training and are technically competant) but likely have little visibility or knowledge about the final product your design ultimately integrates with.
In systems engineering, you gain this overall visibility at the expense of fine grained control. You no longer have visibility over the inner loop of that Kalman filter coefficient estimator. (are registers being optimally allocated?) You are at the mercy of other people meeting your phase margin spec in the low noise amp. (do they need a startup circuit?)
That being said IMHO, people like you who have done low abstraction technical work make better Systems Engineers. Most of the Systems Engineers I used to work* with would disagree with me.
*Having a higher level view of the product that you are delivering can be a mixed blessing. Perhaps you have already made your decision and are comfortable with it. To be in the this business, you have to be comfortable with the fact that you are responsible for killing other people. Since my employer only has one customer and that customer only wants one type of product (the decidedly fatal variety), I decided that being unemployed weighted better on my conscience. Your mileage may vary.