Re: Programmers -> Engineers; Engineers -> Programmers

Re: Programmers -> Engineers; Engineers -> Programmers

[James A. Krzyzanowski]

James Krell (jkrell@nswc.navy.mil) wrote:
: Let's say an organization is developing software for a radar system...
: Is it better to take engineers/scientists who understand the system
: and teach them how to program?  Or is it better to take programmers
: and teach them about the radar system?

: Another example.. what if an organization is developing a command
: and control system? Is it better to take individuals who know the
: tactical and technical  aspects of the command and control system 
: and teach them how to program or is it better to take programmers 
: and teach them about the command and control system?

Sounds like AFATDS to me!  In my opinion, it is better to take "programmers"
and teach them about the command and control system.  That's what I did!

--
Not necessarily the opinion of the company...
--
---------------------------------------------------------------------------
         James A. Krzyzanowski - Senior Software Engineer - AFATDS
   Hughes Defense Communications * Fort Wayne, IN 46808 * (219) 429-6446
   ^^^ the company formerly known as Magnavox Electronic Systems Company
Internet: jakrzy@most.fw.hac.com * AOL: JimShiz@AOL.com * MOST: jakrzy@most
     "I'd rather be right than politically correct !!!" - Rush is Right
---------------------------------------------------------------------------

Re: Programmers -> Engineers; Engineers -> Programmers

[Ron Thompson]

jkrell@nswc.navy.mil (James Krell) wrote:
>Is it better to take engineers/scientists who understand the system Or is it better to take programmers
>and teach them about the radar system?
>
 Is it better to take individuals who know the
>tactical and technical  aspects of the command and control system 
>and teach them how to program or is it better to take programmers 
>and teach them about the command and control system?
>
>
>James Krell
>jkrell@nswc.navy.mil
>

Build a team, a team composed of both types plus the usual
management and budget and contracts and lawyers. Neither group
can grasp all of the other groups' concerns sufficiently.

If you made one group into the other, even temporarily, what
would you do to futures of either? Who needs Engineers when
we can just make the Programmers into them whenever we need
to?

A team of Engineers/Programmers can rely on one another to
accomplish the task. 

rct

The opinions above are mine and mine alone.

Re: Programmers -> Engineers; Engineers -> Programmers

[Mike Ryer]

There are many first-rate programmers who have a general scientific education
and the interest and quickness to learn a lot about radar -- just don't let
them design your antennas.  There are many first-rate electronic engineers
who have the patience and flexibility to learn programming -- just don't let
them code your flight control system.

An electrical engineer can learn on his/her own how to program, but it takes
working in a team within an established software engineering culture to really
learn about maintainability, robustness, configuration management, defensive
programming, realtime constraints, etc.  (A succession of hard knocks will
also work, though this is tough on the first few projects).

A good programmer or software engineer should be able to find ambiguities and 
contradictions in the requirements document written by a radar designer, think
of boundary conditions and unusual scenarios, design for efficiency on 
processing the kinds on input that actually occur in practice, etc.  In 
other words, if they're good, they will have insight into the physics, 
electronics, and mechanics of the system.

A successful project wants software engineers who understand the underlying
science, and radar designers who understand software.  At least a few of each.
Maybe you'll find a superman who does quantum mechanics in his head *and*
writes code that's easy for other people to understand.  (I haven't).

To the extent that you don't have the excellent electronic and software
engineers who learn enough about each other's fields, you need communicators,
reviewers, requirements testers as well as code testers (note Arianne 5
story), and a lot of extra time.

So the summary is:  
  Q: Is it better to take engineers/scientists who understand the system
     and teach them how to program?  Or is it better to take programmers
     and teach them about the radar system?
  A: No.

Mike Ryer, speaking for himself, employed by Intermetrics.

Re: Programmers -> Engineers; Engineers -> Programmers

[Kevin J. Weise]

jkrell@nswc.navy.mil (James Krell) wrote:
>Let's say an organization is developing software for a radar system...
>Is it better to take engineers/scientists who understand the system
>and teach them how to program?  Or is it better to take programmers
>and teach them about the radar system?
>
>Another example.. what if an organization is developing a command
>and control system? Is it better to take individuals who know the
>tactical and technical  aspects of the command and control system 
>and teach them how to program or is it better to take programmers 
>and teach them about the command and control system?
>
Presuming this is an honest, albeit simplistic, query (as opposed to a 
troll)...

I don't have any realistic, hard statistics, but...

It has been my experience that most companies will take engineers and 
make them do programming.  Some like it, some don't.  I've worked for a 
few companies like this and hated having to clean up the software 
messes left by the engineers (many of whom get *very* uptight that 
anyone would question their bizarre architectures and coding 
practices).  Many engineers (primarily those who give a damn), after 
living on a serious software project, pick up good software development 
practices from good software developers(if they are around) and good 
literature (if they are motivated to look for it).  Conversely, many 
good software developers can pick up the needed background in an 
engineering field (if they give a damn, if they have an associate who 
knows the field, if they are motivated,...).  *BUT*, with management 
usually coming from the engineering ranks, a software developer who 
does a poor engineering job is almost always blamed/punished/rejected 
whereas an engineer who does a poor software job is rarely noticed.  
(Probably because those same managers can't determine if the software 
job was good or not.) (I guess if this was a troll, I fell right in.)

