Very nice fix; I like your troubleshooting methods and the way you tracked down the glitch. Your example is a valuable lesson for embedded designers who almost always have to figure out concessions with I/O.
Good point, Greg. These Sherlock Ohms stories are famous for showing how design engineers have to dispense with all assumptions and dig into areas that could easily get overlooked. If you have any of your own Sherlock stories, please send them along to: email@example.com
This is all over my head so I am way out of my comfort zone here, so if this question does not make sense just consider the source. 99% of what I do is mechanical and when I complete a design and the device is built, it is subjected to a run-off, often with the customer present. If changes are made, the drawings get updated and the alteration is logged. That way if I run into a similar design, I have a record of what did not work and how we corrected it. Is that done in your field as well or would someone else have to go through the whole trouble shooting procedure you just spelled out?
One of my co-workers is so tunnel visioned that he thinks the only important thing is to make the device work. As a result, many alterations may occur with the only record being what he retains between his ears. It drives me crazy, but his family owns the company, so I deal with it.
Tool_maker, In a perfect world, we would document everything everytime, but it's not always practical. In a large organization, thourough documentation is necessary to handle the logistics of communication. In a small mom-and-pop shop, you can get away with a certain amount of "mental" documentation because direct communication with those who know the details is easier.
This can be taken to extremes on both sides of the continuum. I used to work for a huge multinational conglomerate. We documented ourselves to death, literally. It took seven signatures and half a day to get an ECO approved and documented. That's IF I walked it through myself. The normal lag was about two weeks.
On the other hand, if you lose your human capital who happens to be the sole keeper of odd knowledge for a given project, good luck making heads or tails of it.
You have to find that balance of productivity and proper documentation with which you are comfortable.
A middle school team from Rochester, Mich., has again nabbed the grand prize in the annual international Future City Competition, which drew students from 37 regions of the United States, as well as from England and China.
The word “smart” is becoming the dumbest word around. It has been applied to almost every device and system in our homes. In addition to smartphones and smart meters, we now hear about smart clothing and smart shoes, smart lights, smart homes, smart buildings, and every trendy city today has its smart city project. Just because it has a computer inside and is connected to the Web, does not mean it is smart.
Are you being paid enough? Do you want a better job? According to a recent survey Manpower released just before Engineers Week, employers and engineers don't see eye-to-eye about the state of US engineers' skills and experience.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.