The Skills of a Pro

[ondo]

Hi there, I'm currently reading "So good they can't ignore you" by Cal Newport, and that make me thing about the skills of a good engineer.

We have a lot of posts and stuff about the skills you need to have for a hobbist level, but not much about the skills that make one stand out in EE, and I thought it was something interesting to talk about.

I've been working for 5 years now in the field, and I don't have much of a clear answer. In fact, most senior I've worked with don't show much of a skill in the field. What's your take?


EDIT: Just moved this because I posted in the wrong forum (so many taabs!)

[John Coloccia]

Other than having basic core skills of your field, which is just a given, the best engineers also have a strong understanding of other fields as well. If you're EE, you should understand a lot about:

mechanical design
software
manufacturing
project management

It doesn't hurt to have a pleasant demeanor so you're not "that guy".

Overall, this will make you a much much stronger engineer, able to see the big picture and come up with solutions that work at the system level, not just on your board. The best engineers are problem solvers at their core. Electronics, software, mechanical widgets, whatever are just tools you use to solve the problems. The more tools you have in your tool box, the better your problem solving skills are. The worst engineers are the ones that lock themselves in their office and can't see beyond their own, tiny little task. These are the guys that are consistent problems in any team and are always very difficult to work with. Sometimes, they'll completely tank a project because you can't get them to change their designs to fit the bigger system. They're also often times quite strong in their own field, able to work their way through the thorniest of issues. It's good to have one guy like this on your team that can solve the really tough problems efficiently, but given a choice I'd take the well rounded guy any day of the week if I could only have one.

Sometimes you have that special someone that's truly an expert in their field, but can navigate everything else as well. If you can be THAT guy, be that guy. They're your stars.

Just my opinion.

[RobertHolcombe]

Its probably easier to list general qualities which make a professional great in any field than those specific to EE or even engineering since the possible skillsets you acquire in a job a so vast.

[KJDS]

When starting your career, make sure that you make your boss look good.

[Kjelt]

Perception.
If "others" around you think you are a pro, you are a pro. The bigger the "other" crowd becomes the bigger pro you become.
So in our company you are a junior engineer when you start, when you show skills and are recognized and acknowledged for those skills over some years you become senior engineer.
If you want to become principal engineer, everyone in the company you deal with has to recognize and ackowledge your skills and you must have some sort of specialty (you are the one to ask about that subject, you are the owner and know everything about that subject inside the company).
And if you want to grow to the top then you have to be recognized and ackowledged for your skills/specialty in a wide (preferably global) community (other companies/universities etc.).

So in short: networking and social skills esp. towards management, something a lot of engineers are not so good at, or like.
So some global experts can be recognized and acknowledged by other experts and their engineering peers and still be just a senior engineer in the company they work for because management does not get it or see it. All perception.

[BradC]

When starting your career, make sure that you make your boss look good.

I can't agree with this enough. I realised this about the same time I became my own boss (about 15 years too late). In my early career if I'd been less of an arrogant shit who was more concerned with pointing out the flaws in my superiors and more concerned with improving on my own I'd have gone a _lot_ further than I did.

[Mechanical Menace]

It doesn't hurt to have a pleasant demeanor so you're not "that guy".

In software it's important to know when not to be too pleasant and I can imagine there are similar situations in EE. Don't be scared of being "that guy" when you're sticking up for yourself or claiming credit for your contributions. If you're too nice you end up doing everyone else's work while they get the credit and rewards.

[ajb]

It doesn't hurt to have a pleasant demeanor so you're not "that guy".

In software it's important to know when not to be too pleasant and I can imagine there are similar situations in EE. Don't be scared of being "that guy" when you're sticking up for yourself or claiming credit for your contributions. If you're too nice you end up doing everyone else's work while they get the credit and rewards.

These two things work best in balance.  If you have a reputation for always being nice and helpful, people will take you much more seriously when you're not.  If you have a reputation for being curmudgeon, then people will start taking your major complaints as seriously as your minor complaints, which is to say not at all.  Also, "being nice" is not the same as being a doormat, or not being honest about problems. 

[John Coloccia]

These two things work best in balance.  If you have a reputation for always being nice and helpful, people will take you much more seriously when you're not.  If you have a reputation for being curmudgeon, then people will start taking your major complaints as seriously as your minor complaints, which is to say not at all.  Also, "being nice" is not the same as being a doormat, or not being honest about problems.

Exactly. I'm trained as a software engineer and did software, among other things, for about 20 years. If the only way you can get your point across is by being an jerk, you need to have a long, hard look at why.

[Mechanical Menace]

If the only way you can get your point across is by being an jerk, you need to have a long, hard look at why.

I totally agree if it's your only way. But sometimes you're dealing with jerks and can't avoid it. Not every problem is a nail, that doesn't mean you never need a hammer...

[John Coloccia]