Anyhow, IMHO, you need both.  If you can get people with good, solid 
backgrounds in both the desired engineering field and in software 
engineering, that's great.  If you can't, but can settle for being a 
CMM Level 1 organization, go for the engineers.  But, then again, if 
you need multiple engineers, you really should consider the software 
part an engineering field as well, and get some software *engineers* 
(i.e., don't settle for merely code-slingers).

---------------------------------------------------------------
Kevin J. Weise               email:  kweise@sed.redstone.army.mil
COLSA Corp.                  voice:  (205) 842-9083
Huntsville, AL

..standard disclaimers apply

Programmers -> Engineers; Engineers -> Programmers

[James Krell]

Let's say an organization is developing software for a radar system...
Is it better to take engineers/scientists who understand the system
and teach them how to program?  Or is it better to take programmers
and teach them about the radar system?

Another example.. what if an organization is developing a command
and control system? Is it better to take individuals who know the
tactical and technical  aspects of the command and control system 
and teach them how to program or is it better to take programmers 
and teach them about the command and control system?


James Krell
jkrell@nswc.navy.mil

Re: Programmers -> Engineers; Engineers -> Programmers

[Bob Kitzberger]

James Krell (jkrell@nswc.navy.mil) wrote:
: Let's say an organization is developing software for a radar system...
: Is it better to take engineers/scientists who understand the system
: and teach them how to program?  Or is it better to take programmers
: and teach them about the radar system?

Hopefully it isn't an either-or proposition.  You should do both,
to some degree.  For a large system, you also need system architects,
and software architects, not just programmers.  IMHO.


--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html

Re: Programmers -> Engineers; Engineers -> Programmers

[steved]

James Krell writes:
>Let's say an organization is developing software for a radar system...
>Is it better to take engineers/scientists who understand the system
>and teach them how to program?  Or is it better to take programmers
>and teach them about the radar system?
>
>Another example.. what if an organization is developing a command
>and control system? Is it better to take individuals who know the
>tactical and technical  aspects of the command and control system 
>and teach them how to program or is it better to take programmers 
>and teach them about the command and control system?
>
Opinion:

I hope the use of plural for programmers and engineers is intentional.  The
best answer is of course to get a mix of individuals on a team.  Let those
who are strong in software map out the software design.  Those that are
knowledgable about the problem offer guidance and work with the
programmers.

Experience:
Personally I am a programmer type, so there's my bias.  I can say from
experience that I have had to bat cleanup a number of times on programs
that were started by engineers trained in other disciplines.

By the same token, I have also had to bat cleanup for programs written by
people trained for the software profession.  So where does that leave you?

I have found that it depends very much on the individual.  But as I said in
my opening "opinion", the best is to get a mix, but I think you should lean
toward the software expert for doing software.

Steve Doiel

Re: Programmers -> Engineers; Engineers -> Programmers

[whiting_ms@corning.com (Matt Whiting)]

In article <Dvu0Jr.Esx.0.-s@inmet.camb.inmet.com>, ryer@harp.camb.inmet.com (Mike Ryer) writes:
> There are many first-rate programmers who have a general scientific education
> and the interest and quickness to learn a lot about radar -- just don't let
> them design your antennas.  There are many first-rate electronic engineers
> who have the patience and flexibility to learn programming -- just don't let
> them code your flight control system.
> 
> An electrical engineer can learn on his/her own how to program, but it takes
> working in a team within an established software engineering culture to really
> learn about maintainability, robustness, configuration management, defensive
> programming, realtime constraints, etc.  (A succession of hard knocks will
> also work, though this is tough on the first few projects).
> 
> A good programmer or software engineer should be able to find ambiguities and 
> contradictions in the requirements document written by a radar designer, think
> of boundary conditions and unusual scenarios, design for efficiency on 
> processing the kinds on input that actually occur in practice, etc.  In 
> other words, if they're good, they will have insight into the physics, 
> electronics, and mechanics of the system.
> 
> A successful project wants software engineers who understand the underlying
> science, and radar designers who understand software.  At least a few of each.
> Maybe you'll find a superman who does quantum mechanics in his head *and*
> writes code that's easy for other people to understand.  (I haven't).
> 
> To the extent that you don't have the excellent electronic and software
> engineers who learn enough about each other's fields, you need communicators,
> reviewers, requirements testers as well as code testers (note Arianne 5
> story), and a lot of extra time.
> 
> So the summary is:  
>   Q: Is it better to take engineers/scientists who understand the system
>      and teach them how to program?  Or is it better to take programmers
>      and teach them about the radar system?
>   A: No.
> 
-- 

And I planned to answer, YES.

---------------------------------------------------------------------------
Matthew S. Whiting, P.E.   | PP-ASEL-IA | All opinions expressed herein are
Corning Incorporated       | C-182K/A   | strictly personal.
whiting_ms@corning.com     |            |

Re: Programmers -> Engineers; Engineers -> Programmers

[Andy Askey]

