EE electroic engineer designer basics please

[Doug_H]

I don't work the commercial side, I do embedded sys s/w stuff for govt/aerospace. On one project I did, the way we handled requirements creep was to put a prototype out in the field that the customers could play with while we were developing the real system in the lab. That wasn't as burdensome as it might seem, they just got dumps of our lab code when we did new releases and we supported them during operations with it, which were sporadic. This helped give them a reality-check of the capabilities they would have and helped us understand their real requirements and operational environment better. Instead of getting hit with a laundry-list of "stuff they wish we had done" at the last minute, we were able to make small tweaks and course-corrections along the way as we developed the system. It ended up being very successful and they gave us a 99% rating on a customer survey we did after we turned it over. I don't remember what we got dinged the 1% for.

I realize this is a different situation than the typical commercial setup where you have the marketing-sales-team promising everyone the world and etc. Even though its more of a closed and contained environment you still might be surprised. I've had projects cancelled due to out of control requirements creep combined with politics because the right people didnt' show up to the right meetings and etc, etc. In the end a lot of it comes down to how strong (competent) your project management is.

[R.G.]

That is a great way to work if your customer is tolerant of it. We did that with some university research people as "customers" on my skunk-works megacomputer back in the day. They liked it a lot.

Some customers cannot tolerate a try-and-tweak approach. In general, business oriented applications such as inventory tracking, accounting, anything where there are dollars and cents immediately in the balance are intolerant. Customers who are themselves developing applications or who are developing research or one-time results are generally more tolerant of tweaks along the way.

And remember, Bill Gates became the wealthiest man on the planet, worth more than the GDP of many countries, by promising us everything, then giving us Windows, a little dribble at a time, and convincing us that really, no fooling, the next release would work better and be more resistant to hacking. So dribbling can be good business, too.

[mojotron]

Another 'long time ago', I worked for a huge company on a CPU debugger that literally had to be perfect in it's core features - that project had crazy amounts of process over-head on everything, but we always had rock-solid requirements and were expected to deliver flawlessly on schedule - slipping schedules on hardware, FPGAs, firmware and software was, for the most part, unacceptable. Some people really liked working in that environment because there were no suprises and all of the engineers all of the resources they wanted, used the very best tools and techniques. I initially thought this was pretty cool, but as time went by, I really wanted to do something where I had fewer constraints and moved on.

This was a great experience for me to learn how to do things absolutely 'the right way' - but I was not excited about the work I was doing. And, I also discovered that when there is a situation where you can get all the right resources/time to do things right - you have to deliver to a whole new level of expectations. All of that is good stuff, but it wears on you after a while because people are not perfect and are going to screw up form time to time - and that leads to a threshold of anxiety that is difficult to manage.

From there I worked in a 'lab' job where I did rapid prototyping doing all kinds of HW and lowlevel SW work - the expectations were quite low for the engineering that got done - but everyday was something different. I got tired of that too, there was no real engineering going on with that stuff because there was really no product - all we did was file patents and write papers. Some people really like the freedom of that situation too, but I really wanted something much more sane.

From there I worked for startups and other situations... I know the situation John describes very well, where sometimes you have to do what you have to do for a bunch of very good reasons, few of which are good engineering reasons/decisions. I think what R.G. mentioned about engineers knowing a lot more about the business decisions rings very true with my experience. I think I have found a good balance between innovation/freedom/process/management for me in my current job because I work with a bunch of people (from the top down) that seem to understand that everyone in the organization has to support good engineering practices at all levels to get things done.

[Doug_H]

That is a great way to work if your customer is tolerant of it. We did that with some university research people as "customers" on my skunk-works megacomputer back in the day. They liked it a lot.

Yeah, this was a skunk-works environment I used to work in. I really loved that. We did some good work.

Some customers cannot tolerate a try-and-tweak approach. In general, business oriented applications such as inventory tracking, accounting, anything where there are dollars and cents immediately in the balance are intolerant. Customers who are themselves developing applications or who are developing research or one-time results are generally more tolerant of tweaks along the way.

Yes, it all depends on the business you're in. In this case it was replacing some old 1968-vintage "apollo control room" technology. The customers/operators were all near retirement and among other things, pretty computer illiterate at the time. A few years ago I had to review the system for return to flight and in the process asked one of the "new, young" operators what they still thought of the system. He gave it a big thumbs-up- that made me feel good.

And remember, Bill Gates became the wealthiest man on the planet, worth more than the GDP of many countries, by promising us everything, then giving us Windows, a little dribble at a time, and convincing us that really, no fooling, the next release would work better and be more resistant to hacking. So dribbling can be good business, too.

I suspect people in general have a better understanding of vaporware promises these days, partially due to the popularity of personal computers that Mr. Gates had a part in.

From there I worked in a 'lab' job where I did rapid prototyping doing all kinds of HW and lowlevel SW work - the expectations were quite low for the engineering that got done - but everyday was something different. I got tired of that too, there was no real engineering going on with that stuff because there was really no product

I've done projects which were more R&D oriented, trying to develop or apply a new technology, etc, with a report or demo as the "product". They were fun while I was working on them but when we finished I missed that satisfaction I got from "producing"- that is, turning something over to a customer and seeing them actually use it. I get a deep satisfaction from knowing there is stuff out in the field being used today that I had a hand in- where there is documentation, source code, etc that has my name in it.

[markphaser]

