On 03-Apr-24 15:37, occam wrote:
> On 01/04/2024 17:42, Athel Cornish-Bowden wrote:
>> On 2024-04-01 15:24:53 +0000, Garrett Wollman said:
>>
>>> In article <uudj7n$2b3sn$1@dont-email.me>,
>>> Hibou  <vpaereru-unmonitored@yahoo.com.invalid> wrote:
>>>> Le 31/03/2024 à 23:40, Garrett Wollman a écrit :
>>>>> I noted elsewhere that for most of the 20th century, American civil
>>>>> engineers were prejudiced against cable-stayed bridges, which were
>>>>> common in Europe during the post-WW2 reconstruction due to their
>>>>> economy of construction.  This didn't start to shift until the late
>>>>> 1980s.
>>>>
>>>> Galloping Gertie! one might say.
>>>
>>> The Tacoma Narrows Bridge was a suspension bridge, of course, and not
>>> a cable-stayed bridge.
>>
>> At one time that was the film I'd seen for the largest number of times.
>>
>>
>
> I can't see you finishing your popcorn to that film. How long is it, a
> minute or two?

If that event was repeated today there would be hundreds of videos
available.

--
Sam Plusnet

On 03-Apr-24 11:13, Bertel Lund Hansen wrote:
> Sam Plusnet wrote:
>
>> Governing parties which anticipate losing at the next election 'have
>> been known' to screw up the economy in ways that will cause great
>> headaches for the incoming party[1].
>> I can't quite see engineers doing that.
>
> Are there many cases where one engineer has taken over from another one
> on the same project?

My main career was spend doing exactly that.
A large team of engineers would design a new sonar and, produce a
pre-production prototype which more or less met the required specification.
At this point we (a much smaller team) would take over the project,
complete the design, support production, support the users, and deal
with all the design and performance issues that cropped up.

--
Sam Plusnet

On 03-Apr-24 15:07, Athel Cornish-Bowden wrote:
> On 2024-04-03 12:20:42 +0000, J. J. Lodder said:

>> Yes. Or even better: why build a huge container terminal
>> behind a vulnerable bridge?
>
> They wanted the money.

There was probably no suitable location outboard of that bridge.

--
Sam Plusnet

occam wrote:

> On 01/04/2024 17:42, Athel Cornish-Bowden wrote:
>> On 2024-04-01 15:24:53 +0000, Garrett Wollman said:
>>
>>> In article <uudj7n$2b3sn$1@dont-email.me>,
>>> Hibou  <vpaereru-unmonitored@yahoo.com.invalid> wrote:
>>>> Le 31/03/2024 à 23:40, Garrett Wollman a écrit :
>>>>> I noted elsewhere that for most of the 20th century, American civil
>>>>> engineers were prejudiced against cable-stayed bridges, which were
>>>>> common in Europe during the post-WW2 reconstruction due to their
>>>>> economy of construction.  This didn't start to shift until the late
>>>>> 1980s.
>>>>
>>>> Galloping Gertie! one might say.
>>>
>>> The Tacoma Narrows Bridge was a suspension bridge, of course, and not
>>> a cable-stayed bridge.
>>
>> At one time that was the film I'd seen for the largest number of times.
>>

> I can't see you finishing your popcorn to that film. How long is it, a
> minute or two?

2:35 at https://www.youtube.com/watch?v=esfpcnQW6qs

but I could finish all the popcorn I have in much less time than that.

--
Jerry Friedman

In article <0phPN.491615$yEgf.198430@fx09.iad>,
Sam Plusnet <not@home.com> wrote:
>On 03-Apr-24 15:07, Athel Cornish-Bowden wrote:
>> On 2024-04-03 12:20:42 +0000, J. J. Lodder said:
>
>>> Yes. Or even better: why build a huge container terminal
>>> behind a vulnerable bridge?
>>
>> They wanted the money.
>
>There was probably no suitable location outboard of that bridge.

Baltimore was settled where it is because of the harbor; the "huge
container terminal" was built at a location that has been a port for
250 years. The lower Patapsco River opens up fairly quickly onto
Chesapeake Bay, which is much more difficult to cross -- in fact, the
Key Bridge was the only crossing between the harbor and the Chesapeake
Bay Bridge many miles to the south in Annapolis. Most through traffic
uses the more direct Harbor Tunnel and Fort McHenry Tunnel, both of
which pass under the Inner Harbor, but which do not allow hazardous
cargoes; those must now take a long detour around the west and north
sides of Baltimore.