Kevin J. Weise wrote:
> 
> 
> I don't have any realistic, hard statistics, but...
> 
> It has been my experience that most companies will take engineers and
> make them do programming.  Some like it, some don't.  I've worked for a
> few companies like this and hated having to clean up the software
> messes left by the engineers (many of whom get *very* uptight that
> anyone would question their bizarre architectures and coding
> practices).  Many engineers (primarily those who give a damn), after
> living on a serious software project, pick up good software development
> practices from good software developers(if they are around) and good
> literature (if they are motivated to look for it).  Conversely, many
> good software developers can pick up the needed background in an
> engineering field (if they give a damn, if they have an associate who
> knows the field, if they are motivated,...).  *BUT*, with management
> usually coming from the engineering ranks, a software developer who
> does a poor engineering job is almost always blamed/punished/rejected
> whereas an engineer who does a poor software job is rarely noticed.
> (Probably because those same managers can't determine if the software
> job was good or not.) (I guess if this was a troll, I fell right in.)
> 
> Anyhow, IMHO, you need both.  If you can get people with good, solid
> backgrounds in both the desired engineering field and in software
> engineering, that's great.  If you can't, but can settle for being a
> CMM Level 1 organization, go for the engineers.  But, then again, if
> you need multiple engineers, you really should consider the software
> part an engineering field as well, and get some software *engineers*
> (i.e., don't settle for merely code-slingers).
> 
> ---------------------------------------------------------------
> Kevin J. Weise               email:  kweise@sed.redstone.army.mil
> COLSA Corp.                  voice:  (205) 842-9083
> Huntsville, AL
> 
> ..standard disclaimers apply


Gee Kevin,

I agree with everything you said except the part of management usually
coming from the engineering ranks.  I have found the biggest problem is
that the managers tend to have neither a programming or engineering
background.  Most have a management background which usually allows them
to screw up everyone and everything involved.

-- 
May your karma be good for forgiving my typos.
Andy Askey

Re: Programmers -> Engineers; Engineers -> Programmers

[Andy Askey]

jkrell@nswc.navy.mil (James Krell) wrote:

>Let's say an organization is developing software for a radar system...
>Is it better to take engineers/scientists who understand the system
>and teach them how to program?  Or is it better to take programmers
>and teach them about the radar system?

>Another example.. what if an organization is developing a command
>and control system? Is it better to take individuals who know the
>tactical and technical  aspects of the command and control system 
>and teach them how to program or is it better to take programmers 
>and teach them about the command and control system?


>James Krell
>jkrell@nswc.navy.mil


I have worked on tasks similar to your examples for the pasted 4
years.  Here are my observations:

1)  Don't hire more than a small number that are clearly a distinct
member of one group or another.  For example, if you have 20 people in
the group, don't hire more than 2 that say they are radar gurus and
are not excited about software.  And don't hire more than 2 software
people who could care less about radar.

When choosing these four people make sure that they are head and
shoulders above the rest of the team in their respective areas and can
give results in hours or days and not in weeks.  It does no good to
hire a pretty good programmer who is not interested in radar.  Only
hire a great programmer cuz the other 16 people in your group will
collectively easily exceed any benefits a pretty good programmer will
bring to the project.  And don't hire a pretty good radar engineer for
the same reason.  If you can't find an expert, don't waste your time.


2)  Hire recent college graduates when possible.  Many times employers
search for that perfect person to fit a specific hole and end up with
someone who is pretty good at the time but is not very useful in a
year when the situation changes.  Recent graduates have not been
corrupted by the system and will do anything you ask them to do.  If
you need a programmer that knows radar, a recent graduate will easily
pick up both cuz he/she hasn't learn to do any different.

For you aging vets with a bunch of experience who disagree and think
that you should be given concideration over a new college kid I have a
question.  Do you fit into the category of "expert" in your field?  If
so, you will always have a job.  You will always be hired for one of
those "expert slots".  And if you have been working for say ten years
and are a pretty good engineer but not someone who is one of the
"best", and not someone who is particularly interested in software, I
have another question.
WHAT THE HELL HAVE YOU BEEN DOING FOR THE PAST 10 YEARS? 


3)  Hire based on the interview and not on previous job history.  I
have found that many people kick around the industry for 10 years,
never really accomplishing anything except to conpile a long list of
projects to add to their resume.  Some awfully average people have
some awsome looking resumes.  This probably does not apply to recent
college graduates.

Set up the interview to determine what the candidate can add to your
task and not what the candidate did on the last task.  I recommend
sending a small packet to the candidate discribing the job before the
interview or schedule the interview in 2 parts.  Part 1 the employer
tells the employee about the job and all the BS background history can
be covered.  Part 2 (on another day), the employee presents a briefing
on the benefits of hiring him/her.

At this point you can determine if you have someone who understands
the software/hardware interactions in the radar.  This is not the
traditional way people are hired in this industry but if you think
about it a second, it makes a lot of sense (at least to me).  You are
merely testing the candidate to see if he/she can do the day 1 work
before he/she is hired.  You will be amazed at the number of BS'er you
will weed out with this process.

4)  Make sure the leads of your core group are impressed with the
candidate after the interview.  Unless you are hiring the "expert"
candidate you need to make sure your  pretty good software people and
radar people both are impressed.

5)  HIRE GOOD PEOPLE.  Don't pigeon hole candidates.  Just find a
smart and ambitious person and hire them.  A smart, ambitious employee
can do most anything.


--
May your karma be excellent for forgiving my spelling mishaps.

Andy Askey
ajaskey@gnn.com

Re: Programmers -> Engineers; Engineers -> Programmers

[David Weller]

In article <320CB7C4.53FE@gnn.com>, Andy Askey  <ajaskey@gnn.com> wrote:
>Kevin J. Weise wrote:
>background.  Most have a management background which usually allows them
>to screw up everyone and everything involved.
>
>

Which is why Scott Adams is laughing all the way to the bank while we
laugh over his latest book, The Dilbert Principle.  

