Looking at the silver lining, having a senior engineer vouch for the fix is a good stepping stone for a junior engineer on the way up. Of course it would be even better if a good engineer was included in management.
A great description of the troubleshooting process and an elegant fix. Good story!
Having someone to "vouch" for the solution was management's way of avoiding responsibility if any problems arose. The veteran engineer was showing either faith in the junior engineer's ability, his ability to comprehend the problem and solution, his leadership, or some combination of all of these. The junior engineer should have been recognized for his inquisitiveness and cost sensitive fix. The veteran should have been recognized for his skill and possibly mentoring the junior engineer.
The concept of having somebody "vouch" for my engineering successes is something that I have often found offensive. After all, didn't they read my reports, which gave very detailed explanations of what the problem was actually found to be, and then a detailed explanation of the solution, followed by an explanation of the functioning of the solution. On the other side, it was often amusing to see that they had so little understanding of what was going on that they had to ask others about it.
Reminds me of one of my favorite sayings: "What is my wisdom if I'm commanded by fools" and a term I use a lot when referring to large corporations: "Corporate constipation by policy". While I was still a technician, back in the early 60's, for General Electric X-Ray Division, I designed and built some clever and effective test equipment (I worked in the component test lab where we tortured resistors, capacitors, etc. until they failed). But since "technicians" couldn't be more clever than the engineers they worked for, my boss took all the credit. Today, I'm a successful analog design engineer (still no degree) with lots of products and several patents to my credit. These days, I do a lot of lecturing (including one at MIT) about system and circuit grounding and my specialty, balanced interfaces. Bill Whitlock, pres & chief engineer, Jensen Transformers www.jensen-transformers.com
Love your quote Bill, I was going to put it as a signature on my work email but it's probably a bit toooo provocative.....
I googled it and it only came up with this post....do you know where it came from? (and if you're quoting yourself, I am still impressed!)
David, my quote was adapted from Ayn Rand in her book "Anthem", which is "What is my wisdom, if even the fools can dictate to me?" The "corporate constipation" is one of my own making. Having worked for a number of large corporations over my career makes me loathe the management structure at most companies ... I especially loathe MBA's, which in my mind stands for Mindless Bottom-line Analysts!
Thanks Bill. You sound like a man after my own heart. The place where I work at the moment, when I started, had one of the best comms networks I have ever seen, well thought out, well impemented and well maintained. Management appointed a bean counter to head us and since then nothing works as it should. Too many chiefs and not enough indians, and your quote fits sooo perfectly.
Twice, I've worked for startups that MBAs ruined. Company starts with handful of clever, hands-on workers with a great idea - company grows from 4 to over 100 employees in 3 years - fun, rewarding place to work for 2 more years - then the MBAs arrive - back to 6 employees and near bankruptcy 1 year later. I'm proud to say my company is engineer owned and operated ... and makes everything here in the USA! David, drop me a line at firstname.lastname@example.org
That reminds me of my favorite story ever in Forbes magazine. The story was about a high school grad that started a successful company and sold out to a group of Harvard MBAs. They ran the company into the ground and he bought it back at a discount and made a second fortune turning the company around. The lessons I took from this is that the top people need to understand the company and its products very well and that smart guys can't always run a business.
Interesting grounding story (pun intended)...I wonder whether they are any general rules for grounding noise sensitive systems? Every-time I discuss this issue everyone has a different opinion, looks like black magic to me! Kris
Kris - As Bill notes in his reply to you, grounding has been a big problem for ages and will continue to be so for a very long time to come. I've been involved with EMC in aerospace systems for the past 11 years, and there are issues there which are totally different than what Bill describes for audio systems. To be sure, there are general design rules that apply in most design scenarios, and I think you'll find it worthwhile to check out EMC-related web sites and publications for some guidance. One of the tasks we EMC engineers had last year was to re-write the in-house EMC design guide for product engineers. That "guide" was more than 600 pages in length! That's a lot of guidance, so each suer must sort out what applies in their case and then go from there.
thank you @WA9ENA...where do I find any of those EMC design guides? these grounding issues come up all the time!...treating ground as common potential is obviously too simplistic and basically neglects the issue but if you consider each grounding point as a signal point where is the reference point? true ground? dr Kris
The "black magic" factor is exactly why I write and teach so much - and why the Audio Engineering Society made me a Fellow. Audio systems are among the most sensitive since the frequency range covers 10 octaves (including 60 Hz and harmonics) and often needs a dynamic range of 120 dB. The main obstacle for engineers is the ubiquitous ground symbol in schematics. It lulls us into thinking that equipotential points exist ... in fact, this is fantasy! I should add that much "sensitive" equipment contains serious internal design flaws that make it respond to power line noise (I call these "power-line primadonnas") or to even small currents on their shield connections ... this includes many desktop and laptop computers but also some very expensive audio gear. Check my company website, www.jensen-transformers.com for some no-bull tutorials (under "white papers", about how ground loops really work. I recently presented a paper that explains where the tiny voltages that drive ground loop currents originate. Believe it or not, the conductors in premises wiring behave as a long, skinny transformer - circuit load currents magnetically induce voltages over the length of the safety ground conductor, depending exquisitely on the exact physical relationship of the conductors. Of course, the induced voltage is proportional to the rate of change of the load current, so predictably, ordinary light dimmers (which cause large currents to turn on in a few microseconds) are major sources of buzz in audio systems. I charge no honorarium for lectures, just my out-of-pocket expenses. Logic and physics will explain it all ... no magic!
Once upon a time, a young engineering master's student made a few bucks fixing the college's fancy equipment: magnetic resonance machines (the manual was in German), helium leak detectors, and scanning electron microscopes (SEM). One day, the SEM developed hum in the image. Not good. So I checked around for loose or broken connections, this, that and the other thing... no dice. One more clue: this was the "engineering unit" that was donated or sold to the college for cheap. Way over on a panel-mounted autotransformer that regulated filament current, a couple layers of electrical tape used to keep the tap from banging into another control mounted too closely, had finally been worn through... need I say more? Except that it took about 3 days to isolate. Hum and noise, hum and noise: one of the bane of an EE's existence.
I went to a vendor meeting in San Leandro to do a design review on a new surgical device.
One thing that caught my attention was a procedure to check that a pair of switches would report that a IV pack door was opened or closed properly.
They used a scope to monitor the switch closures timing while a tech closed the door. I pointed out that the test was invalid since the timing was conditional with the tech closing the door at the proper speed. When I brought up the issue in the review meeting, the chief engineer slammed me for my "ignorance". A month later I saw a ECO changing the test. : )
Ridicule, in a "professional" meeting, is always a bad sign. Something is wrong with the company, or the person who is behaving so poorly. I was once taken over the coals by a "project manager" for proposing to use gold o-rings on a specific high-vaccuum application. He made a joke about it on a telecon with the client. I covered for myself by saying, "I know what you are thinking: why use gold when platinum will do?". After the laughter died down on the line, the customer asked, in all seriousness, "why did I want to use a precious-metal seal?". The program manager, at that point, realized for the first time that there was such a thing... None of us know everything: you would think that people wouldn't be so quick to advertise their ignorance.
To Bob, @rhayashi: There must be thousands of stories like this...in each reasonable large organizations there are several individuals like this, typically in management ranks, that present this type of attitude...typically organizations get rid of those individuals but it takes sometimes very long time...unfortunately, human ego combined with not perfect promotion system lead to cases like the ones described...I don't see any solutions, do you? Kris
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.