Really, folks should look at a map before commenting on the location
of a bridge.

-GAWollman

--
Garrett A. Wollman | "Act to avoid constraining the future; if you can,
wollman@bimajority.org| act to remove constraint from the future. This is
Opinions not shared by| a thing you can do, are able to do, to do together."
my employers. | - Graydon Saunders, _A Succession of Bad Days_ (2015)

On 03/04/24 21:13, Bertel Lund Hansen wrote:
> Sam Plusnet wrote:
>
>> Governing parties which anticipate losing at the next election
>> 'have been known' to screw up the economy in ways that will cause
>> great headaches for the incoming party[1].

Our present government inherited two disasters from the previous
government. One, big tax cuts for the rich, had the potential of sending
inflation out of control. The new government modified the details so as
to give some of the cuts to lower-income people, but I think the result
will still be inflationary. We'll see after June, when the changes come
into effect.

In the other, a treaty called AUKUS, the effects are long-term, so the
damage to Australia is not due for a few decades. I think the present
government decided to let it stand, on the grounds that it will probably
collapse from its own weight long after the present politicians are out
of office.

>> I can't quite see engineers doing that.
>
> Are there many cases where one engineer has taken over from another
> one on the same project?

There are, but usually the people involved are in the same company, so
the public is not aware of the change. Reputational damage, if any,
stays within the walls of that company.

> In the case of Sydney Opera it was actually reversed. The ones that
> took over, screwed up the job after Jørn Utzon.

The story I heard was quite different. According to the engineers, the
structure that Utzon designed was structurally unsound, and his design
had to be modified to ensure that the building would not collapse.

--
Peter Moylan http://www.pmoylan.org
Newcastle, NSW

On 03/04/24 21:41, Hibou wrote:
>
> Personally, I found it difficult to take over someone else's work.
> People think in different ways, have different styles when drawing
> circuits and writing software, which are not always easy to unravel.
> Original designers have had a lot of thoughts along the way, and
> these are not always recorded in their logbooks, so the hapless
> inheritor is unaware of them.

A decade ago, roughly, I designed a device to tell what direction sounds
were coming from. (For environmental monitoring around coal mines.) In
the intervening years I've been called back now and then to make
changes. Most recently, the company has asked me whether I could train a
new employee on how the system works. I think they're nervous about my
age. I'm expecting to be called at any time to do the training.

In preparation for this, I looked up my old documentation files. They
have plenty to say about the design of digital filters, the optimal
block size for a Fast Fourier Transform, and things like that. But my
notes on the theory behind the central algorithm are garbled. I can no
longer reconstruct the mathematics behind the basic concept. Maybe I can
set it as an assignment for the new employee. If that fails, I'll have
to give myself a refresher course on antenna design.

--
Peter Moylan http://www.pmoylan.org
Newcastle, NSW

Le 03/04/2024 à 23:01, Peter Moylan a écrit :
> On 03/04/24 21:41, Hibou wrote:
>>
>> Personally, I found it difficult to take over someone else's work.
>> People think in different ways, have different styles when drawing
>> circuits and writing software, which are not always easy to unravel.
>> Original designers have had a lot of thoughts along the way, and
>> these are not always recorded in their logbooks, so the hapless
>> inheritor is unaware of them.
>
> A decade ago, roughly, I designed a device to tell what direction sounds
> were coming from. (For environmental monitoring around coal mines.) In
> the intervening years I've been called back now and then to make
> changes. Most recently, the company has asked me whether I could train a
> new employee on how the system works. I think they're nervous about my
> age. I'm expecting to be called at any time to do the training.
>
> In preparation for this, I looked up my old documentation files. They
> have plenty to say about the design of digital filters, the optimal
> block size for a Fast Fourier Transform, and things like that. But my
> notes on the theory behind the central algorithm are garbled. I can no
> longer reconstruct the mathematics behind the basic concept. Maybe I can
> set it as an assignment for the new employee. If that fails, I'll have
> to give myself a refresher course on antenna design.

I learnt an early lesson from another engineer's mistake, when I was
assigned to work on an equipment containing a large halogen bulb. The
power supply was DC, but it seemed the bulb had a shorter life on DC
than AC, and on DC couldn't meet the MTBF (mean time between failures)
in the contracted spec. This was a big headache.

