Maker Pro
Maker Pro

Best Practices for Hardware Engineers

P

Paul Hovnanian P.E.

Jan 1, 1970
0
Jim said:
Hello, I have a list of Best Practices for Hardware Engineers that I
would like anyone to look over and tell me what you think or what
should be added to the list.

Here is my list in no particular order
[snip]
7. If a standard exits then follow it.

I like that one ;-)

I always follow MIL-TFD-41C....


make it like the * drawing for once.
 
P

Paul Hovnanian P.E.

Jan 1, 1970
0
John Jardine. said:
Hello, I have a list of Best Practices for Hardware Engineers that I
would like anyone to look over and tell me what you think or what
should be added to the list.
[...]
joe
This same question, in the last couple of years has turned up twice.
It reeks of residence within some management diploma course module.
Specifically, that module that that dreams it can teach up and coming,
thrusting, young pointy haired managers, how to enforce structure and
organisation onto those bolshie, engineering slob types.
john

It reeks of management asking their staff to document their work
processes in hopes of handing said documentation to a production
facility in someplace like Saipan and hoping to get the same result.

The great thing about that is; when they discover their mistake and hire
that staff back as consultants, the salary has more commas in it.
 
J

Jim Thompson

Jan 1, 1970
0
On Wed, 31 May 2006 22:17:28 GMT, "Wayne Lundberg"

[snip]
So yes... a lot of great engineering comes from braking the rules.

And even more comes from breaking the rules ;-)

...Jim Thompson
 
P

Paul Hovnanian P.E.

Jan 1, 1970
0
Wayne said:
Richard Henry said:
On Wed, 31 May 2006 21:46:22 +0100, "John Jardine."


Hello, I have a list of Best Practices for Hardware Engineers that I
would like anyone to look over and tell me what you think or what
should be added to the list.
[...]
joe

This same question, in the last couple of years has turned up twice.
It reeks of residence within some management diploma course module.
Specifically, that module that that dreams it can teach up and coming,
thrusting, young pointy haired managers, how to enforce structure and
organisation onto those bolshie, engineering slob types.
john


An 8-item list of how to do engineering would be like an 8-item list
that tells you how to replace a kidney or how to land a 747.

Besides, good engineering usually involves breaking rules.

Is that a rule?
If you look at almost any innovation you will see the new idea or method
came from outside the normal established procedures. Look at the transistor.
It took years for vacuum tube engineers to realize the true potential of the
transistor. Sony is the one to recognize it and licensed it and look what
happened.

It wasn't Sony, it was a couple of sailors on a Japanese submarine. I
know, I saw it in the movie "1941". They were off the California coast,
trying to stuff a captured vacuum tube radio through their submarine
hatch and one of them said to the other, "We've got to find a way to
make these things smaller".

;-)
 
L

legg

Jan 1, 1970
0
Hello, I have a list of Best Practices for Hardware Engineers that I
would like anyone to look over and tell me what you think or what
should be added to the list.

Here is my list in no particular order

1. Always have a top block diagram, in your schematics and in your FPGA
code
2. Follow the System Engineering Design Process Model
3. Document, Document, Document your work
4. Modularize your work
5. Try a Top Down design approach instead of Bottom Up
6. Ask for Peer Reviews and code walk throughs
7. If a standard exits then follow it.
8. Manage time, don't let time manage you.
<snip>

Depends on whether the hardware engineer is the dog; is the tail; or
is just something somewhere on that tail.

RL
 
J

John Perry

Jan 1, 1970
0
Luhan said:
John Larkin wrote: ....


Hey, thats a good one. I wrestled back and forth with one client for
weeks as they gave me vague and conflicting functions for the product.
Maybe, let *them* write the manual first!

Absolutely not! They're hiring you because you know how to make things
work, and they don't (that's why you had so much trouble getting good
specs). _YOU_ write the manual first, so you can show them how the
thing will work when you're finished. Then if they don't like what
you've given them, you write another version -- that you know you can
make work -- so they can verify it's what they need and buy off on it.
This process of give-and-take makes good specs out of mush.

Then nobody has excuses, and almost all customers will be happy.

John Perry
 
J

Jeroen Belleman

Jan 1, 1970
0
John said:
The only rules you can count on are conservation of energy and
conservation of charge, and I'm not sure about that last one.

Conservation of misery, also. Like when the only possible solution
to a problem introduces another problem, just as nasty.

Jeroen Belleman
 
M

Mike Monett

Jan 1, 1970
0
Jeroen Belleman said:
Conservation of misery, also. Like when the only possible solution
to a problem introduces another problem, just as nasty.

Jeroen Belleman

That is relly funny:) But brick wall problems are the hardest to solve.

That's when the flash of insight hits when you are taking a shower or doing
something completely unrelated.

Then you slowly start to grin from ear to ear. What a marvellous feeling!

Regards,

Mike Monett
 
X

xray

Jan 1, 1970
0
That is relly funny:) But brick wall problems are the hardest to solve.

That's when the flash of insight hits when you are taking a shower or doing
something completely unrelated.

Then you slowly start to grin from ear to ear. What a marvellous feeling!

Really!

Have had that one a few times.

9) When completely stuck, go home, get a night's rest, and take a long
shower.
 
X

xray

Jan 1, 1970
0
Depends on whether the hardware engineer is the dog; is the tail; or
is just something somewhere on that tail.

Once upon a time, I think they were the reason for a company to exist.

Recently, the world has been remodeled. But maybe we already have all
the stuff we really need. Engineers are only needed to make it smaller.
 
P

Pooh Bear

Jan 1, 1970
0
xray said:
But maybe we already have all the stuff we really need.

