A paperback costs what, 8 bucks? Seriously, you're that fucking cheap that you won't take a stab at a book? It's not like you need to buy a $30 hardcover, or a $60 video game here. There's also used bookstores where you can buy them for less than half that.

I don't know what the hell in my post you're responding to. I was talking about computer engineering degrees, which are a combo EE and CS degree. But to comment on the point you tried to make- CS is in the college of engineering at most schools. Parts of Comp Sci are pure mathematics, other parts are applied- for example, software engineering is considered part of CS, but has nothing to do with math. Same with HCI, which is a part of CS but has absolutely nothing to do with math. So even the point you were trying to make makes no sense.

I'm not denying that its hard. I do think that you need to mix in applications with the theoretical teaching though, or you lose a big portion of your audience. At least teach why this is important and how mistakes matter- setting a circuit board or two on fire as a demonstration would have helped a lot. By the time I did a full semester with no idea of how to apply my knowledge I was done, I never wanted to touch analog again. When I found out advanced digital design required analog I became a programmer.

It didn't help that the teachers at my college were extremely boring, and had no leeway to break the daily lecture to help people because a dozen or so sections were synched up to get to the tests at the same time.

A lot of software these days is plugging together libraries and frameworks off the shelf with well known standardized technologies.

But the amount of software being made compared to electronics is immense. yes, if we were rewriting all by hand it would take 10x more of us. But the software world has expanded. The EE world hasn't, while seeing the same reuse.

Same for mech eng- it isn't exactly a booming field.

What do you mean by inputs? Verilog or VHDL? The only thing RTL design has in common with programming is the syntax.

Verilog and VHDL are programming languages. They have some unique features as compared to normally used ones, but writing those is much closer to software engineering than hardware. Thinking back to my classes in them, the pure EEs almost all struggled. Those with a CS background (formally or informally) had an easier time.

But my point stands- we've made tools that greatly simplify EE work, while moving to a model where a lot of custom design is eliminated, reducing the number of EEs needed for a device, reducing their need overall. The same reductions haven't hit software because the need and number of uses for software have increased in that same timespan- the majority of savings brought by better techniques have been eaten up by making software more feature-rich.

Its been over 10 years, but it looks like the course list of requirements hasn't changed much.

I didn't take digital signal processing. I didn't take anything about power systems. I didn't take the advanced level courses of anything that had a I and a II. All of these were open to me as technical electives, but I chose not to take them.

I did take analog signal processing. I did take physics of semiconductors (how transistors work on an atomic level, it was a required course to graduate). I did take a course on fields and waves. And I took a couple of courses on digital circuit design and processor design.

From the CS course I missed the top level theory course on graphs that was required for a CS degree, but I took every other required course and more electives than most CS majors did. That was a personal choice though- I spent all of my electives in EE or CS.

Looking at the requirements for their EE minor, I took all the classes required to get one, with a few extra. Of course they didn't allow CompEs to get a CS minor or an EE minor officially. I look to be 2 classes off of what was required to get an EE major, but wouldn't have had nearly enough EE electives. And I took far more CS stuff than the EEs (EEs were only required to take the intro to CS class, CompEs were required to take data structures, an entry level discrete math class (part of a series of 3 for CS students), and an assembly course). CS majors only needed to take 2 classes on hardware- a watered down version of digital logic gates and architecture, and a watered down version of assembly (the hard version was taught by the EE department and for some reason only counted towards their requirement if they were transfers).

The big thing I didn't ever really understand in my EE coursework at the time is how to design an analog circuit to do something. That's partly my fault, partly lack of a high level follow on course, and partly my instructors fault- we never had a chance to design an analog circuit in our coursework, and they never really explained why we were doing what we did- it was just endless repetition of finding v and i at every point in a circuit using multiple methods.

And it makes sense- a lot of electronics these days is plugging together parts off the shelf with well known standardized technologies. It takes a lot fewer people to do this. Compare this to the 70s, 80s, and prior where CPUs were not king and you still did a lot of proprietary design work. Heck, FPGAs alone probably knock out a big need for EE work- the software there will more or less design the hardware for you, and it needs a programmer to write the inputs not an EE (although an EE who can program would be ideal). The need for them will never be 0, but its not as useful as they were a decade or two ago.

I have a BS in CompE. At my school depending on what optional courses you took you end up as the equivalent of either a EE minor and CS major or a CS minor and EE major. Since I went the first route, I've never considered myself an EE. Since my jobs, by choice, have all been in the CS realm I don't feel I have any knowledge in the EE realm anymore- I just have a deeper understanding of how hardware works and how to use it effectively than the average CS degree holder.

I actually did want to go into processor design at one point, I liked designing digital circuits. Then my senior year I found out that all those things I had been told didn't matter in digital (capacitance, inductance) actually did when you were fast enough. That was enough to convince me to write software for a career.

Yup. When I worked at Amazon the #1 question on internal mailing lists was "my Java webservice feezes up and breaks SLA whenever GC kicks in, how do I fix this?". GC is not a silver bullet, and you're going to end up thinking about memory on anything non-trivial.

You can't do the impossible, and no techniques will allow you to do infinite work in a given period of time. This can be a permanent push back (never going to do it) or a temporary one (we'll discuss it at the next planning meeting).

If they won't be pushed back, stop caring and dust off the resume. Don't work for people who aren't willing to compromise.

And most of them made horrible developers. There's basic bits of theory and knowledge that most (not all, but most) self taught and high school educated developers never learn. The move to requiring a CS degree wasn't due to degree inflation, it was to get more knowledgeable developers.

Its fairly unusual. I've only been asked about it once, and I told them I then cost 50% more. In reality I wouldn't have taken the job anyway- if you aren't willing to hire me, I'll go somewhere that will appreciate my skills.

No, today we have names for diseases that we didn't have names for then. The diseases (except for maybe AIDS) were in the human population at that time, they just weren't studied, were lumped in with other diseases, or thought to be an unavoidable consequence of old age.

By the time I'm working on a program I'm already told what it does. I don't think I've ever gone into a situation that blind. What I don't know is how it does it.

No, you want to make all code paths take the exact same amount of time and power. If the VM does things in a predictable way, even if your code doesn't, there's a possible attack vector there. You don't want the processor to be doing anything you can't guess in cryptography.

(Of course VM languages can still use encryption- just call out to a native part to do the actual work).

Not unless I think I missed something, or its a tightly coupled implementation with another function. My point was just that "just running" code isn't a good idea and doesn't generally get you what you need.