There was even a conjecture than ions migrated from one end of the
filament to the other on DC, but deposited evenly on AC, and that this
explained the shorter life.

Late in the day, I spoke to the man who had done the bulb-life
experiment and saw his logbook. It turned out he'd compared AC to
full-wave-rectified DC. What he hadn't appreciated was that his Avometer
was measuring the average value of the DC (0.637 x peak), not its RMS
value (0.707 x peak). So he was overrunning the bulb on DC, and that was
shortening its life. As far as I know - we never repeated the experiment
- there is no significant difference in bulb life between AC and DC.

He was a mechanical engineer, which mitigated the offence. An electronic
engineer would have been shot.

Peter Moylan wrote:

>> In the case of Sydney Opera it was actually reversed. The ones that
>> took over, screwed up the job after Jørn Utzon.
>
> The story I heard was quite different. According to the engineers, the
> structure that Utzon designed was structurally unsound, and his design
> had to be modified to ensure that the building would not collapse.

I find that hard to believe, but of course I am biased. I am inclined to
think that the new engineers didn't understand Utzon's construction.

This description tells about difficulties, but also about competent (I
suppose) people handling it.

https://createdigital.org.au/engineering-turned-sydney-opera-house-from-idea-into-icon/

I have read about some changes that seemed random (and expensive), but I
know too little and haven't got the neccesary source references to
enable a qualified debate.

--
Bertel, Denmark

Sam Plusnet <not@home.com> wrote:

> On 03-Apr-24 15:07, Athel Cornish-Bowden wrote:
> > On 2024-04-03 12:20:42 +0000, J. J. Lodder said:
>
> >> Yes. Or even better: why build a huge container terminal
> >> behind a vulnerable bridge?
> >
> > They wanted the money.
>
> There was probably no suitable location outboard of that bridge.

There always is. Just make one.
Look at the map, plenty of room all around,
it is completely ridiculous that they have their container terminal
right next to the city centre.
And if you have the patience, look at some other ports for the howto.

To please Athel: 'his' container terminal is in Saint Louis du Rhone,
not right next to the Vieux Port,

Jan

On 04/04/24 18:24, Hibou wrote:
> Le 03/04/2024 à 23:01, Peter Moylan a écrit :
>> On 03/04/24 21:41, Hibou wrote:
>>>
>>> Personally, I found it difficult to take over someone else's
>>> work. People think in different ways, have different styles when
>>> drawing circuits and writing software, which are not always easy
>>> to unravel. Original designers have had a lot of thoughts along
>>> the way, and these are not always recorded in their logbooks, so
>>> the hapless inheritor is unaware of them.
>>
>> A decade ago, roughly, I designed a device to tell what direction
>> sounds were coming from. (For environmental monitoring around coal
>> mines.) In the intervening years I've been called back now and
>> then to make changes. Most recently, the company has asked me
>> whether I could train a new employee on how the system works. I
>> think they're nervous about my age. I'm expecting to be called at
>> any time to do the training.
>>
>> In preparation for this, I looked up my old documentation files.
>> They have plenty to say about the design of digital filters, the
>> optimal block size for a Fast Fourier Transform, and things like
>> that. But my notes on the theory behind the central algorithm are
>> garbled. I can no longer reconstruct the mathematics behind the
>> basic concept. Maybe I can set it as an assignment for the new
>> employee. If that fails, I'll have to give myself a refresher
>> course on antenna design.
>
> I learnt an early lesson from another engineer's mistake, when I was
> assigned to work on an equipment containing a large halogen bulb. The
> power supply was DC, but it seemed the bulb had a shorter life on DC
> than AC, and on DC couldn't meet the MTBF (mean time between
> failures) in the contracted spec. This was a big headache.
>
> There was even a conjecture than ions migrated from one end of the
> filament to the other on DC, but deposited evenly on AC, and that
> this explained the shorter life.
>
> Late in the day, I spoke to the man who had done the bulb-life
> experiment and saw his logbook. It turned out he'd compared AC to
> full-wave-rectified DC. What he hadn't appreciated was that his
> Avometer was measuring the average value of the DC (0.637 x peak),
> not its RMS value (0.707 x peak). So he was overrunning the bulb on
> DC, and that was shortening its life. As far as I know - we never
> repeated the experiment - there is no significant difference in bulb
> life between AC and DC.
>
> He was a mechanical engineer, which mitigated the offence. An
> electronic engineer would have been shot.