I created a corrolary to the Dilbert Principle called the Dilbert
Factor, which is a scale based on the percentage of Dilbert cartoons
that apply to your workplace:

	100-90%		Forget about giving two weeks notice.  Leave Now!

	90-80%		Give two weeks notice, but explain you must take 
			vacation for the last two weeks because "The voices 
			told me to clean my entire gun collection"
			Because most managers are direct descendants
			of primates, they will undoubtedly consider
			this a threat and have some sweaty security
			guy escort you out of the building.  At this
			point, tell your manager you don't want to
			take vacation, but you just need to go home
			for an hour.  They will give you the two weeks
			free.  For bonus points, recite bad Vogon poetry
			to the security guard as he's walking you
			out.

	80-70%		You are undoubtedly wondering what to do.  You
			feel like a caged animal.  Don't worry, look
			around.  Did you know that the Slobovian word
			for "animal pen" is "Cubicle"?  If your
			Dilbert Factor is this high, you're probably
			working for an aerospace company, from which
			there is no escape.

	70-60%		This one is tricky, because everybody _thinks_
			this is where they are at.  You could change
			jobs, but if you're still planning on staying
			in your career field, you'll only succeed in
			changing faces, not your Dilbert Factor.  Have
			you considered becoming a televangelist? Also
			remember:  Managerial intelligence, which some
			claim is an oxymoron, is scientifically proven
			to be a constant.  Managerial population,
			sadly, is increasing.  You are doomed to watch
			your Dilbert Factor increase.  Give up.

	60-50%		Rejoice!  Have a donut!  If you're aspiring to
			become a manager, however, now is a good time
			to head up a "Wellness Committee" or "Quality
			Circle".

	50-0%		Stop lying!  You're either working at home as
			an overpriced consultant (in which case, I
			want to know your secret!), or you're already
			a manager saying, "I don't do those things to
			my employees" (of course, the fact that you're
			reading this is probably entirely accidental,
			but that's beside the point...get back to work
			on that "rightsizing" report or you won't get
			this quarter's bonus!)

In retrospect, the scale could probably be bigger, but since I don't
get paid by the word like Scott, and since my third Whiskey and Coke
is sapping my creative juices, I'll just close with this comment: Am I
off-topic?

-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada

Re: Programmers -> Engineers; Engineers -> Programmers

[Jon S Anthony]

In article <4uiuna$4ut@dfw.dfw.net> dweller@dfw.net (David Weller) writes:

> 	50-0%		Stop lying!  You're either working at home as
> 			an overpriced consultant (in which case, I
> 			want to know your secret!), or you're already
> 			a manager saying, "I don't do those things to
> 			my employees" (of course, the fact that you're
> 			reading this is probably entirely accidental,

You missed one: You and a few other reasonably sane types start your
own company.  Of course, in this case you may still have to "hit the
street" despite being happy about your "Dilbert Factor".  Also, it is
likely that over time, if you _are_ successful, your Dilbert Factor
will go up and at the end of the day you will still be screwed.
Still, by then, you may be lucky enough to leave and never have to
think about this stuff ever again (fingers crossed!!)


> In retrospect, the scale could probably be bigger, but since I don't
> get paid by the word like Scott, and since my third Whiskey and Coke
> is sapping my creative juices, I'll just close with this comment: Am I
> off-topic?

In the current devolution of the internet, and news in particular, nothing
can possibly be off topic anywhere...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Programmers -> Engineers; Engineers -> Programmers

[Kevin J. Weise]

jscheibl@mason2.gmu.edu (Jack W Scheible) wrote:
>In _my_ experience, people who major in Computer Science tend to be
>dullards; if they were not, they would have majored in EE.
>
That's cosmic.  Half the Computer Science people at my alma mater 
*were* EEs.  Of course, that was nearly 20 years ago, & the CS dep't 
only offered graduate degrees.

>There is nary an engineering curriculum in the country that does not
>require programming, and nary a Computer Science curriculum that
>requires engineering classes.
>
True enough.  But those EEs who stayed EEs were the same ones who 
were the die-hard FORTRAN fans & who used every perverse trick in the 
book.  It was rarely for "optimization", it was usually 
one-upsmanship.  Boy howdy!  Now that's software! :-)

---------------------------------------------------------------
Kevin J. Weise               email:  kweise@sed.redstone.army.mil
COLSA Corp.                  voice:  (205) 842-9083
Huntsville, AL

.standard disclaimers apply

Re: Programmers -> Engineers; Engineers -> Programmers

[Jack W Scheible]

In _my_ experience, people who major in Computer Science tend to be
dullards; if they were not, they would have majored in EE.

There is nary an engineering curriculum in the country that does not
require programming, and nary a Computer Science curriculum that
requires engineering classes.

-jack

In article <4udri5$dmv@michp1.redstone.army.mil> "Kevin J. Weise" <kweise@c3i-ccmail.sed.redstone.army.mil> writes:
>I don't have any realistic, hard statistics, but...
>
>It has been my experience that most companies will take engineers and 
>make them do programming.  Some like it, some don't.  I've worked for 
>a few companies like this and hated having to clean up the software 
>messes left by the engineers (many of whom get *very* uptight that 
>anyone would question their bizarre architectures and coding 
>practices).  Many engineers (primarily those who give a damn), after 
>living on a serious software project, pick up good software development 
>practices from good software developers(if they are around) and good 
>literature (if they are motivated to look for it).  Conversely, many 
>good software developers can pick up the needed background in an 
>engineering field (if they give a damn, if they have an associate who 
>knows the field, if they are motivated,...).  *BUT*, with management 
>usually coming from the engineering ranks, a software developer who 
>does a poor engineering job is almost always blamed/punished/rejected 
>whereas an engineer who does a poor software job is rarely noticed.  
>(Probably because those same managers can't determine if the software 
>job was good or not.) (I guess if this was a troll, I fell right in.)
>
>Anyhow, IMHO, you need both.  If you can get people with good, solid 
>backgrounds in both the desired engineering field and in software 
>engineering, that's great.  If you can't, but can settle for being a 
>CMM Level 1 organization, go for the engineers.  But, then again, if 
>you need multiple engineers, you really should consider the software 
>part an engineering field as well, and get some software *engineers* 
>(i.e., don't settle for merely code-slingers).
>
>---------------------------------------------------------------
>Kevin J. Weise               email:  kweise@sed.redstone.army.mil
>COLSA Corp.                  voice:  (205) 842-9083
>Huntsville, AL
>
>..standard disclaimers apply
>
>

Re: Programmers -> Engineers; Engineers -> Programmers

[John Gluth]

In article <4uo6ch$s3v@portal.gmu.edu> Jack W Scheible,
jscheibl@mason2.gmu.edu writes:
>In _my_ experience, people who major in Computer Science tend to be
>dullards; if they were not, they would have majored in EE.

Come on, Jack!  Tell us what you really think!  ;-)

