Looking for Best Practices for Design Engineers - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Looking for Best Practices for Design Engineers
Hi Anton,

Quoted text here. Click to load it

This unfortunately does not address the proprietary database issues.
Remember the Domesday project. Do you happen to have a BBC
Microcomputer with an LD player attached? :)

I used to be a big fan of doing everything electronically, but it's
proven to be much more trouble than it's worth.

I still do archive my invoices, tax returns, credit card statements
etc. electronically - but then I only expect to need them for at most
seven years.

Quoted text here. Click to load it

For general work, I have a series of logbooks describing what I'm
working on. More like a diary than anything else; these are scratchpad
books where anything and everything can be sketched and annotated. The
books are not project-specific.

Once I work something "final" out from my scratchings in the logbook, I
transcribe the "finished" circuit, calculation, or whatever, into the
appropriate project file. Of course, it might get some polishing once
inserted into the real product.

The customer gets a copy of the project file on CD-R as part of the
deliverables.


Re: Looking for Best Practices for Design Engineers

Quoted text here. Click to load it

I'm trying to get the discipline to use Keynote:

 http://www.tranglos.com/free/keynote.html

Nice little program, and free.



Re: Looking for Best Practices for Design Engineers

Quoted text here. Click to load it
best
or
recent
should
Tell
sure

Thanks for the reference.  I'll try it.

When I started engineering, everything went into an engineering notebook.
Some of my old ones are scrapbook collections of meeting notes, lab setups,
Polaroid scope pictures, business cards, fortune cookie papers, etc.  I also
developed a three-ring binder habit - all papers I got related to a project
were punched, sorted, and bound.  Some big projects expanded into multiple
volumes - hardware design, firmware design and listings, part-list
histories, component data sheets, etc.

A few years back I started keeping a daily log on my desktop pc - just a few
notes that describe what happened that day, with contact names, email
addresses, web links, phone numbers, etc included.  I make a new file (a
Word document) every month - the current one is log0506.doc.  It's much
easier to search than a notebook.  I still use the notebook for lab sessions
and the like that may need dated, witnessed data plus the three-ring binders
(4 so far on the current project which started in January and should have
ended by now).  I have a separate project folder on my pc, with subfolders
for hardware, software, meetings, etc.  One folder holds copies of pdf
datasheets for the parts in the design, and I no longer have the need for 4
6-foot bookshelves full of databooks.

For firmware design/documentation, I start with a written specification (in
MIL-490 standard outline).  If you can't write a spec, you don't know what
you're going to do, so don't start.  Usually the first design step is a set
of Visio flowcharts, showing a simple overview of the code functions, and
then detailed charts of any state machines (circles labeled with state names
and arrows labeled with state-transition criteria).  I code directly from
the state machine diagram into a switch/case structure in most cases, with
give and take between the two until they match up.



A




Re: Looking for Best Practices for Design Engineers


Quoted text here. Click to load it

I have never really tried it, I still use real paper,
but you can actually make drawings and write text,
on a graphic tablet like :

http://www.octapc.com.au/prod2811.htm

A german collegue also used a whiteboard on which he wrote
with a special pen and when he pressed a button, the content
was saved in a file or sent by email. This was used during
videoconference sessions and that looked very high tech;)


Re: Looking for Best Practices for Design Engineers
Quoted text here. Click to load it

Just use your editor.
I use my Favorite Text Editor (edwin editor: ee) for as long
as I can remember for project logs.
As a bonus it is easy to paste in data from program
files, but I find myself mostly using different sessions for
programming and logging.

This is a sample from today and yesterday:
--------------------------
2005 jun 22 wed
* make a 4.2 directory.
* test all.
* add a solution for namescooked and constant stuff.
* add make clean to Makefile, that really removes all generated files

make cleanall now really deletes everything.
Remains
- use that to automatically clean 4.1 old ci86 and 4.0 directories
* make sure namescooked works okay
- delete assembler files from 4.2 aka cvs root
- delete dieren files from 4.2 aka cvs root
- delete superfluous files from cvs root
- use that to further clean 4.1 old ci86 and 4.0 directories
- script that moves non-doubles to a single directory.
- move loose items into library file

2005 jun 23 thu
There is a difference now between the archive of e.g. as6809s.frt
in ciasdis and cvs, caused only by the introroduction of version 5.1
what a pity!
First: get a good split w.r.t. assembler.
* delete assembler files from 4.2 aka cvs root
"
 CVS: Removed Files:
 CVS:    testset8080 testset8086 transforms wc
 CVS:    ass.frt ps.frt testas386a testset386 testset386a testset6809
 CVS:    as6809.frt as80.frt asalpha.frt asi86.frt asm386endtest
 CVS: ----------------------------------------------------------------------

 Files related to the PostIt FixUp assembler are now sourced at ciasdis.
 What is left here is a symbolic reference to the ciasdis files.
 README.assembler reflects this.
 At last wc is renamed to mywc.