A mechanical engineer today would probably make the same mistake.

I did my undergraduate studies at Melbourne University, where the
prevailing philosophy was that an engineering graduate should be able to
work in any branch of engineering. (And, indeed, I did subsequently meet
engineers who had crossed the borders.) That meant a big emphasis on
breadth. My very first subject was technical drawing, where we had to
learn things like how to wash a pen, the correct way to sharpen a pencil
with a razor blade, the correct slope of lettering (23.5 degrees, IIRC,
although I might be confusing that with the earth's tilt), mapping 3D
drawings with different perspective. That sort of thing had become
obsolete in EE years earlier, but it was still important in mechanical and
civil engineering. (Today, software packages handle the fiddly details,
and engineers no longer have black ink on their fingers.)

Subsequently I had to suffer through subjects like strength of
materials, thermodynamics, fluid mechanics, and even the crystal
structure of different kinds of steel. On top of this we had the "basic
science" subjects of mathematics, physics, and chemistry. As a result,
we didn't even get to electrical engineering subjects until third year.

In hindsight, I can see that the definition of "breadth" was biased.
Electrical engineering students had to study mechanical engineering
subjects, but not vice versa. EE was the new kid on the block, and
didn't quite fit into the traditional engineering culture.

By now, the steady arrival of new topics that must be taught means that
"breadth" is dead in the water. Specialisation is essential, and there's
nothing we can do that can change that trend.

Actually, we can, but should we? After I moved into an R&D company, I
had a colleague who had graduated from a German "general engineering"
degree. It didn't work out. He just didn't have the skills that the rest
of us took for granted.

--
Peter Moylan http://www.pmoylan.org
Newcastle, NSW

On 04/04/24 18:51, Bertel Lund Hansen wrote:
> Peter Moylan wrote:
>
>>> In the case of Sydney Opera it was actually reversed. The ones
>>> that took over, screwed up the job after Jørn Utzon.
>>
>> The story I heard was quite different. According to the engineers,
>> the structure that Utzon designed was structurally unsound, and
>> his design had to be modified to ensure that the building would
>> not collapse.
>
> I find that hard to believe, but of course I am biased. I am
> inclined to think that the new engineers didn't understand Utzon's
> construction.
>
> This description tells about difficulties, but also about competent
> (I suppose) people handling it.
>
> https://createdigital.org.au/engineering-turned-sydney-opera-house-from-idea-into-icon/

Thanks
>
for the pointer. That's an interesting article, and it seems to
give a fair description of the interaction between Utzon and the engineers.

> I have read about some changes that seemed random (and expensive),
> but I know too little and haven't got the neccesary source
> references to enable a qualified debate.

I too know too little about it, and I don't have a dog in this race, so
I guess that's the end of the debate.

My picture of architects was unfortunately biased by the fact that I
once had a housemate who was an architecture student. His lack of
competence in anything at all left me wondering how low the Architecture
faculty had dropped its standards to allow such a person to enter the
university. On the other hand, I have to concede that you can't prove
anything with a sample size of one.

--
Peter Moylan http://www.pmoylan.org
Newcastle, NSW

Snidely <snidely.too@gmail.com> wrote:

> After serious thinking charles wrote :
> > In article <uuejk5$du7$1@usenet.csail.mit.edu>,
> > Garrett Wollman <wollman@hergotha.csail.mit.edu> wrote:
> >> In article <uudj7n$2b3sn$1@dont-email.me>,
> >> Hibou <vpaereru-unmonitored@yahoo.com.invalid> wrote:
> >>> Le 31/03/2024 à 23:40, Garrett Wollman a écrit :
> >>>> I noted elsewhere that for most of the 20th century, American civil
> >>>> engineers were prejudiced against cable-stayed bridges, which were
> >>>> common in Europe during the post-WW2 reconstruction due to their
> >>>> economy of construction. This didn't start to shift until the late
> >>>> 1980s.
> >>>
> >>> Galloping Gertie! one might say.
> >
> >> The Tacoma Narrows Bridge was a suspension bridge, of course, and not
> >> a cable-stayed bridge.
> >
> > we were shown the film of it during my Engineering degree, (1959-62)
>
> ISTR that the explanation of the resonance was, perhaps, oversimplified
> in most presentations. Being a bit banger, I didn't retain the full
> scope of the correction.

Not just oversimplified, it is completely wrong.
Resonance had nothing to do with it,

Jan

Stefan Ram <ram@zedat.fu-berlin.de> wrote:

> Ross Clark <benlizro@ihug.co.nz> wrote or quoted:
> >black swan (proverbial) something extremely rare (or non-existent)
>
> Existence can be proven epistemically, by observation,
> non-existance cannot be proven by non-observation.
>
> There is a Wikipedia article "Observable universe" saying that
> we well never be able to observe certain parts of the universe.
> Whatever it is that we have never seen, it might be there!
> Speaking swans? Swans that can shoot arrows from their mouths?
> Speaking swans that can shoot arrows from their mouths?

It is even worse. Assuming acceleratiod expansion of the universe
things that are visible now will eventually move behind the horizon
and become invisible.

If we could wait long enough the whole universe
will become unobservable.
(excepting only those parts that are gravitationally bound
to our galaxy)

Jan

On 04/04/24 22:26, J. J. Lodder wrote:
> Snidely <snidely.too@gmail.com> wrote:
>> After serious thinking charles wrote :
>>> In article <uuejk5$du7$1@usenet.csail.mit.edu>, Garrett Wollman
>>> <wollman@hergotha.csail.mit.edu> wrote:

>>>> The Tacoma Narrows Bridge was a suspension bridge, of course,
>>>> and not a cable-stayed bridge.
>>>
>>> we were shown the film of it during my Engineering degree,
>>> (1959-62)
>>
>> ISTR that the explanation of the resonance was, perhaps,
>> oversimplified in most presentations. Being a bit banger, I didn't
>> retain the full scope of the correction.
>
> Not just oversimplified, it is completely wrong. Resonance had
> nothing to do with it,

Could you expand? I've seen the film, of course, and heard the
explanation, but I don't recall anything in the explanation that
rejected resonance as the cause.

--
Peter Moylan http://www.pmoylan.org
Newcastle, NSW

On 2024-04-04, Peter Moylan wrote:

> On 04/04/24 22:26, J. J. Lodder wrote:
>> Snidely <snidely.too@gmail.com> wrote:
>>> After serious thinking charles wrote :
>>>> In article <uuejk5$du7$1@usenet.csail.mit.edu>, Garrett Wollman
>>>> <wollman@hergotha.csail.mit.edu> wrote:
>
>>>>> The Tacoma Narrows Bridge was a suspension bridge, of course,
>>>>> and not a cable-stayed bridge.
>>>>
>>>> we were shown the film of it during my Engineering degree,
>>>> (1959-62)
>>>
>>> ISTR that the explanation of the resonance was, perhaps,
>>> oversimplified in most presentations. Being a bit banger, I didn't
>>> retain the full scope of the correction.
>>
>> Not just oversimplified, it is completely wrong. Resonance had
>> nothing to do with it,
>
> Could you expand? I've seen the film, of course, and heard the
> explanation, but I don't recall anything in the explanation that
> rejected resonance as the cause.

Well, the WP article includes this:

To some degree the debate is due to the lack of a commonly accepted
precise definition of resonance.

<https://en.wikipedia.org/wiki/Tacoma_Narrows_Bridge_(1940)#Resonance_vs._non-resonance_explanations>

--
I heard that Hans Christian Andersen lifted the title for "The Little
Mermaid" off a Red Lobster Menu. ---Bucky Katt

On 2024-04-04, Peter Moylan wrote:

> On 04/04/24 18:24, Hibou wrote:
>> Le 03/04/2024 à 23:01, Peter Moylan a écrit :
>>> On 03/04/24 21:41, Hibou wrote:
>>>>
>>>> Personally, I found it difficult to take over someone else's
>>>> work. People think in different ways, have different styles when
>>>> drawing circuits and writing software, which are not always easy
>>>> to unravel. Original designers have had a lot of thoughts along
>>>> the way, and these are not always recorded in their logbooks, so
>>>> the hapless inheritor is unaware of them.
>>>
>>> A decade ago, roughly, I designed a device to tell what direction
>>> sounds were coming from. (For environmental monitoring around coal
>>> mines.) In the intervening years I've been called back now and
>>> then to make changes. Most recently, the company has asked me
>>> whether I could train a new employee on how the system works. I
>>> think they're nervous about my age. I'm expecting to be called at
>>> any time to do the training.
>>>
>>> In preparation for this, I looked up my old documentation files.
>>> They have plenty to say about the design of digital filters, the
>>> optimal block size for a Fast Fourier Transform, and things like
>>> that. But my notes on the theory behind the central algorithm are
>>> garbled. I can no longer reconstruct the mathematics behind the
>>> basic concept. Maybe I can set it as an assignment for the new
>>> employee. If that fails, I'll have to give myself a refresher
>>> course on antenna design.
>>
>> I learnt an early lesson from another engineer's mistake, when I was
>> assigned to work on an equipment containing a large halogen bulb. The
>> power supply was DC, but it seemed the bulb had a shorter life on DC
>> than AC, and on DC couldn't meet the MTBF (mean time between
>> failures) in the contracted spec. This was a big headache.
>>
>> There was even a conjecture than ions migrated from one end of the
>> filament to the other on DC, but deposited evenly on AC, and that
>> this explained the shorter life.
>>
>> Late in the day, I spoke to the man who had done the bulb-life
>> experiment and saw his logbook. It turned out he'd compared AC to
>> full-wave-rectified DC. What he hadn't appreciated was that his
>> Avometer was measuring the average value of the DC (0.637 x peak),
>> not its RMS value (0.707 x peak). So he was overrunning the bulb on
>> DC, and that was shortening its life. As far as I know - we never
>> repeated the experiment - there is no significant difference in bulb
>> life between AC and DC.
>>
>> He was a mechanical engineer, which mitigated the offence. An
>> electronic engineer would have been shot.

