Slashdot Mirror


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."

8 of 79 comments (clear)

  1. In systems engineering they... by Elwood+P+Dowd · · Score: 3, Insightful

    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.
    1. Re:In systems engineering they... by stinerman · · Score: 2, Insightful

      Sorry, Mr. Dowd. There is no such thing as ethics anymore. There is only more money.

      My school works extremely closely with the DoD. Subsequently, most of the people that graduate end up working there through job placements (they guarantee a job within 6 months of graduation). Needless to say, I'll probably have to turn down a few offers which will invalidate my guarantee. I'll be broke, but at least I'll be able to look at myself in the mirror every morning.

  2. Hope this helps..... by dr_nik · · Score: 2, Insightful

    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'.

  3. Re:What the hell? by fruitbane · · Score: 3, Insightful

    "Also try asking people that already have the position what they do and decide if you would like doing what they do"

    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 /. 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?

  4. My Take (similar position) by Anonymous Coward · · Score: 2, Insightful

    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.

  5. Engineering, it ain't by Anonymous Coward · · Score: 1, Insightful

    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?

  6. Re:What the hell? by aminorex · · Score: 2, Insightful

    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-
  7. It is your choice... by jschmerge · · Score: 3, Insightful

    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.