Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Businesses Education

Software Engineering vs. Systems Engineering? 79

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."
This discussion has been archived. No new comments can be posted.

Software Engineering vs. Systems Engineering?

Comments Filter:
  • Code or Bla? (Score:5, Interesting)

    by XBL ( 305578 ) on Monday July 25, 2005 @07:59PM (#13161349)
    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.
    • 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.
      • That isn't *always* the case. When I got mine the time from walking in off the street to getting "approved" was about 8 months. 9/11 might have added quite a bit of time to that though. Anthony
        • Nail on the head. Like you, mine is pre-911, but these days it takes longer. Funny thing, they ask the same questions and do the same investigation. The difference is the "Military-Industrial Complex" has grown quite a bit, so more people are trying to get them.
    • They can't outsource it _yet_.
    • You cannot just "go for" the highest clearence you want. There has to be a need for it. And you will lose it after there is no longer a need for you to have it.
  • by daedalus-prime ( 854575 ) on Monday July 25, 2005 @08:00PM (#13161352)
    The main difference between a Systems Engineer and a Software Engineer (at least in defense/aerospace) is the level of abstraction you're working at. A Systems Engineer works at a higher level of abstraction. They are the ones who right the high level requirements and make sure the design fits the customer requirements. They rarely get down to the code level.

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

    • From my experience working as a co-op at a defense contractor, Systems Engineering is not well applied to software development, as in they have very little in common. As a software developer there, the main interface to Systems Engineering is the project schedule. Most Systems Engineers have no programming experience (and my work seems to prefer it that way), so we end up with people telling us how long it will take to do something even though they have no reasonable basis for estimate. One wonders why proj
      • Systems Engineering is supposed to be the group that makes the connections between Customer, Hardware, and Software. Certainly, that connection isn't always as good as you would like it to be. In my experience, it is usually the Program Manager who harps on the project schedule.

        OTOH, with schedule pressure and penny pinching, I've seen the Systems Engineering group squeezed to the point that they really can't do their job...

        Overall, my recommendation is to check out how it really works in the positio

  • by Elwood P Dowd ( 16933 ) <judgmentalist@gmail.com> on Monday July 25, 2005 @08:07PM (#13161390) Journal
    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.
  • I've been both (Score:5, Informative)

    by Thumper_SVX ( 239525 ) on Monday July 25, 2005 @08:22PM (#13161479) Homepage
    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!
  • by Curmudgeonlyoldbloke ( 850482 ) on Monday July 25, 2005 @08:52PM (#13161660)
    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?
  • by dr_nik ( 843876 )
    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
  • 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.
    • Comment removed based on user account deletion
    • 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.

      I admire your idealism. I propose that you go dig up landmines in Vietnam.
      • Proposing serious consideration of the consequences of one's actions is not idealism, it is realistic responsiblity.

        • Proposing serious consideration of the consequences of one's actions is not idealism, it is realistic responsiblity.

          I agree it is, except he proposed quitting because the military does bad stuff, not because of anything having to do with the person's own personal situation. That's laying down in front of the tank. That is 100% idealistic, for good or for ill.

          So... if all the ethical people quit, would it be better or worse?

  • 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.
    • A base education in any field combined with understanding software design and implementation is good. People who call themselves programmers are a dime a dozen. People who can go from a user's description of a problem and turn it into a fully functional solution are still in demand.
  • by Anonymous Coward

    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 thin

  • by Anonymous Coward
    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-def
    • As somebody with a "real" engineering degree (MSEE)...

      Translation: "Hi, I'm an asshole."

      There's barely any theory...

      Translation: "I somehow got [presumably] two EE degress without learning anything about computer science and probably faked/cheated my way through most of my math classes."

      Basically, you're ignorant. Design can have as little or as much to do with the final product in software as it does in any other engineering discipline. Engineering software is no different than any other; design,
  • Hobson's Choice (Score:3, Informative)

    by aminorex ( 141494 ) on Tuesday July 26, 2005 @02:00AM (#13162947) Homepage Journal
    Frankly, either one and you're screwed.
    Pick door number 2.
  • by HalWasRight ( 857007 ) on Tuesday July 26, 2005 @02:15AM (#13163009) Journal
    Coding may be a noble profession, but you are replaceable. If you are a code pig, you are nothing. A spec can be coded by anyone. If you want to keep a job (and buy a house, and that lease that BMW), and pay for your kid to go to college to not be a code pig, then you better be one writing the spec, not implementing it.

    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.

  • by jschmerge ( 228731 ) on Tuesday July 26, 2005 @03:09AM (#13163171)

    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.
  • 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.
  • 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 star
  • Software Engineer = Monkey with a PC making code System Engineer = Monkey Trainer IT Consultant = Monkey Trainer with expenses (oh yeh!)
  • Software Engineer = Monkey with a PC making code
    System Engineer = Actualy analyses, designs and defines the system (sometimes codes with the monkeys)
  • 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.
  • 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
    • Parent has the best description that I could see from others, though they all ring true.

      I'm a software guy who's in constant interaction with systems to refine things.

      I've worked with some great systems people. The idea of making requirements makes me cringe though. Getting into some code is where its at for me, whether I'm fixing it or creating it.

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Working...