John (an EE, doing software)

Re: Programmers -> Engineers; Engineers -> Programmers

[Frank Manning]

In article <4uic1j$fg0@news-e2d.gnn.com> ajaskey@gnn.com (Andy Askey)
writes:

>       [...]
> 3)  Hire based on the interview and not on previous job history.  I
> have found that many people kick around the industry for 10 years,
> never really accomplishing anything except to conpile a long list of
> projects to add to their resume.  Some awfully average people have
> some awsome looking resumes.  [...]  

Sounds like good advice to me. One question, though -- how do you decide
who to interview, if you can't rely on resumes, which are mostly job
histories? Especially if you're hiring an Ada programmer (to make this
thread somewhat relevant to cla)?

-- Frank Manning
-- Chair, AIAA-Tucson Section

Re: Programmers -> Engineers; Engineers -> Programmers

[Robin P. Reagan]

Jack W Scheible wrote:
> 
> There is nary an engineering curriculum in the country that does not
> require programming, and nary a Computer Science curriculum that
> requires engineering classes.
> 

The reason that most schools don't require CS majors to take Engineering classes is that
Engineering is only one of many areas that CS people have open to them! vertually every
profession you can think of has been or will be touch by computers (and programmers)! You don't
need to understand fluid mechanics to write a financial analysis (yuck ptttt ptttt...) program.
The reverse can't be said about Engineering, Virtually every aspect of Engineering is associated
in some way with computers.

The school I attended left enough free credits open to the CS(BS) student to get a minor. I used
mine for Physics, some used theirs for Math or Bussiness (Even though my school offered a CS(BA)
for bussiness) I guess they prefered the BS over the BA.

Robin,    a SE doing SW (How about that  :-)
-- 
+---------------------------*LL&P*------------------------------+
| Robin P. Reagan          | Lockheed Martin Astronautics       |
| krreagan@msn.com         | P.O.Box 179                        |
|                          | Denver, Colorado                   |
| "My Mind is My Own..."   | rreagan@ast.lmco.com - 303.977.9483|
+---------------------------------------------------------------+

Re: Programmers -> Engineers; Engineers -> Programmers

[Marin David Condic, 407.796.8997, M/S 731-93]

Jack W Scheible <jscheibl@MASON2.GMU.EDU> writes:
>In _my_ experience, people who major in Computer Science tend to be
>dullards; if they were not, they would have majored in EE.
>
    Slow and sullen though we may be, at least our mothers managed to
    teach us proper manners. Do all EE curricula contain a course in
    "Rude and Offensive Behavior, 101?"

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        407.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "They that can give up essential liberty to obtain a little
    temporary safety deserve neither liberty nor safety."

        --  B. Franklin
===============================================================================

Re: Programmers -> Engineers; Engineers -> Programmers

[Marin David Condic, 407.796.8997, M/S 731-93]

James Krell <jkrell@NSWC.NAVY.MIL> writes:
>Let's say an organization is developing software for a radar system...
>Is it better to take engineers/scientists who understand the system
>and teach them how to program?  Or is it better to take programmers
>and teach them about the radar system?
>

    My experience has been that you generally need a little bit of
    both. The hypothetical radar system is going to need "application"
    oriented software and it's going to need "system" oriented
    software. Taking a radar expert and training him/her as an
    "application" programmer can be useful. But you're probably
    wasting time training them on all the ins/outs of system level
    programming - and hence the value of the computer scientist.

    Often, you have the domain specialists acting as analysts and the
    computer geeks translating this into design. This works well as
    long as both sides are reasonably good at communicating. Maybe
    companies would be better off hiring some of both and training
    them all in communication skills?

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        407.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "They that can give up essential liberty to obtain a little
    temporary safety deserve neither liberty nor safety."

        --  B. Franklin
===============================================================================

Re: Programmers -> Engineers; Engineers -> Programmers

[Jack W Scheible]

In article <Dw6wKp.BEG@most.fw.hac.com> jakrzy@ss2.magec.com (James A. Krzyzanowski) writes:
>Jack W Scheible (jscheibl@mason2.gmu.edu) wrote:
>: In _my_ experience, people who major in Computer Science tend to be
>: dullards; if they were not, they would have majored in EE.
>
>Unbelievable!
>
>When will people learn they can't make such generalizations?
>
>I looked up the exact definition of dullard - one that is stupid,
>unimaginative, or insensitive.

I misspoke.  I should have said, "Most of the CS majors I have
met are dullards; many wanted to be EE majors but were not
admitted to the program, and others failed out of EE."
(Those that failed out of CS became business majors.)

>I think it would be pretty tough to get through CS if you're stupid. 
>How can a CS person ever design a program if he were unimaginative?

All adjectives are relative.

>Insensitive?  Maybe some, but not most.

The dictionary used the conjunction "or," not "and."
>
>BTW - my degree is in Mathematics!

My minor was also in Mathematics.

-jack

Re: Programmers -> Engineers; Engineers -> Programmers

