Um, OK. I think I can clear up a couple of points here.
I DID get recognition from Management: did NOT get laid off in the next two RIFs, so I guess my "volunteerism" paid off. Incidentally, the enginners who subscribed to the theory of "A lack of planning on your part does not necessarily constitute a crisis on my part." actually DID get laid off!!! Sometimes it helps to "lean forward" a bit.
Also, and this is a funny one, WE NEVER BUILT PROTOTYPES!!! Management, as a rule, didn't bid the Labor to kluge up the circuits beforehand. Makes me wonder how we did so well....
I probably would have done the same thing as you did by staying up late and working around the clock to get the job done.
I am just curious wasn't testing done up front to see whether the design was as it was intended to be.
Point taken Glen. It's sometimes very difficult to know when to let management stew in their own crisis and when to step up and get them out of it. In this case they did recognise Dwight's efforts, apparently. And in the end, you have to live with yourself and your own criteria for a job well done.
A supportive management style will always get more out of the workers than being hard-assed. Where I am at the moment, the "us and them" attitude is almost palpable and it has made a good company a very frustrating place to work.
If you are part of a team it is a pleasure to contribute to getting the team out of a tight spot. If you don't feel part of a team, it's very difficult to give of your best.
I think EmbeddedNinja's comment refers to the old cliche "A lack of planning on your part does not necessarily constitute a crisis on my part." In other words, why should someone have to struggle to compensate for another's goof?
Somebody goofed up, somebody else busted their butt to save the company's bottom line. Good engineering response to problem solving, jump in and resolve the problem with many hours of unpaid overtime.
Unfortunately this engineering response gets no credit or acknowledgment (often upper management is not aware of the engineer's efforts) and is overlooked or forgotten during times of downsizing.
I think you're being a bit hard here. It's an engineering problem, does it matter where it came from??
So Dwight "did what every other young engineer would do – I "buckled down" and got to work." Good on him! He says also that "My boss was impressed...." so hopefully it got him ahead in the job.
I think 90% of engineers would have taken this course of action, and rightly so.
I love these old war stories! Too bad plds weren't fast enough at the time it would have made things much simpler. My very first design I used a dead bug socket instead of the normal one and my design of course didn't work until I put the part in upside down and soldered on some little yellow wires. My boss made me do this before he would let me spin another PCB!
Anyone else got some good stories?
Were we more scared then?
Recent designs of mine have used 900MHz datarates, and I have done lots of digital video without problems (certainly without board-level simulation timing tools). When I started, though, people were terrified of video rate signals (13.5MHz!) let alone ECL and beyond.
I guess silicon was sooo slow then we had no margins left, and the bleeding edge of digital design was a black art. Now ts the other way about, Analog is the twilight zone.
A good experience with the video card designs and the propgation delays in the TTL circuits and the schematic capture ,simulations.In the 20 years time the scenerio completely changed.Going back and thinking of the past experiences some times gives us lot of pleasure.
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.