"

In Makefile.add is a list of files that have to be cleaned with ``make
cleanall' but currently aren't.
-------------

Invaluable 10 weeks down the road.

Quoted text here. Click to load it


--
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
We've slightly trimmed the long signature. Click to see the full one.
Re: Looking for Best Practices for Design Engineers
On 23 Jun 2005 17:39:46 GMT, Albert van der Horst

Quoted text here. Click to load it

This is fine for keeping track of software status, but for schematics
etc. A way to handle sketches and other material is desirable. I
currently keep PDF versions of schematics and PCB overlays, and
scan read-line drawings to pdf to keep in electronic format.

Regards
  Anton Erasmus


Re: Looking for Best Practices for Design Engineers
Quoted text here. Click to load it

I think you are looking at this the wrong way. There are considerable
benefits to being what you are calling a "bad" engineer:

* You finish faster if you don't document your code.

* You get "somewhat working" code up and impressing executives with
  demos faster. Then, you can relax and soak up that paycheck with
  those months upon months of "small fixes" to the product, during
  which you will be rewarded for your outstanding bug fix rate.

* Your job is secure. Nobody can understand your code.

* By the time anyone in management realizes that the code is FUBAR,
  you will be gone to another company, with star status and higher
  salary, or you will be in the management of your current company,
  and can blame in on your employees. Its win-win.

* More than half of products don't make it to market anyways. Why
  waste time on something that is never going to ship ?

* Most "first approaches" are wrong in any case. The code will have
  to be rewritten, so why spend a lot of time on it.

* Managers don't read code, so less documenting means more time
  to suck up to the boss.

And on and on. The co-workers who you put down for not documenting
are smart. You will become more and more angry as you watch
them rewarded for their successes and promoted to be your manager,
at which time they can have you fired for your bad, continuously
complaining attitude.

"There is no shame in mediocracy... I am the patron saint of
mediocracy!" [From "Almadeus"]


Re: Looking for Best Practices for Design Engineers

Quoted text here. Click to load it

Excepty when the code MUST pass certification for the application it is
being incorporated into. Then, lack of documentation is going to cost you
plenty of sleepless nights while you try and figure out why certain curious
things keep happening unexpectedly; especially if the customer witholds
payment until the whole deal is right.
 
Quoted text here. Click to load it

Only if they haven't closed off your escape route first.
 
Quoted text here. Click to load it

So you work for companies that waste your and their time on useless stuff
from the get go. The saner ones do some elementary market research and
product requirements determination before they start down the design and
build road.
 
Quoted text here. Click to load it

So why write code before you understand the requirements? Do the work in
the right order and you spend less time re-writing. You should, after a
while, get better than 80% right first time (so only 20% might be in for
the second run).
 
Quoted text here. Click to load it

Sucking up is something I never have to do. I am currently working as an
integral part of a larger team and feel I am well respected by my
colleagures and the upper management (to the point I even lunch with the
CEO on occassion).
 
Quoted text here. Click to load it

I get the feeling that a smiley or two was missed out somewhere along the
way.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Looking for Best Practices for Design Engineers
On Tue, 14 Jun 2005 18:52:23 +0100, "Paul E. Bennett"

Quoted text here. Click to load it
[Snipped]
Quoted text here. Click to load it

There is a very good reason why a comic strip like Dilbert exists and
why it is so popular with technical people. Most companies have some
aspects with the Dilbert world - otherwise people would not relate.
As in everything one gets cases on the extrem ends. If one ends up at
a company where the company is at the Dilbert end of the extreme, then
the only way to survive in such a company is to follow the previous
posters advice. It takes a long time, and dedication to build up an
organisation where things are done as they should be. It is amazing
how fast such an organisation can end up at the Dilbert end of the
spectrum when one of the top level managers is a bad apple.

Regards
   Anton Erasmus


Re: Looking for Best Practices for Design Engineers
Quoted text here. Click to load it

A simple rules in this business is that you only
touch what brings you the laurels.
So if none acknowledges documentation, don't do it.
If none acknowledges optimal code, don't do it.
And so on.
Why should you behave different to your CEO which
only optimizes the quarterly results ?

Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Re: Looking for Best Practices for Design Engineers
in the private sector it varies, generally with the size of
corporation. High turnover large corporations have well documented
design practices and well documented list of documents that must be
produced as part of the project. Smaller corporations tend to have very
little formal documentation (unless its required as part of the
contract). Generally the smarter engineers know exactly what they need
to document to be successful and the dumber engineers don't, and
forcing the dumber engineers to document their work just results in a
pile of worthless incomprehensible documentation.


Site Timeline