Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 10 down vote favorite
2

I am in the progress of moving on to a new software development job. There are openings for both low-level control software and high-level application software. To me, both opportunities are exciting.

Working on embedded/control software technically means programming the operating system for a specific hardware. But this might mean I will be an expert for only that hardware's API and if I move on in the future, I would have to throw away that knowledge.

Working on application software, in my understanding, means software that can scale, so I will be developing my design skills as well. Moreover, libraries tend to be reused compared to hardware APIs so what I learn might be of use in the future.

But that's my narrow view of the world. I do not have enough experience to see a bigger picture. Is there anything else I should be aware of in choosing between these two software development flavors?

Thank you.

share|improve this question
2  
Most important is that you do the one you enjoy the most – Anto Apr 12 '11 at 20:51

closed as not constructive by Yannis Rizos♦ Mar 7 '12 at 15:16

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

3 Answers

up vote 4 down vote accepted

Don't worry about API knowledge becoming irrelevant. Any reasonably well-designed API can be learned pretty quickly--to proficiency at least, if not to an expert level--by any competent programmer with a certain baseline level of domain knowledge. So if you don't know some library when starting the job after this one because you didn't work on it in this job, that's not a serious problem.

All other things being equal, I'd pick the job that allowed me the greater opportunity to grow and develop my skills. For example, if you've never done low-level before, this is a great opportunity to learn some very valuable principles about how computers work at low levels. (And even if the specifics don't transfer well to other systems, you'll pick up a lot of generally applicable principles too.)

On the other hand, if you're already well-versed in low-level stuff, then by all means go with the applications job. But either way, try to get outside your comfort zone and learn some new stuff. You'll be glad you did after a year or two.

share|improve this answer
1  
+1 for trying both. I've found that after doing lots of low-level stuff for some years, it's getting harder to get considered for higher-level applications positions! – Jeff Apr 13 '11 at 1:17
up vote 7 down vote

Keep in mind that everything in this field is throwaway knowledge at some point. Do what you enjoy but keep your eye on trends and don't be afraid to move.

In general, the higher level skills do get paid a bit better but it also means increased exposure to customers/business partners the higher you go. If you are technical but good at explaining complex subjects to non-technical people this is a good route.

Low-level skills that are in demand also pay well but, as you point out, the specific skills are short-lived. If you really love understanding the nuts and bolts of how things work, then you should follow this route.

Good luck!

share|improve this answer
2  
Your comment of the Low-level skills is pretty much totally wrong. Most hardware related activities are pretty much the same. Understanding the basics of the memory map, local bus interface, PCI, DMA transfers, setting up memory such as DDR, configuring interrupts..ect don't really change. There is no such thing really as a hardware API, unless you want to call the register set of whatever device you are working with the API. Also, on average, embedded software engineers make more money than other software areas such as say web design or desktop application development. – Pemdas Apr 12 '11 at 22:35
Please read what I actually posted before condemning it. – Dave Wise Apr 12 '11 at 22:54
I did. I am arguing that the specific skills are not really short-lived and that you get paid more as an embedded engineer. That is pretty much exactly the opposite of what you said. – Pemdas Apr 12 '11 at 23:15
Actually, I said "Low-level skills that are in demand also pay well". As to specific skills, could you please tell me the interactions of the Palm OS vs. WinCE? How do those compare with that of Windows Mobile or Android? All of the things you mention are general skills, not specific and apply to all of programming. – Dave Wise Apr 12 '11 at 23:28
1  
Understating the intricacies of each operating system is not a skill, it is application domain knowledge. I suppose this is the point where we misunderstood each other and perhapses I miss understood the original poster. Regardless, embedded software engineers make more money regardless of the demand of their domain knowledge. It is not the domain knowledge that is ultimately important. – Pemdas Apr 13 '11 at 0:05
up vote 1 down vote

My recommendation would be to go with whichever one is going to most broaden your "narrow view of the world" and give you more of the "experience to see a bigger picture". You say you're excited about both opportunities, and as Dave Wise said a minute ago, "everything in this field is throwaway knowledge at some point." So if your previous experience is more high level, go with the low-level control software. Vice versa? Go with the high-level application software.

Once you've experienced more types of development, then you can start really focusing on doing what you enjoy most. At the moment it sounds like you haven't discovered what that is, yet. Good luck!

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.