If the only way you can get your point across is by being an jerk, you need to have a long, hard look at why.

I totally agree if it's your only way. But sometimes you're dealing with jerks and can't avoid it. Not every problem is a nail, that doesn't mean you never need a hammer...

Well, I'll grant you that engineering is not for people that don't like a good fight. I doubt there's a decent engineer out there that hasn't gotten into some pretty severe arguments or almost taken a swing at someone. I swear, there were some days I practically had to sit on my own hands to keep from doing something stupid.

[Tomorokoshi]

1. Ask questions when you need to.

2. Don't ask questions unless you already know the answer.

3. Understand that contradictions are a part of the work.

4. Give your boss trivial decisions to make so he doesn't make the important ones.

[rx8pilot]

When starting your career, make sure that you make your boss look good.

I can't agree with this enough. I realised this about the same time I became my own boss (about 15 years too late). In my early career if I'd been less of an arrogant shit who was more concerned with pointing out the flaws in my superiors and more concerned with improving on my own I'd have gone a _lot_ further than I did.

In my early years, I focused intensely on learning everything I possibly could. This just happened to make my boss look good, but that was a bi-product of my desire to learn how to solve any and all problems. During my on the clock hours, I focused on my job, and during off hours (approved by the boss), I would learn everyone else's jobs. It's not that I wanted to do their jobs, but ti was much easier to excel at my own job when I knew the big picture - what feeds my job and what my job feeds into. At that point, the boss was willing to share more big picture business concepts with me so I was able to understand the business as a whole. Shortly after, I left and started my own business (not competing of course) and never looked back.

Being a professional is a mindset. It is a mindset of seeking to be the best at what you do and do it with a pleasant attitude. It's not about having all the answers all the time, it's about knowing the right questions to ask and how to discover the answer. If you are an EE, the degree and book knowledge you get with that is merely the ticket that gets you in the door. As others have said, your job is to solve problems. To solve the problems, you have to able to know what the problem is and how to break it down into manageable chunks and then solve it. If you take the route I did and others have wrote about, you would have at least a solid working knowledge of peripheral fields - mechanical, management, IT, software, etc. I went a little overboard on that note and have a very broad skill set, that only goes so deep. I have been a contractor for over 20 years and so have a variety of experiences working from NASA/USA (Houston/KSC), Oil field, Medical, Manufacturing, Broadcasting, etc. I have seen first hand which people rise to the top and which ones are stuck.

Be pleasant.
Listen.
Make peace with the reality that you will never know all the answers.
Learn how to learn.
When it seems impossible, just wait a few minutes - solutions tend to arrive when you are are less focused on the problem.
Take the time to understand the perceptive of your peers. They may indeed be stupid, but you should let them prove it all by themselves.
Self-educate constantly. Read and explore the industry for information and new ideas. This will help at your current job or help you discover a better one.
Be a salesman - you have to sell the others on why they should jump on board with your idea instead the theirs.

[woodchips]

I hate to spoil the party, but I wonder if something is missing here.

I have just found Silberman's book Neuro Tribes about autism, simply because I recognise myself to some extent. Autism is known as the nerds diesease. I can visualise software to work through it to find bugs, never fails, I really don't think this is a normal thing to do. I have certainly met astonishingly good engineers who are also well rounded people, but I am not.

I think it is essential to be a generalist. But you have to be a good generalist. What does that mean? Well, look at Bruel & Kjaer, an audio company with a stellar reputation in test equipment design. What do I find? Pieces of equipment that are so poorly designed they are unrepairable, cables too short, can't get to PCBs to probe them etc etc. I did intend to write a post to try to document basic design requirments when the item is being put through production engineering, but not found time. Not really certain it would be of interest.

I think a pro has a certain 'feel' for the world, can know if something is unlikely to even start working. An example not engineering, is the Euro. You read back to the 1990's and you find lots of people saying it won't work, that countries will be borrowing in a foreign currency. All phoo phooed but look what happened. Some pros knew this was going to end in tears, no one listened. Like some aspects of engineering, my current puzzle is oversampling ADCs. I am working on some experiments to see if it really does work, because I can't see it whatever the semiconductor manufacturers write in their application notes. If it is an 8 bit ADC then that is what it is, reading it 16 times doesn't make it a 10 bit ADC. If I am wrong then that doesn't make me a pro, but I will have learn't a lot.

[KJDS]

Whilst having a general skillset is good, having some key areas of expertise is also essential.

On the oversampling of ADCs, you need to ensure that there is a couple of bits worth of random noise added to the signal, then run the maths.

[German_EE]

The local electric company were building a generating station in a small city, three of the turbines went in just fine but the fourth turbine had a really bad vibration problem when it was run up to 100% of full speed. They tried everything they could to fix this vibration problem but in the end they gave up and called in an engineer from the turbine manufacturer. After an overnight intercontinental flight and a six hour drive from the airport the man arrived and was shown the faulty turbine.

