K
Klaus Kragelund
Guest
Be, Think, Innovate
https://www.grundfos.com/about-us/Our%20company/be-think-innovate.html
https://www.grundfos.com/about-us/Our%20company/be-think-innovate.html
L
Lasse Langwadt Christense
Guest
lørdag den 15. februar 2020 kl. 22.15.53 UTC+1 skrev jla...@highlandsniptechnology.com:
https://imgs.xkcd.com/comics/ballmer_peak.png
https://imgs.xkcd.com/comics/ballmer_peak.png
B
Bill Sloman
Guest
On Sunday, February 16, 2020 at 9:19:55 AM UTC+11, Klaus Kragelund wrote:
Innovation is good - when you need it. When it becomes a form of showing off, it leads to designers rejecting the known good way of solving problem and adopting a solution which isn't quite as tried and tested.
I've worked with people who fancied themselves as inventors, and it could be wearing. I've known two people who had got their their on 25 patents - my father and a friend of mine from EMI Central Research - and neither of them was in the least interested in being innovative for the sake doing things differently.
--
Bill Sloman, Sydney
Innovation is good - when you need it. When it becomes a form of showing off, it leads to designers rejecting the known good way of solving problem and adopting a solution which isn't quite as tried and tested.
I've worked with people who fancied themselves as inventors, and it could be wearing. I've known two people who had got their their on 25 patents - my father and a friend of mine from EMI Central Research - and neither of them was in the least interested in being innovative for the sake doing things differently.
--
Bill Sloman, Sydney
J
Jeff Liebermann
Guest
On Fri, 14 Feb 2020 18:35:18 -0800, jlarkin@highlandsniptechnology.com
wrote:
Does that mean one should stop working before one is allowed or able
to think? That doesn't really work well because the project clock and
schedule don't just stop on my command. Consider the time to think a
luxury, that should be tasted sparingly lest run out of time to think.
Or, does that mean I should empty my mind before attempting to think?
The Wisdom of Empty Minds
<https://www.beliefnet.com/faiths/buddhism/2001/05/the-wisdom-of-empty-minds.aspx>
Emptying Your Mind and Becoming Zero
<https://www.hinduwebsite.com/divinelife/selfnegation.asp>
Hopefully, you're not recommending meditation.
Or, is "Stop -> Think" an abbreviated form of:
When you're up to your neck in alligators, it's hard to
remember that your initial objective was to drain the swamp.
At one employer, it was considered proper to be subtle when reminding
engineers of this rather common problem. My immediate supervisor
would look at what I was doing and ask "Am I paying you to do this?" I
usually didn't have an answer, but after being buried in diversions, I
would ask him "Are you paying me to do this?"[1]
Or, perhaps it's a variation of:
Do something, even if it's wrong".
It's often difficult to distinguish between thought, contemplation,
day dreaming, thought experiments, loafing, meditation, and plotting
revenge. In all cases, it requires interrupting the thinker to
determine if their line of thought is productive, reactionary, or
conspiratorial. Whatever the motivation, the act of interruption is
disruptive and non-productive. It's better to assume that a blank
stare means re-evaluating the projects direction and reconsidering
contradictory instructions and assumptions, than to interrupt the
thinker and insure that nothing of value will be produced.
I noticed that you left a blank line between stop and think, possibly
for the addition of another fundamental. When I'm stuck, it's usually
not due my failure to recall the project objectives. Instead, I find
myself failing to see the obvious, too many assumptions, or my
trademark arithmetic errors. In other words, I can't properly
evaluate my own work. So, I press the virtual reset button by
stopping what I'm doing, go for a walk to get away from the problem,
and return with a fresh or at least modified approach. I suggest you
amend your Fundamentals of Engineering to include:
Stop -> Clear Brain -> Think
Also, when I go for my walk, I usually carry a small note pad or
smartphone voice recorder app, to record anything of value because
I've found that creative thinking is often rather transient and
volatile.
[1] Two of the most original products I created were the result of
distractions and diversions.
--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
wrote:
Does that mean one should stop working before one is allowed or able
to think? That doesn't really work well because the project clock and
schedule don't just stop on my command. Consider the time to think a
luxury, that should be tasted sparingly lest run out of time to think.
Or, does that mean I should empty my mind before attempting to think?
The Wisdom of Empty Minds
<https://www.beliefnet.com/faiths/buddhism/2001/05/the-wisdom-of-empty-minds.aspx>
Emptying Your Mind and Becoming Zero
<https://www.hinduwebsite.com/divinelife/selfnegation.asp>
Hopefully, you're not recommending meditation.
Or, is "Stop -> Think" an abbreviated form of:
When you're up to your neck in alligators, it's hard to
remember that your initial objective was to drain the swamp.
At one employer, it was considered proper to be subtle when reminding
engineers of this rather common problem. My immediate supervisor
would look at what I was doing and ask "Am I paying you to do this?" I
usually didn't have an answer, but after being buried in diversions, I
would ask him "Are you paying me to do this?"[1]
Or, perhaps it's a variation of:
Do something, even if it's wrong".
It's often difficult to distinguish between thought, contemplation,
day dreaming, thought experiments, loafing, meditation, and plotting
revenge. In all cases, it requires interrupting the thinker to
determine if their line of thought is productive, reactionary, or
conspiratorial. Whatever the motivation, the act of interruption is
disruptive and non-productive. It's better to assume that a blank
stare means re-evaluating the projects direction and reconsidering
contradictory instructions and assumptions, than to interrupt the
thinker and insure that nothing of value will be produced.
I noticed that you left a blank line between stop and think, possibly
for the addition of another fundamental. When I'm stuck, it's usually
not due my failure to recall the project objectives. Instead, I find
myself failing to see the obvious, too many assumptions, or my
trademark arithmetic errors. In other words, I can't properly
evaluate my own work. So, I press the virtual reset button by
stopping what I'm doing, go for a walk to get away from the problem,
and return with a fresh or at least modified approach. I suggest you
amend your Fundamentals of Engineering to include:
Stop -> Clear Brain -> Think
Also, when I go for my walk, I usually carry a small note pad or
smartphone voice recorder app, to record anything of value because
I've found that creative thinking is often rather transient and
volatile.
[1] Two of the most original products I created were the result of
distractions and diversions.
--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
Guest
On Saturday, February 15, 2020 at 8:37:43 PM UTC-5, Jeff Liebermann wrote:
Mixing metaphors here..rules vs algorithms. as well as level of abstraction.
I tend to refine 'think' to something a bit more concrete, but still abstract enough:
Understand the problem that is being solved, or as some of my physics teachers used to say, make sure the problem is well formed...
This is sometimes harder than you think.
Mixing metaphors here..rules vs algorithms. as well as level of abstraction.
I tend to refine 'think' to something a bit more concrete, but still abstract enough:
Understand the problem that is being solved, or as some of my physics teachers used to say, make sure the problem is well formed...
This is sometimes harder than you think.
Guest
On Sat, 15 Feb 2020 17:37:41 -0800, Jeff Liebermann <jeffl@cruzio.com>
wrote:
It's useful to stop doing things once in a while and ask if you are
still trying to do the best thing. Or if you are making any big
mistakes. In a group, personality pressures discourage this sort of
thinking.
In economics, the "sunk cost fallacy" corresponds to the folk concept
"throwing good money after bad."
Sometimes halfway through a 2-year project, someone stops and thinks
of a different approach that will be better and take three months.
Sometimes the act of executing a clumsy design makes one really
understand the problem.
I'm thinking about this because I'm involved with a semiconductor
company that is all pickey about how we are instrumenting sensors that
haven't worked for about 18 years now. They spend around a million
dollars a year installing them. We acquire the data. Nobody uses it.
But nobody will state the obvious.
--
John Larkin Highland Technology, Inc
The cork popped merrily, and Lord Peter rose to his feet.
"Bunter", he said, "I give you a toast. The triumph of Instinct over Reason"
wrote:
It's useful to stop doing things once in a while and ask if you are
still trying to do the best thing. Or if you are making any big
mistakes. In a group, personality pressures discourage this sort of
thinking.
In economics, the "sunk cost fallacy" corresponds to the folk concept
"throwing good money after bad."
Sometimes halfway through a 2-year project, someone stops and thinks
of a different approach that will be better and take three months.
Sometimes the act of executing a clumsy design makes one really
understand the problem.
I'm thinking about this because I'm involved with a semiconductor
company that is all pickey about how we are instrumenting sensors that
haven't worked for about 18 years now. They spend around a million
dollars a year installing them. We acquire the data. Nobody uses it.
But nobody will state the obvious.
--
John Larkin Highland Technology, Inc
The cork popped merrily, and Lord Peter rose to his feet.
"Bunter", he said, "I give you a toast. The triumph of Instinct over Reason"
W
whit3rd
Guest
On Sunday, February 16, 2020 at 7:10:12 PM UTC-8, jla...@highlandsniptechnology.com wrote:
If it's process monitoring, knowing how a process went awry AFTER a
few batches fail is very important, but when the batches don't fail,
the records gather dust.
There are circumstances where a process gone awry can destroy the equipment (in
parts-per-billion contamination with the wrong stuff) and only an extraordinary
amount of info can tell you the salvage prospects. So, the information might
be only for insurance in case of a disaster. Pay for insurance, don't expect
to profit from it, but it still DOES make sense.
If it's process monitoring, knowing how a process went awry AFTER a
few batches fail is very important, but when the batches don't fail,
the records gather dust.
There are circumstances where a process gone awry can destroy the equipment (in
parts-per-billion contamination with the wrong stuff) and only an extraordinary
amount of info can tell you the salvage prospects. So, the information might
be only for insurance in case of a disaster. Pay for insurance, don't expect
to profit from it, but it still DOES make sense.
J
John Larkin
Guest
On Sun, 16 Feb 2020 19:25:29 -0800 (PST), whit3rd <whit3rd@gmail.com>
wrote:
But it doesn't make sense to collect and archive bad data.
This is a process that dithers some timings to find the sweet spot,
maximum output, which is roughly inverted parabolic on our inputs. Our
gear was supposed to work but, since it doesn't, they found some other
sensor to use. But they keep installing the sensors that don't work.
I guess a million dollars a year is way down in the noise.
--
John Larkin Highland Technology, Inc
picosecond timing precision measurement
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
wrote:
But it doesn't make sense to collect and archive bad data.
This is a process that dithers some timings to find the sweet spot,
maximum output, which is roughly inverted parabolic on our inputs. Our
gear was supposed to work but, since it doesn't, they found some other
sensor to use. But they keep installing the sensors that don't work.
I guess a million dollars a year is way down in the noise.
--
John Larkin Highland Technology, Inc
picosecond timing precision measurement
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
R
Rich S
Guest
On Saturday, February 15, 2020 at 2:39:29 AM UTC-5, DecadentLinux...@decadence.org wrote:
also consider the cyclical nature of EE work,
a la Shewart cycle (plan, do, act, adjust,...Go To 1)
or, as done on s.e.d., 'lather' 'rinse' 'repeat'...
cheers, rich s.
also consider the cyclical nature of EE work,
a la Shewart cycle (plan, do, act, adjust,...Go To 1)
or, as done on s.e.d., 'lather' 'rinse' 'repeat'...
cheers, rich s.
T
three_jeeps
Guest
On Monday, February 17, 2020 at 1:16:44 PM UTC-5, John Larkin wrote:
Process monitoring and associated data can be very useful if the right data is collected and used in the right way.
Process data is often used to detect drift in certain process variables which can kickoff some inspection/diagnosis/mitigation action. All sorts of neat statistical things can be done here.
Also, it can be used to determine machine wear out. Back in the day, we developed signature analysis for machine tool monitoring, prime mover monitoring, etc. Basically it was frequency spectrum analysis of vibration on various axis, which correlated to impending tool or machine failure.
We developed a digital version of signature analysis focused on discrete logic boards - put a whole lot of input vectors into a discrete board and observe outputs at different points of the board. Did a similar technique for analog boards...
point is, collecting a bit basket full of data doesn't have to be useless.....
Process monitoring and associated data can be very useful if the right data is collected and used in the right way.
Process data is often used to detect drift in certain process variables which can kickoff some inspection/diagnosis/mitigation action. All sorts of neat statistical things can be done here.
Also, it can be used to determine machine wear out. Back in the day, we developed signature analysis for machine tool monitoring, prime mover monitoring, etc. Basically it was frequency spectrum analysis of vibration on various axis, which correlated to impending tool or machine failure.
We developed a digital version of signature analysis focused on discrete logic boards - put a whole lot of input vectors into a discrete board and observe outputs at different points of the board. Did a similar technique for analog boards...
point is, collecting a bit basket full of data doesn't have to be useless.....
T
Tom Del Rosso
Guest
jlarkin@highlandsniptechnology.com wrote:
Define the problem.
Define the problem.
Guest
On Saturday, February 15, 2020 at 1:36:50 PM UTC-5, whit3rd wrote:
It's often better to cut twice, converging on the target with
successive approximations rather than assuming perfect knowledge,
perfect cuts, and infallible measurements in advance.
The latter is, often, more hubris than wisdom.
Cheers,
James Arthur
It's often better to cut twice, converging on the target with
successive approximations rather than assuming perfect knowledge,
perfect cuts, and infallible measurements in advance.
The latter is, often, more hubris than wisdom.
Cheers,
James Arthur
Guest
On Tuesday, February 18, 2020 at 12:17:46 AM UTC-5, Tom Del Rosso wrote:
Any problem comprises two smaller problems.
Cheers,
James Arthur
Any problem comprises two smaller problems.
Cheers,
James Arthur
G
George Herold
Guest
On Tuesday, February 18, 2020 at 9:39:06 AM UTC-5, dagmarg...@yahoo.com wrote:
George H.
George H.
Guest
On Tuesday, February 18, 2020 at 10:10:25 AM UTC-5, George Herold wrote:
Everything is either simple, or impossible.
Cheers,
James Arthur
Everything is either simple, or impossible.
Cheers,
James Arthur
Guest
On Tue, 18 Feb 2020 00:17:40 -0500, "Tom Del Rosso"
<fizzbintuesday@that-google-mail-domain.com> wrote:
Presumably that was done at the start of a project, but it is often
done wrong. Especially when designing a new standard product. So an
occasional stop/think break could change the project direction.
Group-think and management discourage such re-assessments.
--
John Larkin Highland Technology, Inc
The cork popped merrily, and Lord Peter rose to his feet.
"Bunter", he said, "I give you a toast. The triumph of Instinct over Reason"
<fizzbintuesday@that-google-mail-domain.com> wrote:
Presumably that was done at the start of a project, but it is often
done wrong. Especially when designing a new standard product. So an
occasional stop/think break could change the project direction.
Group-think and management discourage such re-assessments.
--
John Larkin Highland Technology, Inc
The cork popped merrily, and Lord Peter rose to his feet.
"Bunter", he said, "I give you a toast. The triumph of Instinct over Reason"
Guest
dagmargoodboat@yahoo.com wrote in
news:b5522723-7a69-4784-9176-7f5fd7d87e23@googlegroups.com:
That's just Brown Ian motion. What a notion.
news:b5522723-7a69-4784-9176-7f5fd7d87e23@googlegroups.com:
That's just Brown Ian motion. What a notion.
P
Phil Hobbs
Guest
On 2020-02-18 09:39, dagmargoodboat@yahoo.com wrote:
Or two larger ones that partially cancel.
Cheers
Phil Hobbs
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510
http://electrooptical.net
http://hobbs-eo.com
Or two larger ones that partially cancel.
Cheers
Phil Hobbs
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510
http://electrooptical.net
http://hobbs-eo.com
T
Tom Gardner
Guest
On 18/02/20 15:54, jlarkin@highlandsniptechnology.com wrote:
I've often seen clients say they want X developed to
solve their problem Y.
After talking to them it becomes apparent that Y is
merely a symptom of the underlying problem and that X
isn't the best way of solving their underlying problem.
In bad cases, X won't even solve the underlying problem.
The clients you don't want are those are wedded to
X for reasons that they can't adequately explain.
I've often seen clients say they want X developed to
solve their problem Y.
After talking to them it becomes apparent that Y is
merely a symptom of the underlying problem and that X
isn't the best way of solving their underlying problem.
In bad cases, X won't even solve the underlying problem.
The clients you don't want are those are wedded to
X for reasons that they can't adequately explain.
T
Tom Gardner
Guest
On 18/02/20 17:45, Lasse Langwadt Christensen wrote:
I didn't realise it had been coded in those terms.
I first discovered it was a problem in ~1982, and had
no doubt that my discovery wasn't original.
It is just The Way People Are.
I didn't realise it had been coded in those terms.
I first discovered it was a problem in ~1982, and had
no doubt that my discovery wasn't original.
It is just The Way People Are.