"Software engineer" encompasses a wide range of activities. I am considerably over age 40 yet I could never be replaced by (even multiple) 20-year olds. Two reasons are:

1. I have one foot in academic research, and have been not just following but advancing the state of the art and publishing hundreds of papers in scholarly journals and conferences for decades;

2. One of my job functions is to show up at the scene of a software disaster in my firetruck, assess the management and technical situation, make recommendations for how to recover, and (if allowed, which is not always) work hands-on with the engineers to help design and implement corrective software. After decades, you name it, I've been there and done that. No one much younger than I am can have had all that experience and be able to cost-effectively diagnose and solve software engineering problems. It's like internal medicine physicians: older ones have assimilated more and have deeper broader insights than younger ones.

What an ignorant comment. Just because you don't like something (and not just music) doesn't mean it is bad. Most of the composers we consider masters today received considerable criticism in their time. Each musical "period" uses its own "language" -- if you don't understand the language, you probably won't like (or at least fully appreciate) the music. Sometimes gaining sufficient understanding to appreciate something new, whether wine or music or sculpture, etc., takes time and even effort. You have to decide whether it seems to you to be worth the time and effort. I found that taking the time and making the effort to appreciate Messiaen paid off in great joy. I have not considered it worth my time and effort to appreciate Cage. That's a matter of personal judgment and not a criticism of Cage, who is very highly regarded by experts.

Yes--yes I would. Popular cuture" is an oxymoron.

The U.S. hasn't had an operational battleship in quite a few years. Aircraft carriers an be viewed as mobile U.S. military airports and thus are an effective tactical and strategic weapon. The only other ships scary to our enemies are our submarines, which are strictly strategic.

The Arsenal ship was very controversial for a number of reasons (e.g., lack of sufficient self-defense) and so was overcome by events: "The U.S. Navy has since modified the four oldest Ohio-class Trident submarines to SSGN configuration, allowing them to carry up to 154 Tomahawk cruise missiles using vertical launching systems installed in the tubes which previously held strategic ballistic missiles." [Wikipedia]

There is a vestigial article on embedded software on Wikipedia: http://en.wikipedia.org/wiki/Embedded_software.

A key aspect is that embedded systems and software are "reactive" in that they receive information (data, signals, etc.) from devices external to the computer system, process it, and usually (but not necessarily) send data out to devices external to the computing system. A real-time embedded system (not all are) has time constraints for completing all three of those steps.

A case can be made that programming an embedded (often real-time) system is harder than programming a non-embedded -- called a "transformational" (for obvious reasons) system. The increased difficulty is due to the programmer typically having to deal with the exogenous devices at a very low level, requiring detailed understanding of the devices' hardware. Embedded software programmers usually have some degree of electrical and/or mechanical and/or .... knowledge (but currently based on experience more than formal education). Real-time embedded software and systems must consider meeting completion time constraints for these reactive interactions a correctness (perhaps even a human safety) criterion, not a performance criterion -- adding exponentially greater difficulty as the size and functional and non-functional (e.g., fault management) and complexity increases. Embedded programming deals with more than software abstractions.

A counter-argument can be made that programming an embedded system is at least often easier than programming a non-embedded one. That argument is based on several considerations. Embedded software is usually smaller size (e.g., lines of code) than most non-embedded software -- but in number of application domains (such as certain parts of telecommunications and military systems) the embedded software is 10's of millions of source lines of code. Another consideration is that the embedded system application software development systems and operating systems are almost always simpler than those of non-embedded systems. Whether that indeed makes embedded programming easier-- more difficult -- is specific to the systems, and also a matter of opinion.

So can just anyone be a programmer? Here I ask "Can just anyone be an embedded systems programmer -- good enough to be successful?" I assert that fewer people can be successful embedded -- especially real-time -- programmers.

I provide one piece of anecdotal support for my assertion.

In one of my former lives, I was on the faculty of both the Computer Science Department, and the Electrical and Computer Engineering Department, of Carnegie Mellon University. I created and led one of the largest research projects -- it was for embedded real-time systems -- moreover, distributed ones, thus adding a whole new dimension of complexity. We implemented our distributed real-time OS kernel directly on the bare hardware of multiprocessor nodes which we created by modifying Sun boards (a donation from Bill Joy), and then interconnected those with an Ethernet. (Yes, you can create a real-time Ethernet, or even a real-time system using standard Ethernet--a non-trivial topic out of scope here.) At that time, the standard practice for academic OS research was to implement on top of a *NIX. I was the thesis advisor to five CS Ph.D. students and five ECE Ph.D. students, all of whom did their thesis work in the context of my research project. In addition, I taught cross-listed courses attended by both CS Ph.D. students (a Ph.D. was the only CS degree CMU offered at that time) and ECE M.S. and Ph.D. students.