[James A. Krzyzanowski]

Jack W Scheible (jscheibl@mason2.gmu.edu) wrote:
: In _my_ experience, people who major in Computer Science tend to be
: dullards; if they were not, they would have majored in EE.

Unbelievable!

When will people learn they can't make such generalizations?

I looked up the exact definition of dullard - one that is stupid,
unimaginative, or insensitive.

I think it would be pretty tough to get through CS if you're stupid.  How
can a CS person ever design a program if he were unimaginative?
Insensitive?  Maybe some, but not most.

BTW - my degree is in Mathematics!

--
Not necessarily the opinion of the company...
--
---------------------------------------------------------------------------
         James A. Krzyzanowski - Senior Software Engineer - AFATDS
   Hughes Defense Communications * Fort Wayne, IN 46808 * (219) 429-6446
   ^^^ the company formerly known as Magnavox Electronic Systems Company
Internet: jakrzy@most.fw.hac.com * AOL: JimShiz@AOL.com * MOST: jakrzy@most
     "I'd rather be right than politically correct !!!" - Rush is Right
---------------------------------------------------------------------------

Re: Programmers -> Engineers; Engineers -> Programmers

[Dale Stanbrough]

Jack W Scheible writes:

"In _my_ experience, people who major in Computer Science tend to be
 dullards; if they were not, they would have majored in EE.
 
 There is nary an engineering curriculum in the country that does not
 require programming, and nary a Computer Science curriculum that
 requires engineering classes."

Probably flame bait, but here goes. 

The presumption that the contents of an entire discipline can be learnt
as an adjuct to another course in a "by the way, here's how to program"
manner is rather amazing.
Students in our double degree computer science/computer systems engineering
course are _not_ dullards. They often remark on how much better the
programming
information is from computer science.
Similarly the manufacturing systems engineering students who are based on
the same campus as me, comment on how lacking some of their computing 
experiences have been (they are not taught by us).

Jack's "in _my_ experience" reminds me of "i've never been so insulted!",
"you should get out more". Jack, you really need to get out more.


Dale

Re: Programmers -> Engineers; Engineers -> Programmers

[Brendan WALKER]

In article <4uic1j$fg0@news-e2d.gnn.com>, Andy Askey <ajaskey@gnn.com> wrote:
>
>I have worked on tasks similar to your examples for the pasted 4
>years.  Here are my observations:
>
>1)  Don't hire more than a small number that are clearly a distinct
>member of one group or another.  For example, if you have 20 people in
>the group, don't hire more than 2 that say they are radar gurus and
>are not excited about software.  And don't hire more than 2 software
>people who could care less about radar.
 
  [snip]

I agree in part with this. Certainly you only need a very small number
of "problem domain" experts, however if the project is primarily a
software development effort then the rest of the staff should be the most 
compentant "solution domain" experts that you can find. In this case,
solution domain means skills on the design methodolgies, languages,
operating systems, documentation and testing standards, etc, that your
project is using! That is, well rounded, highly skilled and experienced
Software Engineers (doesn't matter whether their degree is in science or
engineering really, what matters is how they've learnt to apply their
skills in the real-world).

>2)  Hire recent college graduates when possible. [snip] ..........

This is in my experience down here in Australia the worst mistake that
can be made. I have seen projects fail abysmally due to the company
trying to "save money" by hiring far too many in-experienced new graduates.

The problem occurs because the Universities/Colleges don't really teach
the practical Software Engineering skills that can currently only really
be learned on the job. Things such as how a good S/W CM system works, how
to test S/W practically and effectively, the importance of documented 
processes and procedures, how to communicate effectively with other
organsisations and team members, how to lead professional teams, 
etc, etc, etc........ 

>For you aging vets with a bunch of experience who disagree and think
>that you should be given concideration over a new college kid I have a
>question.  Do you fit into the category of "expert" in your field?

I am not quite an aging vet, but 5 years out of Uni and another 5 years
working in the industry while studying in the first place I think puts me
way beyond the graduate status! 

> If so, you will always have a job.  You will always be hired for one of
>those "expert slots".  And if you have been working for say ten years
>and are a pretty good engineer but not someone who is one of the
>"best", and not someone who is particularly interested in software, I
>have another question.
>WHAT THE HELL HAVE YOU BEEN DOING FOR THE PAST 10 YEARS? 

Don't know what they've been doing, but I can tell you that most of these
people are probably managers!


>3)  Hire based on the interview and not on previous job history.  I

  [snip]

>5)  HIRE GOOD PEOPLE.  Don't pigeon hole candidates.  Just find a
>smart and ambitious person and hire them.  A smart, ambitious employee
>can do most anything.

This stuff makes general sense, especially this last bit. To add, a smart
ambitious, highly skilled and experienced employee can do ABSOLUTELY
anything!

Best Regards,


-- 
Brendan Walker	        | The opinions expressed above are obviously
IASSF Project, 	        | the ramblings of a troubled mind, and 
GMS S3I (Australia)     | therefore not those of my employer.

Re: Programmers -> Engineers; Engineers -> Programmers

[Mike Roske]

Robin P. Reagan wrote:
> The school I attended left enough free credits open to the CS(BS) student to get a minor. I used
> mine for Physics, some used theirs for Math or Bussiness (Even though my school offered a CS(BA)
> for bussiness) I guess they prefered the BS over the BA.
> 
> Robin,    a SE doing SW (How about that  :-)
> --

Ditto the school I attended.  Many folks (myself included) used them
for Math, using the knowledge for learning logical thought and problem
solving.  Not that those skills would be useful in engineering ;-)

