Breaking News
Oldest First | Newest First | Threaded View
Page 1 / 4   >   >>
User Rank
About this post;
NavmanWireless   8/19/2014 10:48:33 AM

User Rank
So true!
zeeglen   8/19/2014 11:19:39 AM
Good blog!  Tells it like it is.

User Rank
Re: So true!
jeremybirch   8/19/2014 11:56:36 AM
There two things that are a bit sad about this:

1) it repeats the mistakes of the past. For a ling time at large Japanese corporations there was an expectation that workers would not work 9 to 5, or even take their annual leave. This reached ridiculous levels where on top of a multi-hour commute workers were not meant to leave their desks, and when the bell rang at 5 pm no one moved, waiting until the 7pm  "doors being locked" bell before stopping. This bred a culture of stretching the day's work to fit the hours ie not more productovoty but just longer hours.

2) how many really tough problems do you solve when you are not staring at them but instead you are doing something completely separate, like walking, reading a book, even sleeping? By working long hours you don't necessarily get to the solution any quicker and you do weaken yourself physically and mentally, and damage home life (which is after all what the work is meant to be paying for, isn't it?)


User Rank
Very accurate.
jimwilliams57   8/19/2014 11:57:46 AM
I've worked in many environments during my career, roughly two-thirds of which were with companies that understood engineering and were willing to allow the engineers to make decisions.

It is the employers that describe themselves as "marketing companies" that seem, in my opinion, to have the most difficult time with engineers. The marketing companies that I have worked for have been very unbending regarding requirements, decisions, and schedules. The engineers were treated like robots that were expected to produce error-free results according to the schedule created by management. While at one of these marketing companies, when a product didn't meet sales expectations the engineering team was informed that we "had failed" and were expected to make it right so that sales would increase.  The product met every requirement, including the ones that engineering had argued against or in need of improvement.

User Rank
Re: Very accurate.
MeasurementBlues   8/19/2014 3:22:27 PM
I once worked for such a "marketing" company doing tech support and then management wanted to devlop its own products. We hired several engineering consultants and I was the project manager/test engineer. As we kept adding more projects, allof them fell behind and we switched gears whenever a customer screamed "where's my product?" Marketing then accused engineering (me) of deliberately delaying the projects in an effort to keep my job. That's the last thing I wanted to do, for I knew that completing a successful project was a better way to keep my job.

Management also didn't understand the need for things like test equipment and bought on price alone.

And of course, I still had to do the tech support for the other product line, products where were imported and sold under the company name.


User Rank
Do more with less
MeasurementBlues   8/19/2014 3:33:12 PM
The management battle cry for every business. Engineers are not alone here.

User Rank
Queueing delays
perl_geek   8/19/2014 7:01:46 PM
I don't know if it's the same with hardware, but my experience with software development has been that a great deal of time is wasted and delay caused by incorrect division of work.

Any time responsibility is split between people or groups in a way that causes one group to wait on another's output, or separates decisions about interacting parts, it has two effects. Projects take longer than they should, because what one group finishes languishes in a queue until the next group can pick it up, (e.g. prototype production to testing). Meetings held in an attempt to communicate what is needed, tie up people who could actually be doing work, if they knew what had to be done. Everybody spends a lot of time not achieving anything, rushing to overcome delays, reworking what was done badly because it was rushed, or just not what was really needed.

Some of this is what "Agile" methods attempt to address. Small groups, properly balanced teams, and short feedback cycles help. Reporting methods that don't create more work than they measure are important. too.  (The Duke of Wellington made a relevant remark on the topic: see )


User Rank
Re: Queueing delays
zeeglen   8/19/2014 8:35:39 PM
@perl_geek I don't know if it's the same with hardware,

Take my word for it, hardware development is just as buggered up.  Management at work ...

User Rank
bad managers
zbo   8/19/2014 8:52:12 PM
There are just people out there that shouldn't be managers. Actually, let me rephrase. There are managers out that that us as engineers shouldn't take crap from and bother working for. I've learned enough that life's too short to be involved in bad work.


Scenario #1 - you're employed and have been looking elsewhere. The manager interested in having an interview should never call the person out of the blue if that person has an email address in the resume. If the manager is asking for basic things that are already in the resume, he has not taken the time to review it. This is a job you should not waste time persuing because that would be an idiot you'll need to deal with - unless you're out of work and need the money


Scenario #2 - Manager should be looking out for his/her team members. If you're in a meeting with other teams where the other team is reporting a problem with the project, don't start immediately putting blame at your own guys in front of other people without fully understanding the situation.


Scenario #3 - There are managers that solely care about numbers and bookings. They're pure sales weasels, not there to manage. Well, I guess 'manage' would be the appropriate term, since they're not there to 'lead'.  In any case, they are ones that are so disconnected with technology, people that work for them, completely disregards effots that their team puts in, show no remorse when people from his team leaves. They're so high up in the food chain that they're most interested is how much commission they get from bookings.


User Rank
Re: So true!
Measurement.Blues   8/20/2014 9:54:11 AM
how many really tough problems do you solve when you are not staring at them but instead you are doing something completely separate, like walking, reading a book, even sleeping?

We've all come up with ideas when we're not staring at our work, but how much of our time is spent on "busy" work, the kind that has to be done but is monotonous, requiring no thought? We often need to longer hours just to do that.

Page 1 / 4   >   >> Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)

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.
Like Us on Facebook
Special Video Section
LED lighting is an important feature in today’s and future ...
The LT8602 has two high voltage buck regulators with an ...
The quality and reliability of Mill-Max's two-piece ...
Why the multicopter? It has every thing in it. 58 of ...
Security is important in all parts of the IoT chain, ...
Infineon explains their philosophy and why the multicopter ...
The LTC4282 Hot SwapTM controller allows a board to be ...
This video highlights the Zynq® UltraScale+™ MPSoC, and sho...
Homeowners may soon be able to store the energy generated ...
The LTC®6363 is a low power, low noise, fully differential ...
See the Virtex® UltraScale+™ FPGA with 32.75G backplane ...
Vincent Ching, applications engineer at Avago Technologies, ...
The LT®6375 is a unity-gain difference amplifier which ...
The LTC®4015 is a complete synchronous buck controller/ ...
The LTC®2983 measures a wide variety of temperature sensors ...
The LTC®3886 is a dual PolyPhase DC/DC synchronous ...
The LTC®2348-18 is an 18-bit, low noise 8-channel ...
The LT®3042 is a high performance low dropout linear ...