IEE or IEEE - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: IEE or IEEE
On Fri, 08 Oct 2004 20:40:20 GMT, the renowned Joerg

Quoted text here. Click to load it

Engineers, doctors,lawyers and accountants always have holes in our
areas of technical competence (or, to put it more positively, areas of
specialization). Knowing when to get someone else to check the work
out, or when to give the work to someone else, is part of being a
professional. A licenced engineer in Ontario can red-tag a boiler and
force it to be shut down. That's in the law, and it's ANY licenced
engineer- even an electronics type. Of course there could be various
consequences if it was not justified. Same if a lawyer who spent all
his life doing tax law decided to take on a murder case.


Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: IEE or IEEE
Quoted text here. Click to load it


Having a degree from any but a few institutions in this country (England -
I'm not sure whether the other UK bits are as bad) is no longer a guarantee
that the holder can even spell "Maxwell's Equations". I'd be even more
surprised if (s)he put the apostrophe in.

--
--
Peter Bushell
http://www.software-integrity.com /



Re: IEE or IEEE

Quoted text here. Click to load it

How true.  The 'upgrade' of Polytechnics to 'University' status was the
worst second worse thing to happpen in education in this country.  I would
still brief HR to select candidates only from 'red brick' universities.

Ian
--
Ian Bell

Re: IEE or IEEE
Quoted text here. Click to load it

I think there are several ex-polys that take CS and/or EE very seriously -
Hatfield, Kingston, North Staffs, Teesside - and a lot of "old"
universities where the focus is very much anti-engineering and the CS/EE
courses are something of a joke. As it happens, our engineering team is
almost entirely Redbrick/Oxbridge/Robbins Committee - but they were
picked individually on their own merits rather than because of "where
they came from".

(Actually, there was one MSc course at a particular university in
the North that produced some of the most risible candidates for jobs
that I've ever seen - and yet on paper it was a place with a pretty good
reputation for computing and electronics... I did suggest a blanket ban on
anyone from that course after we'd interviewed a few complete clowns...)

pete
--
snipped-for-privacy@fenelon.com "there's no room for enigmas in built-up areas"

Re: IEE or IEEE

Quoted text here. Click to load it

Indeed there are, but I would never employ anyone who had majored in CS on
an embedded project.

Quoted text here. Click to load it

This is a good thing.  When the Polys first converted there were still huge
gaps between them and the red bricks.  it is a pity that after such a long
period that the gap has not narrowed more.  I don't mine where good
candidates come from.

Quoted text here. Click to load it

There has always been a (well known) hierarchy amongst the red bricks for
Electronics.  These have not changed significantly in 20 years.

Quoted text here. Click to load it

I did not mean to imply picking people because of where they came from,
merely as a pre-qualifier, in the same way I would select upper seconds and
firsts for preference.

Ian

--
Ian Bell

Re: IEE or IEEE
Quoted text here. Click to load it

Again, depends on the course. There are some CS courses where anything
as "dirty" as implementation is looked upon with a degree of scorn,
others where anything that's not point'n'drool commercial software and
language-of-the-month isn't appreciated....

and on the other hand there are EE courses where "programming" is
taught, but with no underlying concept of "software engineering" -
"here's the assembler/C syntax, hack it together, you don't need
process" (I exaggerate only slightly....)

There are good and bad courses in both disciplines.

pete
--
snipped-for-privacy@fenelon.com "there's no room for enigmas in built-up areas"

Re: IEE or IEEE

Quoted text here. Click to load it

No argument about that.  However, it has been my experience that CS
graduates are generally less able than EE graduates when it comes to
embedded.

Ian

--
Ian Bell

Re: IEE or IEEE

Quoted text here. Click to load it

And also, on another branch of this thread:

wrote:

Quoted text here. Click to load it

...

Interesting points to read.  I prefer having as much overlap in skills for those
on a team as is possible.  I'll elaborate:

I started out as a mathematics and physics major and learned computer science
out of my need for calculating physical systems, but eventually made CS my own
profession because it paid the bills.  Electronics has been a hobby for quite
some time and I have acquired some understanding, though I certainly don't try
and offer my meager hobbyist electronics skills professionally.

But projects I work on involve optics, detector physics, electronics, fairly
sophisticated signal processing, numerical methods, as well as a variety of
software skills.  I am *not* usually responsible for designing the optics, but I
have had years of experience in both designing and building (by hand-grinding)
and testing optical system, so I can and do comment on the designs I see and
participate in them.  I am *not* usually responsible for selecting the detector,
but my understanding of physics does allow me to understand and participate in
that process, too.  I am somewhat fluent at reading the schematics, so I often
do make recommendations which do impact on resulting product design in helpful
ways.  My skills in mathematics mean that I can both develop and accept
mathematical ideas and use numerical methods to understand sources of error that
accrue from specific algorithm implementations or the use of floating point
notation, etc.

In short, it helps to understand the overall system and electronics and software
tradeoffs and to help think through various alternatives and also to catch the
mistakes others may make in an early and timely way.  

What makes this work better is that while I don't have the final responsibility
in the other areas, I do understand them and I do impact their design and I have
enough overlap of skills to not let things slip through the cracks, so to speak.
When a physicist writes a closed equation, I can use my knowledge of numerical
methods to generate a sequential algorithm that delivers what is intended --
often, the physicist has almost no idea about the vagaries and limitations of
programming issues and simply imagines that the calculations are always exact,
for example, and that constants are exact, as well (just by way of example) and
doesn't really understand how software can actually create errors and that these
errors can accumulate if they aren't understood and managed well.  Having an
overlap of skills is what helps keep these problems from arising in the first
place, when in highly partitioned skill sets these things can often "slip
through" and wind up in the final product.  Similar arguments may also apply to
why a software person needs to understand the hardware to some degree, as well.

I taught undergrad CS courses for a few years at the 2nd and 3rd year level at a
local university here.  Not a long experience, but there it is.  Class size was
around 55-65, or so.  Subjects included assembly languages, computer
architecture, operating systems, and concurrent programming.  In such classes,
I'd often have 5 or 6 students from the EE department -- about 10%.  In every
case, my experience is that these EE students would have almost zero problem
understanding my lectures and doing the work assigned.  By comparison, out of
the remaining 50-60 CS-only students, I'd have perhaps a slightly smaller number
(about 3 or 4) who were as fluent.  The rest required a fair amount of my office
time to help them think things through.

I don't mean to say that the lesson here is that EE folks are necessarily
brighter, but that being personally and eagerly interested in various technical
areas is a good thing.  My "sense" is that what Joerg said is about right --
though perhaps I'd broaden it a little -- having an abiding interest in all
things surrounding a project is key.  Someone who is narrowly focused on
remaining isolated and partitioned off as a "software person," in embedded work
where there are myriad important interactions, is a recipe for problems and
quite possibly failure.  You need many eyes watching out for problems and who
can bring their own unique viewpoints to bear and help make the resulting
product one born of an overall more comprehensive viewpoint.  Having people who
keep themselves into their own little functional boxes is often a bad thing in
embedded work.

But I'd be looking for this kind of interest in many areas together with the
ability to actually translate that interest into, at least, a skilled and
serious amateur understanding of these other areas.  Not simply excluding CS and
reaching for EE.  You can find these kinds of people from both areas, though
perhaps it may be argued that an EE is more likely to have broader technical
interests.  (On that last point, I wouldn't know.)

Jon

Re: IEE or IEEE
Quoted text here. Click to load it
those
science
own
quite
try
fairly
of
but I
hand-grinding)
Quoted text here. Click to load it
and
detector,
participate in
often
helpful
error that
point
software
the
responsibility
I have
speak.
numerical
intended --
Quoted text here. Click to load it
of
exact,
example) and
Quoted text here. Click to load it
these
an
first
apply to
well.
level at a
Quoted text here. Click to load it
size was
classes,
every
problem
of
number
office
technical
right --
Quoted text here. Click to load it
all
work
and
who
people who
thing in
the
CS and
though
technical

Very well said. My dad, who's an engineer and actually more into hardware
than software, knows by practice that understanding not only the hardware
(or not only the software) exclusively is real important because that makes
both design and implementation better, not to say that locating and fixing
problems is way easier when you're not limited to just one half of the
product. I, myself, as a former physics student (though I've shifted from
physics to CS), know about this importance from practice. And it is quite
the right kind of thing to be interested in may things, I mean, when you
have broader knowledge (often from several areas of science/engineering) you
can do more and better, you can invent unexpectedly (or just come to) good
solutions.
And yes, it's better for CS guys to know how the transistors work (and not
only them) which make up their CPUs, how to make custom ASIC to solve the
task that the CPU isn't able, etc etc. Beyond CS there's always math and
physics. Math is a must, physics is very much desired.
Btw, good business in IT requires knowledge of both the business itself and
the matter, the engineering stuff that's behind.