"Take him out and shoot him," General Dreedle demanded.

> A mechanical engineer today would probably make the same mistake.
>
> I did my undergraduate studies at Melbourne University, where the
> prevailing philosophy was that an engineering graduate should be able to
> work in any branch of engineering. (And, indeed, I did subsequently meet
> engineers who had crossed the borders.) That meant a big emphasis on
> breadth. My very first subject was technical drawing, where we had to
> learn things like how to wash a pen, the correct way to sharpen a pencil
> with a razor blade, the correct slope of lettering (23.5 degrees, IIRC,
> although I might be confusing that with the earth's tilt), mapping 3D
> drawings with different perspective. That sort of thing had become
> obsolete in EE years earlier, but it was still important in mechanical and
> civil engineering. (Today, software packages handle the fiddly details,
> and engineers no longer have black ink on their fingers.)
>
> Subsequently I had to suffer through subjects like strength of
> materials, thermodynamics, fluid mechanics, and even the crystal
> structure of different kinds of steel. On top of this we had the "basic
> science" subjects of mathematics, physics, and chemistry. As a result,
> we didn't even get to electrical engineering subjects until third year.
>
> In hindsight, I can see that the definition of "breadth" was biased.
> Electrical engineering students had to study mechanical engineering
> subjects, but not vice versa. EE was the new kid on the block, and
> didn't quite fit into the traditional engineering culture.
>
> By now, the steady arrival of new topics that must be taught means that
> "breadth" is dead in the water. Specialisation is essential, and there's
> nothing we can do that can change that trend.

Well, they could make an engineering degree take 10 years.

> Actually, we can, but should we? After I moved into an R&D company, I
> had a colleague who had graduated from a German "general engineering"
> degree. It didn't work out. He just didn't have the skills that the rest
> of us took for granted.
>

--
In general, I find that calligraphers are just about the nicest people
I've ever met. ---Donald Knuth

Just this Wednesday, Hibou puzzled about:
> Le 03/04/2024 à 11:13, Bertel Lund Hansen a écrit :
>> Sam Plusnet wrote:
>>>
>>> Governing parties which anticipate losing at the next election 'have
>>> been known' to screw up the economy in ways that will cause great
>>> headaches for the incoming party[1].
>>> I can't quite see engineers doing that.
>>
>> Are there many cases where one engineer has taken over from another one
>> on the same project?
>>
>> In the case of Sydney Opera it was actually reversed. The ones that took
>> over, screwed up the job after Jørn Utzon.
>
> Where I worked, it happened fairly often. People move on to other projects,
> contractors do a job that is then passed to permanent staff... (and the
> contractor is then unavailable to answer questions).
>
> Personally, I found it difficult to take over someone else's work. People
> think in different ways, have different styles when drawing circuits and
> writing software, which are not always easy to unravel. Original designers
> have had a lot of thoughts along the way, and these are not always recorded
> in their logbooks, so the hapless inheritor is unaware of them.
>
> I don't think I was alone. An engineer who inherited some software from me,
> in which I'd been having fun with recursion, complained that I must have been
> on drugs when I wrote it.

I've done a lot of code maintenance, and a little of being the legacy
designer. One driver that I worked on was spaghetti code; I finally
was able to replace a lot of that with nested state machines.

But consider TV repairmen and other service techs. There's a schematic
for service techs used to explain the device in this video:
<URL:https://www.youtube.com/watch?v=ue-1JoJQaEg>

/dps

--
"Inviting people to laugh with you while you are laughing at yourself
is a good thing to do, You may be a fool but you're the fool in
charge." -- Carl Reiner

Peter Moylan <peter@pmoylan.org.invalid> wrote:

> On 04/04/24 22:26, J. J. Lodder wrote:
> > Snidely <snidely.too@gmail.com> wrote:
> >> After serious thinking charles wrote :
> >>> In article <uuejk5$du7$1@usenet.csail.mit.edu>, Garrett Wollman
> >>> <wollman@hergotha.csail.mit.edu> wrote:
>
> >>>> The Tacoma Narrows Bridge was a suspension bridge, of course,
> >>>> and not a cable-stayed bridge.
> >>>
> >>> we were shown the film of it during my Engineering degree,
> >>> (1959-62)
> >>
> >> ISTR that the explanation of the resonance was, perhaps,
> >> oversimplified in most presentations. Being a bit banger, I didn't
> >> retain the full scope of the correction.
> >
> > Not just oversimplified, it is completely wrong. Resonance had
> > nothing to do with it,
>
> Could you expand? I've seen the film, of course, and heard the
> explanation, but I don't recall anything in the explanation that
> rejected resonance as the cause.

It is just flutter.
The frequenies are not resonant with any normal mode of the structure,

Jan

Le 04/04/2024 à 16:10, Snidely a écrit :
>
> But consider TV repairmen and other service techs.  There's a schematic
> for service techs used to explain the device in this video:
> <URL:https://www.youtube.com/watch?v=ue-1JoJQaEg>

Well, yes, but they have to understand only to the level that allows
them to find and cure faults. A designer or an engineer who modifies
another's design needs a much deeper understanding.

In the UK, anyone can call himself or herself an engineer -
central-heating engineer and so forth - but they are mostly technicians.
I prefer a more Continental European definition: 'engineers' should be
masters of their art - especially if they're entrusted with designing
bridges.

As to fault finding.... A design I inherited was a small circuit board
containing 11 ICs. It went into production, and one day one of these
boards was sent up to me because it was faulty and they couldn't fix it
downstairs. I found they had changed 10 out of the 11 chips trying to
find the fault - but when I buzzed the board, I found a broken track.

The place was better than it sounds. It's the exceptional that sticks in
the mind.

Le 05/04/2024 à 06:30, Hibou a écrit :
>
> As to fault finding.... A design I inherited was a small circuit board
> containing 11 ICs. It went into production, and one day one of these
> boards was sent up to me because it was faulty and they couldn't fix it
> downstairs. I found they had changed 10 out of the 11 chips trying to
> find the fault - but when I buzzed the board, I found a broken track. [...]

Much more impressive is Richard Feynman's anecdote of how he fixed a
radio set when he were a lad. From memory (I'm too lazy to look it up),
the set would howl when warming up, then settle down and work properly.
He walked up and down, trying to think how this could occur, and decided
that a later stage must be warming up before an earlier one had
stabilised. Since the valves were identical (he would've called them
'toobs'), he swapped them, and that cured the fault.

So there it is. Go forth and find fault!

On 05/04/24 16:49, Hibou wrote:
> Le 05/04/2024 à 06:30, Hibou a écrit :
>>
>> As to fault finding.... A design I inherited was a small circuit
>> board containing 11 ICs. It went into production, and one day one
>> of these boards was sent up to me because it was faulty and they
>> couldn't fix it downstairs. I found they had changed 10 out of the
>> 11 chips trying to find the fault - but when I buzzed the board, I
>> found a broken track. [...]
>
> Much more impressive is Richard Feynman's anecdote of how he fixed a
> radio set when he were a lad. From memory (I'm too lazy to look it
> up), the set would howl when warming up, then settle down and work
> properly. He walked up and down, trying to think how this could
> occur, and decided that a later stage must be warming up before an
> earlier one had stabilised. Since the valves were identical (he
> would've called them 'toobs'), he swapped them, and that cured the
> fault.
>
> So there it is. Go forth and find fault!

The howling reminds me of another story.

A telephone technician went to the home of a customer who had complained
that the bell of her phone had stopped working. When anyone phoned her,
the phone made no sound. "Then how do you know that anyone has called
you?" he asked. "Because the dog howls when someone phones me", she said.

Eventually he found the problem. The dog was on a chain in the back
yard, with the end of the chain attached to a metal stake. And that
stake had gone right through the telephone cable.

--
Peter Moylan http://www.pmoylan.org
Newcastle, NSW

Hibou wrote:

> Much more impressive is Richard Feynman's anecdote of how he fixed a
> radio set when he were a lad. From memory (I'm too lazy to look it up),
> the set would howl when warming up, then settle down and work properly.
> He walked up and down, trying to think how this could occur, and decided
> that a later stage must be warming up before an earlier one had
> stabilised. Since the valves were identical (he would've called them
> 'toobs'), he swapped them, and that cured the fault.
>
> So there it is. Go forth and find fault!

My father (who as it happens ins an engineer) is keeping odds and ends
because he might one day need them. He was very proud of his repairing
the washing machine after a technician had given up and advised him to
buy a new one. He took it at apart, located the error to the program
'clock' and discovered that a small spring was broken in two. He could
find an identical one in his collection, and inserting it fixed the
problem.

"Is" because he is still alive and well. 20 days ago we celebrated his
hundredth birthday.

--
Bertel, Denmark

On Fri, 5 Apr 2024 08:20:18 +0200
Bertel Lund Hansen <gadekryds@lundhansen.dk> wrote:

> Hibou wrote:
>
> > Much more impressive is Richard Feynman's anecdote of how he fixed a
> > radio set when he were a lad. From memory (I'm too lazy to look it up),
> > the set would howl when warming up, then settle down and work properly.
> > He walked up and down, trying to think how this could occur, and decided
> > that a later stage must be warming up before an earlier one had
> > stabilised. Since the valves were identical (he would've called them
> > 'toobs'), he swapped them, and that cured the fault.
> >
> > So there it is. Go forth and find fault!
>
> My father (who as it happens ins an engineer) is keeping odds and ends
> because he might one day need them. He was very proud of his repairing
> the washing machine after a technician had given up and advised him to
> buy a new one. He took it at apart, located the error to the program
> 'clock' and discovered that a small spring was broken in two. He could
> find an identical one in his collection, and inserting it fixed the
> problem.

For want of a nail...

>
> "Is" because he is still alive and well. 20 days ago we celebrated his
> hundredth birthday.
>
Hurrah.

PS can he take a look at my wm/c, and fridge and...

--
Bah, and indeed Humbug.

Hibou <vpaereru-unmonitored@yahoo.com.invalid> wrote:

> Le 04/04/2024 à 16:10, Snidely a écrit :
> >
> > But consider TV repairmen and other service techs. There's a schematic
> > for service techs used to explain the device in this video:
> > <URL:https://www.youtube.com/watch?v=ue-1JoJQaEg>
>
> Well, yes, but they have to understand only to the level that allows
> them to find and cure faults. A designer or an engineer who modifies
> another's design needs a much deeper understanding.
>
> In the UK, anyone can call himself or herself an engineer -
> central-heating engineer and so forth - but they are mostly technicians.
> I prefer a more Continental European definition: 'engineers' should be
> masters of their art - especially if they're entrusted with designing
> bridges.
>
> As to fault finding.... A design I inherited was a small circuit board
> containing 11 ICs. It went into production, and one day one of these
> boards was sent up to me because it was faulty and they couldn't fix it
> downstairs. I found they had changed 10 out of the 11 chips trying to
> find the fault - but when I buzzed the board, I found a broken track.
>
> The place was better than it sounds. It's the exceptional that sticks in
> the mind.

Indeed. The first step in fault finding
is inspectiing the board with a good magnifyig glass.
In cases of power carrying circuit boards
a magnifying glass will not even be necessary.
The burnt spot will be immediately obvious.

Jan