I'm mostly looking for a list that are 10 or 20 most common designer issues and designer PCB or layouts problems

[puretube]

the biggest is: TIME

(or rather: the lack of...)

[R.G.]

I'm mostly looking for a list that are 10 or 20 most common designer issues and designer PCB or layouts problems

What lot of the replies here have been about is, loosely stated, the fact that it is impossible to give you that. There are ten to twenty THOUSAND most common problems. This is not like finding the ten most important things about baking bread, or sailing a schooner, or things to take on vacation with you. In any given design problem you will have to use a different set of most important things. You can only list meta-issues as the most important design issues or problems.

I'll do a representative list of those for you, though.

Top Ten electronic design meta-issues:
1. Knowing when to stop
2. Knowing who to call.
3. Knowing who's paying the bills
4. Knowing what minimum features must be met and what features are negotiable.
5. Knowing what the maximum allowable cost is.
6. Knowing what the maximum allowable completion time is.
7. Stopping feature creep.
8. Recognizing all of the stakeholders
9. Recognizing the political realities of the project
10. Knowing technologies which can be used.

Notice that the least important of the top ten is anything to do with the actual technologies.

Of course, that's not what you wanted to know. What you wanted to know is that equations to solve, what procedures to do, what tricks to do in design. That stuff is a set of minimum requirements. It's on the bottom of things you need.

It is not most important to know Ohm's law, or to be able to say why dual opamps are better than singles or quads, or to know what PCB trace thickness is needed. But it is mandatory. If you know all of this lowest level stuff but not any of the top ten meta-issues, you will fail. If you know all of the top ten, and expecially 1, 2, and 3, you will probably be successful in spite of not knowing the minimum requirements. I've seen people who don't have a clue about how to design a memory chip, lay out a board, do a thermal analysis, compute an error budget on an A-D converter and a million other things be successful because they knew the first three.

There is another way for you to answer your own question. This forum is a treasure trove of things that can and have gone wrong in making effects. If you find and list the most common things that have gone wrong with an effects design, those will be the most important things to get right, and you have your list. Just do a search in the archives.

[markphaser]

why dual opamps are better than singles or quads?

This seems like more the R&D Buyer/sales persons job they handle all of this:
Top Ten electronic design meta-issues:
1. Knowing when to stop
2. Knowing who to call.
3. Knowing who's paying the bills
4. Knowing what minimum features must be met and what features are negotiable.
5. Knowing what the maximum allowable cost is.
6. Knowing what the maximum allowable completion time is.
7. Stopping feature creep.
8. Recognizing all of the stakeholders
9. Recognizing the political realities of the project
10. Knowing technologies which can be used.

[puretube]

a good designer is the best R&D buyer...



a dual got least pins for most function without routing probs...

[R.G.]

MP,

If you, as the designer, do not know these things, no matter what you design you will be late with completion, not have a suitable price/performance, be over budget, have the wrong features (as seen by the people who pay your salary) not have enough features, have "defects" as seen by the customers, and your bosses will be furious.

Believe me, if you are a designer and the buyer does all this for you, you'll get fired; it's certain that you *should* be fired.

Please understand; I'm telling you the straight facts. I wish I had learned these in college instead of painfully over three decades of engineering practice. Let me repeat:

And markphaser, I was not being snide or snotty to you. I was telling you the literal truth. These days, an EE who has no concept of project management is going to have a very difficult time holding on to a good job, and will certainly not get ahead in the organization. It's not enough to know the equations and real world practice of electronics. You have to learn the economics of engineering design, the management and scheduling of projects, and the politics of  your organization.

I have a good book for you to find and read. Go look up and read the PMBOK, the Project Management Body of Knowledge. It'll be very enlightening.

[markphaser]

Not at the most jobs i worked at the R&D buyer did all that hard work i done intern at many jobs i never seen the electronic EE designer worry about how much the parts were going to cost thats not his jobs and doing the accounting also please R.G u must have worked at really really small companies

[R.G.]

So tell us MP, at what companies did you intern, what kinds of things did you do?

[The Tone God]

Dang it. R.G. beat me to it.

Andrew

[R.G.]

Sorry - I would have waited had I known. 

[markphaser]

i intern doing testing,checking,troubleshooting from technical write ups from the R&D department of various stuff different products the technical write up tell u what to do and how and where to measure plus with the new digital oscilloscope its even easier. I then intern for school at various jobs in the R&D departments and watched engineer asst. which they prototyped the new product mostly like 10 or more people in the R&D department doing different tasks like buyers,schematic software drawing,software simulations,C++ programmers,a couple of EE math guys to do the analysis of the circuit beyond ohms law, PCB simulation program, trace,routing software programs,i just mostly watched and asked questions and helped out it was internships for school

Your saying its one guy doing all this and i have to disagree with u again there is no way one guy can do all this. If my questions were saying what is a R&D department thats another story but i asked only about PCB design issues and PCB problems

 

[R.G.]

i intern doing testing,checking,troubleshooting ... it was internships for school

Cool!

What school and what company was this?

[StephenGiles]

What is "intern"? Please forgive my simple English brain, but I thought doctors were interns before they qualified.

[StephenGiles]

Ah, it's an unpaid slave!!

[gez]

Stephen, aren't we all 'interns' at the end of the day??

[StephenGiles]

You could be right there!! I remember when I first heard the word "intern" - it was on Dr Kildare in the 60s.