On Mon, 09 Jul 2012 20:21:55 -0500, John H. Guillory
wrote:

Engineers are known for knowing all the
knowladge to pass a test, yet not a single bit of real-world usage.

I are an engineer and I know which end of the soldering iron to grab.

Eg. An engineer can design the complete working schematic for a ham
radio, but when it comes to putting it together, he may have the
hardest time stripping the wires, soldering the connections, etc.

Nope. These daze, engineers do all their design work on a computah.
The design process is called direct to manufacturer. There is no hand
built prototype stage. They don't need to strip wires or solder
anything. Worst case is they might use a hot air SMT rework station
to replace a part, or fix a layout error. If it doesn't work right,
the engineer goes back to the computah simulations, fixes it, and has
the prototype shop robots build another revision. These are todays
engineers, not the cave man variety (like me) that had to build their
own prototypes, strip their own wires, and steal parts from production
to build prototypes. Those days are long gone, except maybe in garage
operations. Open a cell phone and tell my you can build it by hand
with your soldering iron and wire stripper.

But
gosh darn it, once it's completely together, and fired up.... The
engineer would then listen carefully and hear a distorted sounding
voice and insist that the antenna wasn't working to full potential,

Baloney. It's the marketing and sales guys that evaluate how
something sounds. Engineers use test equipment that measure how it
sounds, how well it works, and whether it complies with a multitude of
specifications. The numbers are far more sensitive to anomalies than
a talk test. On a rare day, there may actually be a talk test, but
that's unusual. Incidentally, you can see distortion on a scope long
before you can hear it.

while the newly licensed short order cook steps up and turns the
clarifier slightly and hears a much clearer voice, then tells the
Engineer "You go tune the antenna, while I make a connection to this
operator!"

What's a clarifier? Is that one of those things found on a CB radio?
--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Tue, 10 Jul 2012 02:03:29 -0000, wrote:
John H. Guillory wrote:
On Fri, 30 Apr 2010 22:37:58 -0500, tom
wrote:

You are really good, Art. How do you keep it up?

You make new and fresh nonsense up with very many of your
posts. Not
every one, but you do have to carry on your themes after all.

Still, it's quite an effort you put into it. How do you
continue to
make almost no sense? That's really tough. I mean, even
random chance
would say you occasionally have to be realistic.

tom
K0TAR

As an engineer can't afford to act on theories alone
only those that have already be established.
Not knowing anything about what the two of you are talking about,
just
gotta say one thing... Engineers are known for knowing all the
knowladge to pass a test, yet not a single bit of real-world
usage.
Eg. An engineer can design the complete working schematic for a
ham
radio, but when it comes to putting it together, he may have the
hardest time stripping the wires, soldering the connections, etc.
But
gosh darn it, once it's completely together, and fired up.... The
engineer would then listen carefully and hear a distorted sounding
voice and insist that the antenna wasn't working to full
potential,
while the newly licensed short order cook steps up and turns the
clarifier slightly and hears a much clearer voice, then tells the
Engineer "You go tune the antenna, while I make a connection to
this
operator!"


Most engineers are not technicians though a lot were a one time.


Do doctors usually know the best way to mop the floors in the
hospital?

Quite possibly, yes.

On Tue, 10 Jul 2012 02:03:29 -0000, wrote:

Do doctors usually know the best way to mop the floors in the hospital?

The 11th Dr Who knows how to use a mop.
http://www.toplessrobot.com/fez.png
http://www.flickr.com/photos/15265256@N03/5143518610/

--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Wayne wrote:
On Tue, 10 Jul 2012 02:03:29 -0000, wrote:

Do doctors usually know the best way to mop the floors in the
hospital?

Quite possibly, yes.

I highly doubt most doctors have any knowledge of the floor cleaning
products available on the market or their efficacious.

Jeff Liebermann wrote:
On Mon, 09 Jul 2012 20:21:55 -0500, John H. Guillory
wrote:

Engineers are known for knowing all the
knowladge to pass a test, yet not a single bit of real-world usage.

I are an engineer and I know which end of the soldering iron to grab.

Eg. An engineer can design the complete working schematic for a ham
radio, but when it comes to putting it together, he may have the
hardest time stripping the wires, soldering the connections, etc.

Nope. These daze, engineers do all their design work on a computah.
The design process is called direct to manufacturer. There is no hand
built prototype stage. They don't need to strip wires or solder
anything. Worst case is they might use a hot air SMT rework station
to replace a part, or fix a layout error. If it doesn't work right,
the engineer goes back to the computah simulations, fixes it, and has
the prototype shop robots build another revision. These are todays
engineers, not the cave man variety (like me) that had to build their
own prototypes, strip their own wires, and steal parts from production
to build prototypes. Those days are long gone, except maybe in garage
operations. Open a cell phone and tell my you can build it by hand
with your soldering iron and wire stripper.