My experience, which was the consensus of a small group of other faculty I consorted with, was the anecdotal support I referred to: we agreed that in general our experience (note the two qualifiers) was that it was easier to educate an ECE student to be a good embedded programmer, than it was to educate a CS student (having a non-engineering -- usually math, physics, or CS bachelors or masters degree) to be a good embedded programmer. To grossly over-simplify it: the software-minded students were trained to think in terms of system and software abstractions, and lacked the fundamental mindset of an engineer that even a few EE courses (e.g., control theory) would have imbued; and most lacked even rudimentary knowledge of and experience with device hardware. The ECE students also thought in terms of abstractions -- system and hardware, and software to a lesser depth than (most of) the CS students; and their perspective was that of an engineer. They needed additional education in relevant CS principles (e.g., theory of algorithms, formal methods, software engineering).

While many "CS" departments are just awful, check out the curricula at the top 10 CS departments (that ranking is decided annually by consensus of CS department heads) -- CMU, MIT, Stanford, etc. You get a through education in computer SCIENCE, during which you learn both the PRINCIPLES (including healthy doses of hard core theory--proving programs correct etc.; AI; databases; hardware, etc.) and the BEST PRACTICES of programming -- as much as is feasible in four years. IHMO a good CS education requires an M.S. If you intend to be a programmer, chances are you are going to start out as a good relatively inexperienced one and with experience become one of the 10%'ers that can out-program 10 mediocre programmers. But many people with CS degrees are not focused on programming -- for example, they may be focused on software engineering, which is a separate but closely related field. And of course he are people who get CS degrees, just as there are people who get physics degrees, not to work in CS or physics but to use their education in another field.Finally I'll note that some people get CS degrees so they are better prepared (assuming it's from a good department) to get M.S. and Ph.D. CS degrees.

I know a kid who has been a real car whiz all through his teen years. He buys cars, fixes them up, and sells them. When he graduated from high school he had a choice to make: a trade school for auto mechanics, or a B.S. in mechanical engineering. He wisely chose the B.S. He still spends hours every single day buying, fixing, and selling cars. He has a B average in his mechanical engineering education. He loves the theory and principles he learns in his courses, despite having to learn how to use tools like differential equations etc -- just like he had to learn how to use tools to repair auto engines and transmissions. His college requires two internships during the four years. He was hired by a military lab when they saw a kid with both self-taught experience and intense love for the field, plus one who is doing well in the theory and principles. The military facility kept him on the payroll after his first internship, committed to have him back for his second internship, and said they intend to hire him permanently when he gets his B.S. -- but he thinks he may prefer to get an M.S. in mechanical engineering because the B.S. coursework has been so valuable to him in his work with the military. This kid is going to be a big success. I know software engineers (note I didn't say programmers, they are not engineers, but the same goes for them too) who have followed this same combined path. If you don't want to get a formal degree in CS, you're almost certain to turn out to be a technician like many (if not most) programmers are. We need good technicians so that's great too.

Check out the SCHOOL -- not just department -- of CS at CMU.

I have several thousand technical documents ranging from hundreds of pages to a dozen pages. I have been carrying them around with me on a 500GB portable USB hard drive, connecting that to my laptop or a public computer. I got 801 of them on my DX before it filled up, so now I am in the process of triaging all my PDFs to get the most important ones on the DX. I have no problems at all reading them, even the mathematics-intensive ones. Something I thought of after I bought the DX: hey, now I can easily have with me the PDFs of all (a couple hundred) of the journal and conference papers I have published. One obvious use is for employment interviews (I'm just saying) without having to tote my laptop -- the show-and-tell experience is totally different and cool. Well worth the price for my purposes.

No that is not what it means, however counter-intuitive it may seem. Look it up.

I'd gladly pay -- I'm not sure how much, but up to say $10/mo. for unlimited downloads, or $0.10 each, is a no-brainer for me.

Mostly because people are carrying around laptops.