2 more cents, from a SW weenie who can actually read a HW schematic and
use it to find out what the hardware is REALLY doing when it's not
working to the interface document.  (not that that ever happens ;-)  )



-- 
*-------------------------------------------------------*
* Michael Roske
* Sanders, A Lockheed Martin Company
* mroske@mailgw.sanders.lockheed.com
* (603) 885-9240
*-------------------------------------------------------*
* This space left blank	          This space right blank*
*-------------------------------------------------------*

Re: Programmers -> Engineers; Engineers -> Programmers

[Alan Brain]

jscheibl@mason2.gmu.edu (Jack W Scheible) wrote:

>In _my_ experience, people who major in Computer Science tend to be
>dullards; if they were not, they would have majored in EE.

>There is nary an engineering curriculum in the country that does not
>require programming, and nary a Computer Science curriculum that
>requires engineering classes.

I admit that in the Dark Ages of 1977, I thought EE majors were masochists. 2nd 
year Pure/Applied Maths, Computer Science and Honours Physics took over 58 hrs/week 
of tutes and lectures, plus 40 or more of assignments (for me, anyway). But Elec Eng 
had 106 hrs/week without assignments. Sheesh!

Of course, the fact that of the 1200 entrants into Comp Sci first year, only 36 
could go onto 3rd year did make the course fairly tough. Pass marks were adjusted 
until enough students failed.

Sample Prac Question (Computer Science):

"Here is the instruction set for a CPU. Design and Build one. (4 Hours)"

About 25% of the Comp Sci and Elec Eng courses were identical, with both streams of 
students in the same classes.

Actually, the above question wasn't that difficult: after the exam, I found that the 
instruction set was for a PDP-8, a very simple CPU indeed. In Physics, we'd learnt 
how to make transistors: In Comp Sci we were given transistors, and learnt how to 
make flip-flops: then we were given flip-flops on chips and learnt how to make ALUs, 
and so forth.

Regards, A.Brain BSc (Comp Sci) Sydney University 1976-81 

Re: Programmers -> Engineers; Engineers -> Programmers

[Jon S Anthony]

In article <STEPHENB.96Aug16095012@sorrol.harlqn.co.uk> stephenb@harlequin.co.uk (Stephen J Bevan) writes:

> Indeed.  I was told (admittedly by a physicist) that people who took
> EE were dullards; if they were, not they would have taken physics :-)
> 
> No doubt there is some group who thinks that physicists are dullards ... etc.

Ah, that would be us "pure" mathematicians.  Yep, I think the last few
replies here pretty much define the intellectual pecking order. :-)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Programmers -> Engineers; Engineers -> Programmers

[steved]

Jack W Scheible wrote:
>
>>In _my_ experience, people who major in Computer Science tend to be
>>dullards; if they were not, they would have majored in EE.
>
>>There is nary an engineering curriculum in the country that does not
>>require programming, and nary a Computer Science curriculum that
>>requires engineering classes.
>
Following the same logic, I had a Computer Science curriculum and took some
electronics courses.  Does this mean that I should do some electrical
engineering?

My experience has been (others may have different experiences) that people
with an EE background in Software, have programming skills, but little
knowledge of Software Engineering.  It is true that if you follow engineering
principles and apply them to software, you will succeed.  But I have seldom
seen this from EE's.

Steve Doiel

Re: Programmers -> Engineers; Engineers -> Programmers

[Stephen J Bevan]

In article <Dw6wKp.BEG@most.fw.hac.com> jakrzy@ss2.magec.com (James A. Krzyzanowski) writes:
   Jack W Scheible (jscheibl@mason2.gmu.edu) wrote:
   : In _my_ experience, people who major in Computer Science tend to be
   : dullards; if they were not, they would have majored in EE.

   Unbelievable!

Indeed.  I was told (admittedly by a physicist) that people who took
EE were dullards; if they were, not they would have taken physics :-)

No doubt there is some group who thinks that physicists are dullards ... etc.

Re: Programmers -> Engineers; Engineers -> Programmers

[Richard Riehle]

 Jack W Scheible <jscheibl@MASON2.GMU.EDU> writes:
>In _my_ experience, people who major in Computer Science tend to be
>dullards; if they were not, they would have majored in EE.

 Mr. Scheible is probably a little embarrassed upon reading how this
 looks after being posted.

 If I understand his underlying point, the need for engineering education
 as part of the computer science curriculum, it is hard to support an
 argument against that position. The notion that Computer Science
 students should take a principles of engineering class is worthy of
 serious consideration.

 Richard Riehle

Re: Programmers -> Engineers; Engineers -> Programmers

[Marin David Condic, 407.796.8997, M/S 731-93]

Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU> writes:
>In article <STEPHENB.96Aug16095012@sorrol.harlqn.co.uk>
>stephenb@harlequin.co.uk (Stephen J Bevan) writes:
>
>> Indeed.  I was told (admittedly by a physicist) that people who took
>> EE were dullards; if they were, not they would have taken physics :-)
>>
>> No doubt there is some group who thinks that physicists are dullards ... etc.
>
>Ah, that would be us "pure" mathematicians.  Yep, I think the last few
>replies here pretty much define the intellectual pecking order. :-)
>
    And then we have the "B-School" students who are *truly* at the
    top of the pecking order:

    "You <mathematicians> <physicists> <engineers> <computer-scientists>
    go to school for 4+ years and work hard at it in order to get out
    and get a job paying 5 figures. Whereas *I* go to school for 4+
    years and learn how to exploit & oppress <mathematicians>
    <physicists> <engineers> <computer-scientists> for fun and profit,
    draining their brains of all their marketable ideas and taking full
    credit for them, get paid 'The Long Green', ride in corporate
    jets, wear Armani suits, have a company car, get stock options and
    (in the event of incompetence) have a golden parachute promising
    me megabucks just for getting fired! BwaHaHaHaHaHaaaaa!"

    Now who are the *real* 'dullards' in this picture?

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        407.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "They that can give up essential liberty to obtain a little
    temporary safety deserve neither liberty nor safety."

        --  B. Franklin