Unless you were in a very small operation or talking about REALLY ancient
times, engineers as a general rule never did mundane tasks.

Those were left to other, lesser paid people, like technicians, draftsmen,
and typists.

No one in their right mind would pay an engineer to build and test a
prototype, draw up the formal schematics, or type up the documentation
when there are other people who could do that faster and at a much lower
hourly rate.


But
gosh darn it, once it's completely together, and fired up.... The
engineer would then listen carefully and hear a distorted sounding
voice and insist that the antenna wasn't working to full potential,

Baloney. It's the marketing and sales guys that evaluate how
something sounds. Engineers use test equipment that measure how it
sounds, how well it works, and whether it complies with a multitude of
specifications. The numbers are far more sensitive to anomalies than
a talk test. On a rare day, there may actually be a talk test, but
that's unusual. Incidentally, you can see distortion on a scope long
before you can hear it.

Most of the places I worked, the testing was done by techicians who
wrote up a test results report for the engineers and the engineers
only got involved if something was hinky in the test results.

On Wed, 11 Jul 2012 15:04:43 -0000, wrote:

Unless you were in a very small operation or talking about REALLY ancient
times, engineers as a general rule never did mundane tasks.

Those were left to other, lesser paid people, like technicians, draftsmen,
and typists.

No one in their right mind would pay an engineer to build and test a
prototype, draw up the formal schematics, or type up the documentation
when there are other people who could do that faster and at a much lower
hourly rate.

True for most companies, but not true for every place that I've
worked. One such small company made it a point of having the engineer
personally perform every step of the production cycle from incoming
inspection to shipping. At some point, I did incoming inspection
(QA), parts stuffing, wave soldering, lead trimming, final assembly,
cable harnesses, production test, QA test, burn-in setup, and
shipping. There was no attempt utilize expensive engineering talent
for these jobs. It was a very necessary learning experience that paid
off handsomely in improved efficiency. It's one thing to stand aside
and just watch someone do their job. It's quite another to actually
sit down and do it. For example, we had a small 3 turn coil that was
hand wound on a form. Production people could average about 5 coils
per hour, which stunk. I sat down for several hours, made numerous
changes, found numerous problems that nobody bothered to identify, and
was able to crank out about 40 coils per hour. However, my fingers
felt like they were going to fall off after about an hour. This
wasn't going to work. The experience was sufficient to justify the
design and construction of an automatic coil winder, that could do
about 200 coils per hour.

When I worked for larger companies, I did much the same thing. I
experienced some initial resistance but got the attention of
production by breaking a few rules, but which dramatically improved
efficiency. I arranged to have the drawings and assembly instructions
translated into several languages. While assemblers were expected to
know English, they were not proficient in technical English. From
then on, the suggestions and changes came quickly. Unfortunately, I
still had products to finish, but was allowed about 25% of my time to
do the production engineering function.

An engineer (or manager) that sits behind a computer, never leaves the
office, never sits on the production line, never understands how
things are built, and never has an understanding of anyone elses job,
will eventually make some rather nasty mistakes. Using engineering
talent for these functions is not a good idea for extended periods,
but is a good idea for the short periods needed to gain the necessary
experience.

Incidentally, in the distant past, one of my consulting jobs was
cleaning up the computerized RF board layouts produced by an
assortment of PCB designers, that didn't seem to understand that RF
travels in roughly straight lines, and that bypassing requires a low
impedance ground, not a mass of spaghetti wiring.

Most of the places I worked, the testing was done by techicians who
wrote up a test results report for the engineers and the engineers
only got involved if something was hinky in the test results.

Likewise. Unfortunately, production test was reluctant to call
engineering for help because we would tend to be rather disruptive.
When I had to fix things using paper reports (usually incoherent) and
ECO's (engineering change orders), it took much longer and many tries
to fix it correctly. When I sat down and saw the problem for myself,
it was usually fixed the first time, and usually without attendant
piles of paper going in both directions. I couldn't do much of that
at larger companies, but when I was asked for an overnight solution,
that was the only way.


--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

"Jeff Liebermann" napisal w wiadomosci
...
On Wed, 11 Jul 2012 15:04:43 -0000, wrote:

Unless you were in a very small operation or talking about REALLY ancient
times, engineers as a general rule never did mundane tasks.

Those were left to other, lesser paid people, like technicians, draftsmen,
and typists.

No one in their right mind would pay an engineer to build and test a
prototype, draw up the formal schematics, or type up the documentation
when there are other people who could do that faster and at a much lower
hourly rate.

True for most companies, but not true for every place that I've
worked.

It is not true for every R&D place.

There no "draw up the formal schematics, or type up the documentation"

The each prototype is simmillar to something older.
The R&D people take the copy of the simmillar documentation and change the
identification number and dimensions, materials etc..
The new prototype documentation is ready in a few hours.