I think some ppl believed this in the 1920s / 1930s too.

Graham
 
F

Frithiof Andreas Jensen

Jan 1, 1970
0
Hello, I have a list of Best Practices for Hardware Engineers that I
would like anyone to look over and tell me what you think or what
should be added to the list.

0) There are two kinds of employees: Earners and Overhead - and
Overhead loose.

1) Find Out what *really, truly matters* to the business, then become
good at that.

2) Find Out how things *really* gets done - this will *not* be the way
of the official process!

3) *Pretend* to live by the official process; management spend vast
amounts of ressources on it, so it must be good or mangement are
fools. Remember the Japanes proverb: "The nail that stick out gets
hammered"!

Straying from the above - letting QA and similar agents of the
deciever lure you away from the true path - will mark you up as
"Overhead" !!
 
F

Fred Bloggs

Jan 1, 1970
0
I'm always trying
to think of practices that can help me manage complex tasks and hope to
hear from others how they do it.

The fact that you use the adjective "complex" to describe the task means
you are not fit for the job. The entire purpose of engineering is to
*make* things, and fundamental to *making* anything is devising a
developmental architecture *simple* enough to facilitate a successful
implementation. This will be more or less of a challenge as a function
of the capabilities of the employees. No amount of simplification will
be sufficient in your work environment, the norm is total and consistent
abject failure, and introducing "process" to the equation is just that
much more overhead, an impediment, and yet another contributor to the
inevitable failure of the entire project- take failure to mean
unworkable, years late, ridiculously expensive, and technologically
obsolete.
 
John said:
Hello, I have a list of Best Practices for Hardware Engineers that I
would like anyone to look over and tell me what you think or what
should be added to the list.
[...]
joe
This same question, in the last couple of years has turned up twice.
It reeks of residence within some management diploma course module.
Specifically, that module that that dreams it can teach up and coming,
thrusting, young pointy haired managers, how to enforce structure and
organisation onto those bolshie, engineering slob types.
john

An 8-item list of how to do engineering would be like an 8-item list
that tells you how to replace a kidney or how to land a 747.

Besides, good engineering usually involves breaking rules.

John

John,

Hello, thanks for responding to my list. You are right, an 8-item list
is too small. Could you add some items from your experiences that
enabled you to produce a successful product. What are some rules that
you've broken to achieve success?

Thanks, and keep the comments coming.
joe
 
Fred said:
The fact that you use the adjective "complex" to describe the task means
you are not fit for the job. The entire purpose of engineering is to
*make* things, and fundamental to *making* anything is devising a
developmental architecture *simple* enough to facilitate a successful
implementation. This will be more or less of a challenge as a function
of the capabilities of the employees. No amount of simplification will
be sufficient in your work environment, the norm is total and consistent
abject failure, and introducing "process" to the equation is just that
much more overhead, an impediment, and yet another contributor to the
inevitable failure of the entire project- take failure to mean
unworkable, years late, ridiculously expensive, and technologically
obsolete.

Fred,

Thanks for responding to my post. So far it looks like it has angered
many and was not my intention. My intention was to "learn" from others
concerning their successes. Let's say a new engineer showed at your
work. I'm sure you are a very knowledgeable and successful engineer.
What advice would you pass on to him/her concerning success? How do you
measure success? If its not a list of items or habits, then what is
your response? Not to be mean, but do you practice what you preach and
go around your workplace and tell others, "your not fit for the job"?
Or, you pass on some words of wisdom? Anyways, thanks for your
suggestions, it is a good topic, Best Practices, and I'm finding a lot
of important views on engineering.

Thanks Fred,
joe
 
F

Fred Bloggs

Jan 1, 1970
0
John said:
Hello, I have a list of Best Practices for Hardware Engineers that I
would like anyone to look over and tell me what you think or what
should be added to the list.
[...]
joe


This same question, in the last couple of years has turned up twice.
It reeks of residence within some management diploma course module.
Specifically, that module that that dreams it can teach up and coming,
thrusting, young pointy haired managers, how to enforce structure and
organisation onto those bolshie, engineering slob types.
john

An 8-item list of how to do engineering would be like an 8-item list
that tells you how to replace a kidney or how to land a 747.

Besides, good engineering usually involves breaking rules.

John


John,

Hello, thanks for responding to my list. You are right, an 8-item list
is too small. Could you add some items from your experiences that
enabled you to produce a successful product. What are some rules that
you've broken to achieve success?

Thanks, and keep the comments coming.
joe

HEHEH! Hey , John- write more!- You know how most of us just like to sit
around and mental midget over amorphous, unstructured, undefined,
philosophical crap- I believe these sessions are called "meetings"-
better you than me:)
 
M

mc

Jan 1, 1970
0
"Best practices" are for things that have already been designed and
debugged, such as maintenance tasks. The job of an engineer is to *invent*,
to create things that do *not* already exist.
 
M

me

Jan 1, 1970
0
Fred,

Thanks for responding to my post. So far it looks like it has angered
many and was not my intention. My intention was to "learn" from others
concerning their successes. Let's say a new engineer showed at your
work. I'm sure you are a very knowledgeable and successful engineer.
What advice would you pass on to him/her concerning success? How do you
measure success? If its not a list of items or habits, then what is
your response? Not to be mean, but do you practice what you preach and
go around your workplace and tell others, "your not fit for the job"?
Or, you pass on some words of wisdom? Anyways, thanks for your
suggestions, it is a good topic, Best Practices, and I'm finding a lot
of important views on engineering.

Thanks Fred,
joe

It have not noticed any really angry responses. Just people telling you
that your list is not of much use, if not outright foolish...
 
Top