===============================================================================

Re: Programmers -> Engineers; Engineers -> Programmers

[Thomas Kendelbacher]

In article <Pine.GSO.3.92.960819102006.27186B-100000@nunic.nu.edu>, Richard Riehle <rriehle@nunic.nu.edu> writes:
> If I understand his underlying point, the need for engineering education
> as part of the computer science curriculum, it is hard to support an
> argument against that position. The notion that Computer Science
> students should take a principles of engineering class is worthy of
> serious consideration.

FYI: In Germany, a basics course in EE has always been part of the standard
CS ("Informatik") curriculum, at least at the Technical University of Braunschweig
which I attended, but many others, too.  (At other universities, the courses are
sometimes called "Technische Informatik" with a stronger emphasis/specialization
on digital circuitry.)

At the TU Braunschweig, the 2-semester course covered "everything" from Ohm's Law,
complex resistor networks, Fourier/Laplace transformation, semiconductor theory,
electronic circuitry including AD/DA converters, up to digital circuitry, PLAs
etc.

Phew, it _was_ tough (including the exam.)  ;-)

Not that I need much of it in my daily work, but it was certainly a good
experience to gain some insight to an engineering discipline. Yes, I think
it can be recommended (maybe a bit less "bare-metal basics" and a bit more
"engineering", but some "basics" are required, of course!)

-- 
Thomas Kendelbacher   |   email : Thomas.Kendelbacher@erno.de
DASA RI / Abt. RIT14  |   voice : +49 421 539 5492 (working hours)
Postfach 28 61 56     |      or : +49 421 57 04 37 (any other time)
D-28361 Bremen        |     fax : +49 421 539 4529 (any time)
Germany

Re: Programmers -> Engineers; Engineers -> Programmers

[Jon S Anthony]

In article <96081917123470@psavax.pwfl.com> "Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM> writes:

> >Ah, that would be us "pure" mathematicians.  Yep, I think the last few
> >replies here pretty much define the intellectual pecking order. :-)
> >
>     And then we have the "B-School" students who are *truly* at the
>     top of the pecking order:

They are indeed at the top of _a_ pecking order.  It is not the
intellectual pecking order. :-)


>     and get a job paying 5 figures. Whereas *I* go to school for 4+
>     years and learn how to exploit & oppress <mathematicians>
>     <physicists> <engineers> <computer-scientists> for fun and profit,
>     draining their brains of all their marketable ideas and taking full
>     credit for them, get paid 'The Long Green', ride in corporate
>     jets, wear Armani suits, have a company car, get stock options and
>     (in the event of incompetence) have a golden parachute promising
>     me megabucks just for getting fired! BwaHaHaHaHaHaaaaa!"
> 
>     Now who are the *real* 'dullards' in this picture?

:-) :-)

Not "dullards".  Fools!


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Programmers -> Engineers; Engineers -> Programmers

[jtapa]

Richard Riehle wrote:
> 
>  Jack W Scheible <jscheibl@MASON2.GMU.EDU> writes:
> >In _my_ experience, people who major in Computer Science tend to be
> >dullards; if they were not, they would have majored in EE.
> 
>  Mr. Scheible is probably a little embarrassed upon reading how this
>  looks after being posted.
> 
>  If I understand his underlying point, the need for engineering education
>  as part of the computer science curriculum, it is hard to support an
>  argument against that position. The notion that Computer Science
>  students should take a principles of engineering class is worthy of
>  serious consideration.
> 
>  Richard Riehle

I agree whole heartedly, to many CS people are cheated out of the basics 
of engineering. My observations are that many (maybe more than half) 
software engineers do not have CS degrees. I know of more EEs, CEs, and 
MEs who are successful SW Engineers. Myself (EE) included. Let's face it, 
a technical degree gives you certain tools and trains you in how to use 
them for certain tasks. CS, EE, ME, CE and the like are all strong fields 
of study, certainly they differ but I think the different backgrounds in 
a SWEs education adds to a team's ability to solve difficult problems. 
ie, the ones none of us ever heard about in school.

I think the important thing to remember is "engineering" part of the 
software engineers job. When all is said and done, coding is the easy 
part. Coming up with a good design that will meet the requirements and 
schedule/budget restraints is where the magic lies.

JT Apa

Re: Programmers -> Engineers; Engineers -> Programmers

[Alan Brain]

jtapa@pacbell.net wrote:
> 
> Richard Riehle wrote:

> >  If I understand his underlying point, the need for engineering education
> >  as part of the computer science curriculum, it is hard to support an
> >  argument against that position. The notion that Computer Science
> >  students should take a principles of engineering class is worthy of
> >  serious consideration.
> >
> 
-->8---------
> I think the important thing to remember is "engineering" part of the
> software engineers job. When all is said and done, coding is the easy
> part. Coming up with a good design that will meet the requirements and
> schedule/budget restraints is where the magic lies.

Concur. 

Signed:
A.E.Brain (BSc) who's done B*** all Science, but a mass of Engineering
of Software and Systems since leaving Uni.

-- 

----------------------      <> <>       How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM  By pulling
---------------------- o OO*O^^^^O*OO o oo     oo oo     oo  Maerklin
Wagons
                                                             In 1/220
Scale