One such small company made it a point of having the engineer
personally perform every step of the production cycle from incoming
inspection to shipping. At some point, I did incoming inspection
(QA), parts stuffing, wave soldering, lead trimming, final assembly,
cable harnesses, production test, QA test, burn-in setup, and
shipping. There was no attempt utilize expensive engineering talent
for these jobs. It was a very necessary learning experience that paid
off handsomely in improved efficiency. It's one thing to stand aside
and just watch someone do their job. It's quite another to actually
sit down and do it. For example, we had a small 3 turn coil that was
hand wound on a form. Production people could average about 5 coils
per hour, which stunk. I sat down for several hours, made numerous
changes, found numerous problems that nobody bothered to identify, and
was able to crank out about 40 coils per hour. However, my fingers
felt like they were going to fall off after about an hour. This
wasn't going to work. The experience was sufficient to justify the
design and construction of an automatic coil winder, that could do
about 200 coils per hour.

When I worked for larger companies, I did much the same thing. I
experienced some initial resistance but got the attention of
production by breaking a few rules, but which dramatically improved
efficiency. I arranged to have the drawings and assembly instructions
translated into several languages. While assemblers were expected to
know English, they were not proficient in technical English. From
then on, the suggestions and changes came quickly. Unfortunately, I
still had products to finish, but was allowed about 25% of my time to
do the production engineering function.

An engineer (or manager) that sits behind a computer, never leaves the
office, never sits on the production line, never understands how
things are built, and never has an understanding of anyone elses job,
will eventually make some rather nasty mistakes. Using engineering
talent for these functions is not a good idea for extended periods,
but is a good idea for the short periods needed to gain the necessary
experience.

Incidentally, in the distant past, one of my consulting jobs was
cleaning up the computerized RF board layouts produced by an
assortment of PCB designers, that didn't seem to understand that RF
travels in roughly straight lines, and that bypassing requires a low
impedance ground, not a mass of spaghetti wiring.

Most of the places I worked, the testing was done by techicians who
wrote up a test results report for the engineers and the engineers
only got involved if something was hinky in the test results.

Likewise. Unfortunately, production test was reluctant to call
engineering for help because we would tend to be rather disruptive.
When I had to fix things using paper reports (usually incoherent) and
ECO's (engineering change orders), it took much longer and many tries
to fix it correctly. When I sat down and saw the problem for myself,
it was usually fixed the first time, and usually without attendant
piles of paper going in both directions. I couldn't do much of that
at larger companies, but when I was asked for an overnight solution,
that was the only way.

It is obvious that you was working in R&D places.

If a prototype is a succes then the formal documentation is made by another
staff.
S*

On Thu, 12 Jul 2012 09:36:52 +0200, "Szczepan Bialek"
wrote:

It is obvious that you was working in R&D places.

Wrong. I worked for several manufacturers as an employee and as a
consultant. There was no R&D and I have never done any R&D.

If a prototype is a succes then the formal documentation is made by another
staff.

I never produced any formal documentation at any company. I did what
was needed to get a product into production and occasionally to
scribble something for trade journals and advertising.

The prototype and documentation were a parallel effort in order to
save time. It was quite common to do the prototype in stages, with
sections of the design being frozen before the final product had been
tested. This allowed some of the documentation to be completed before
the prototype was completed.

The closest approximation of something formal were two radio direction
finders for the US Coast Guard. The documentation was done by a
professional tech manual writer. I wrote most of the raw text and
sketched some of the drawings.
http://802.11junk.com/jeffl/AN-SRD-21/
http://802.11junk.com/jeffl/AN-SRD-22/


--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Szczepan Bialek wrote:


It is not true for every R&D place.

No one said anything about "R&D".

There no "draw up the formal schematics, or type up the documentation"

Utter nonsense.

The each prototype is simmillar to something older.
The R&D people take the copy of the simmillar documentation and change the
identification number and dimensions, materials etc..
The new prototype documentation is ready in a few hours.

More utter nonsense.

It is obvious that you was working in R&D places.

No, to someone that actually knows something, it is obvious he was mostly
working in places that manufactured products.

If a prototype is a succes then the formal documentation is made by another
staff.

Formal documentation is usually produced by a tech writter with inputs from
engineering and marketing.

Well, now we have another subject that you know absolutely nothing about
and just babble nonsense.

You really are a babbling, ignorant, ineducable, idiot.

"Jeff Liebermann" napisal w wiadomosci
...
On Thu, 12 Jul 2012 09:36:52 +0200, "Szczepan Bialek"
wrote:

It is obvious that you was working in R&D places.

Wrong. I worked for several manufacturers as an employee and as a
consultant. There was no R&D and I have never done any R&D.

"New product design and development is more often than not a crucial factor
in the survival of a company. In an industry that is changing fast, firms
must continually revise their design and range of products. .
"In general, R&D activities are conducted by specialized units or centers
belonging to companies"

Each manufacturer has such specialized units or centers belonging to
companies.

S*