"Run the turbine up to full speed please" said the visiting engineer and the great machine started turning faster and faster until a low rumble could be felt through the concrete floor. Pulling a stethoscope out of his toolkit the engineer held the business end against the turbine case and then removed it. He then pulled a stick of chalk from his pocket and placed a neat cross on one of the large bolts holding the turbine to the floor.

"You need to place a 0,2mm shim under this support, after that you will be fine" he said. He then turned around and asked to be taken back to the airport.

A week later they received an invoice for $20000 dollars for the engineer's services. Some concern was expressed as the man had only been in the plant for thirty minutes, just long enough for the turbine to run up to speed and for him to place that chalk mark. They therefore asked the turbine manufacturer for a detailed invoice and in due course one was supplied:

One chalk mark..................................$0,01
Knowing WHERE to place
the chalk mark.............................$19999,99

TOTAL........................................$20000,00

The invoice was paid.

[f5r5e5d]

Like some aspects of engineering, my current puzzle is oversampling ADCs. I am working on some experiments to see if it really does work, because I can't see it whatever the semiconductor manufacturers write in their application notes. If it is an 8 bit ADC then that is what it is, reading it 16 times doesn't make it a 10 bit ADC. If I am wrong then that doesn't make me a pro, but I will have learn't a lot.

your formulation above is rather backwards - doesn't take much reading, looking at products using delta-sigma ADC/DAC to see that "it works"

you should quickly concede there's something you're missing in your current formulation that you need to find out

knowing what can be done even if you don't currently understand how is needed to plan in product development

knowing how to find out what you need to learn to make something work, estimating the difficulty, knowing when to get expert help are all part of the engineering process


I see all too many coming to technical forums with misconceptions and demanding that people trying to help them learn must "prove them wrong" starting from their misunderstanding, misstatement of principles, the problem, problem domain

when they are off the map into "not even wrong" it simply can't be done

[ondo]

Thanks all for your input, it will be useful in the future 

While my current situation is a bit tricky and "make your boss look good" is kind of impossible, I'll be sure to do so in the future.

my current puzzle is oversampling ADCs. I am working on some experiments to see if it really does work, because I can't see it whatever the semiconductor manufacturers write in their application notes. If it is an 8 bit ADC then that is what it is, reading it 16 times doesn't make it a 10 bit ADC. If I am wrong then that doesn't make me a pro, but I will have learn't a lot.

With that I can actually help. The key is keeping in mind that noise exists.

Let's say we hook up our 8bit ADC so that full range represents 1,024V. Then, our voltage resolution becomes 1.024V/2^8=4mV. Now we try to mesure a 622mV signal. This point is actually between 155 (620mV) and 156 (624mV). If we assume there's 2mV (white) noise in our signal (since our resolution was 4mV, we're still OK), half of our samples will read 155, and half of them will read 156.

 By taking to readings and averaging you get 155.5 (the original 622mV). By doing that you've effectively halved your minimum step to 2mV, so your new resolution becomes 9 bits. If you increase the samples by multiples of 2, you get increasing bit gains for your resolution.

When not enough noise is present, some solutions actually add it (dithering).

[John Coloccia]

FWIW, if your boss is smart, he'll be trying to make YOU look good. That's what I did when I was a manager. Who looks better: an insecure manager that has to "do everything himself" leading a team of idiots, or a strong leader leading a team of superstars? I guess there's not much you can do about that now, but keep it in mind as you grow your career. IMHO, you want to be managing the all-star team, or at a minimum you want everyone to think that. 

[zapta]

the chalk mark.............................$19999,99

That's a good one.

Though, a monkey with a chalk would eventually do the mark at the right place so it's cost is not just for that chalk mark (recall) but also for the lack of all the other possible chalk marks (precision).

https://en.wikipedia.org/wiki/Precision_and_recall

[woodchips]

Ok, leave me with the puzzle. Now found a few 12 bit ADCs to play with.

To widen the pro decision making. You are supplying a mixing system that mixes, say, 100kg or so of stuff. The ingredients are added to a certain weight and then mixed. My use of strain gauge load cells is old, but I recall that the best accuracy you can get from one is 1 part in 2000. Note, accuracy, not resolution.

You are advising the supply of this system. How many load cells under the mixing bowl would you use? Are there any advantages in using more than one?

Because it is part of a production process then having a local ADC controller is a good idea. How many bits? If the requirement is to measure to 1%? Or 0.1%? How does the dead weight of the mixing bowl affect your calculations? What alternatives to strain gauge load cells are available?

I know it seems trivial, but we all have to start somewhere so the decision process might be of use to other forum people. But this is a job where your competance is on the line, do you want complaining phone calls becaude it can't mix correctly?

[woodchips]

The attached photos are of a piece of military electronics. You would have thought that the bent chip leg would be detected in any eyeball inspection?