Alex



Re: IEE or IEEE

snip

Quoted text here. Click to load it

And not only that, it is a lot more *fun*.

Ian

--
Ian Bell

Re: IEE or IEEE
Hi Ian,

Quoted text here. Click to load it
What would be the reason? Embedded, as long as it contains the full dose
of hardware and failsafe structures, can be one of the hardest kinds of
projects one can encounter.

Sometimes when working on an embedded system I long back to earlier EMI
assignments. Even though EMI is usually nasty when they call me out and
I have to bite on my tongue to avoid inappropriate exclamations to come
out.

Regards, Joerg

http://www.analogconsultants.com

Re: IEE or IEEE

Quoted text here. Click to load it

They do not have a sufficient depth of understanding of hardware.

Ian
--
Ian Bell

Re: IEE or IEEE
Hi Ian,

Quoted text here. Click to load it
That is true, to some extent. But I found that working together with an
engineer who is interested in the hardware and myself being interested
in software we can build a nice product of high quality. Some of these
have now surpassed their 10th anniversary in production.

The minute you need to enter low power modes (like that ol' PCON
command) a mutual understanding of what each other's designs do is
essential.

Regards, Joerg

http://www.analogconsultants.com

Re: IEE or IEEE

Quoted text here. Click to load it

It is certainly project specific I agree. The vast majority of projects I
have been involved in (and recruited for) have for high volume cost
sensitive products where it is essential to squeeze every last ounce of
performance out of the software and hardware together.

Quoted text here. Click to load it

Indeed, in many of the designs I have been involved in, a very high degree
of innovation is necessary to achieve the cost/performance targets for
which a high level of knowledge outside your own specific discipline is
required (and can include disciplines other than just electronics and
software)..

Ian


--
Ian Bell

Re: IEE or IEEE
Hi Ian,

Quoted text here. Click to load it
That's why I used to present candidates with an actual or recent
problem. How would they go about it? Can they think holistic? Are they
willing to? In the case of SW folks I did sometimes ask them to come to
the lab with me and try to trigger a Tek scope on a signal from a
circuit or pulse generator. To be fair, HW engineers would be asked
about what an interrupt latency is.

Regards, Joerg

http://www.analogconsultants.com

Re: IEE or IEEE

Quoted text here. Click to load it

We recently took on another chap as a prototype wireman to assist with the
workload of geting a new experimental rig up and running in pretty sdhort
order. On Monday he said "you didn't ask about doing mechanics, cryogenics
and operating this stuff in the interview". True enough, but we had already
figured out that he was quite versatile fromk his CV and the interview.

For my part, as a Systems Engineer, I have certainly learned a lot about
High Energy Plasma Physics, Cryogenics, Low Temperature Measurements
techniques, behaviour of gases and liquid gases, and High vacuum pumping
systems to add to what I already knew of Motion Control Systems, Load and
Torque Measurements, Power Control, PLC programming, Forth Programming and
basic electronics.

Whoever expects engineering to be shoehorned into narrow confines had
better reconsider. The trick to being a good engineer is to be open to
learning new stuff continuously.

So, the people you look for need to exhibit this openess to continued
day-by-day learning, whatever way they come to you.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: IEE or IEEE

Quoted text here. Click to load it

Yup.  Nicely said.

Jon

Re: IEE or IEEE
<posted & mailed>


snip
Quoted text here. Click to load it

Exactly.

Ian

--
Ian Bell

Re: IEE or IEEE


Quoted text here. Click to load it

I got my BSEE in 1972. There have been very few changes since, with math,
circuit theory, and even electronics (in the context that I deal with). The
"practical" stuff we studied was pretty much centered around vacuum tubes.

I've had to learn a lot of new stuff, and that's what keeps it fun!

But even the vaccum tube stuff is of some use (repairing my guitar amp).

-Hershel Roberson

Re: IEE or IEEE

Quoted text here. Click to load it

I got my degree in 1973.  We were the first year to be taught transistors
instead of valves.   The lecturers were so inexperienced at this that they
taught us the Beta barrier method straight from the pages of the current
Wireless World.

Ian
--
Ian Bell

Site Timeline