Breaking News
Comments
dt_hayden
User Rank
CEO
bless the complexity
dt_hayden   5/20/2014 10:47:44 AM
NO RATINGS
My favorite errant manager story is from when I worked at a small company on innovative heldheld test instruments.  The manager, also being the owner of the startup company, enforced an unwritten policy that nothing made it into production unless it was his idea.   I came up with an idea which improved the performance of a measuring circuit, required less PCB real estate, was cheaper to implement, and was generally less complex.  As I demonstrated the circuit to the manager along with one benefit, I was advised the improvement was too minimal to implement.  I noted an additional benefit, one at a time, only to be struck down each time.  When I explained the simplicity of the new cicruit compared to the existing, the mananger said, and I quote, "we are not always looking for the least complex solution".  Oy!

JeremySCook
User Rank
Blogger
The boss is always the boss
JeremySCook   5/28/2014 10:02:00 AM
NO RATINGS
Glad you got something new to work.  It's great when you can improve things.

 

On the other hand, sometimes I just have to tell myself that, while sometimes the boss doesn't seem right from my perspective, he's who I get paid to answer to.

Duane Benson
User Rank
Blogger
Re: The boss is always the boss
Duane Benson   5/28/2014 2:15:53 PM
NO RATINGS
"he's who I get paid to answer to"

A freind of mine once describe it this way: You have two jobs: the one in your job description, and keeping your boss happy. Ideally, they are the same, but all too often, are not.

TFCSD
User Rank
CEO
Re: The boss is always the boss
TFCSD   5/29/2014 1:12:00 AM
NO RATINGS
I use to have a programming job where I maintained/upgraded an embedded program that the original programmer did what was correct rather than do what the boss and sales wanted. I don't know why the programmer would do this but the boss and sales would randomly walk in and quickly look at the screen and start suggesting new features or making programming suggestions (like you are using too many comments and semicolons ;-)). The original program worked great but it did not follow their manual precisely in some areas (one wonders why none of the customers or other in the company saw this?). The last programmer's joked it took up to 80 KLOCs to cut a piece of silicon and he could do it better in a few hundred lines. Well I made the mistake of mentioning these divergent areas during a manual rewrite and suggested we should make the new manual match how the program really functioned. Boy, did fertilizer impact the rotary air device. I was grilled on what I changed and everything was correct before. Even when I showed the original program was not following their manual, it was still my fault. Did I mention I use to have a programming job?

zeeglen
User Rank
Blogger
Re: The boss is always the boss
zeeglen   5/29/2014 1:39:29 AM
NO RATINGS
@TFCSD Boy, did fertilizer impact the rotary air device.

LOVE your expressive verbiage.  Damn shame you no longer have a programming job for doing what was right.

zeeglen
User Rank
Blogger
Re: The boss is always the boss
zeeglen   5/29/2014 1:56:50 AM
NO RATINGS
Just for fun, there is a comedy sketch on youtube about a common-sense engineer getting beaten up in a corporate-management-moron meeting.  Go to youtube and search for "The Expert" (short comedy sketch).  I think most of us have been in similar situations.

Carolus1964
User Rank
Rookie
About well tested code...
Carolus1964   5/21/2014 12:00:31 PM
NO RATINGS
I were in a simila situation: the porting of field proven code for a Z80 processor (8 bit - little endian) to another microcontroller (16 bit - big endian).

After recompilation with the minimum of adaptions (because the code was well tested over many years) the code ran but appeared a lot of bugs and crashes that were invisible before (or well, they were there but they weren't triggered).

Only after the debugging of all buffer overflows, stack corruptions, etc.. the firmware worked again.

BrainiacVI
User Rank
CEO
Management by Magazine Article
BrainiacVI   5/27/2014 3:12:45 PM
NO RATINGS
Many a time have I dealt with a methodology I call "Management by Magazine Article".

Once, a manager insisted that one member of my team rewrite three lines of code into one. The argument being that one line of code is easier to maintain than three.

The program used three move statements to construct a string (two pieces of text and a terminating 0) and the manager did not understand that technique and when explained to her, still insisted that it be written using sprintf (string print function).

The compiler would have created three MOV instructions for the three C statements. Very small, very fast. The sprintf would be interpretive and if the function library had not already been in memory, would have added K's of code to the size of the program.

So standing on the dictum she had read in a magazine article, the code went from small and fast to big and slow.

I have too many examples from her and other managers I've had to work for to list here, but it could make a book.

Not to pick on her, aside from her being at the top of my idiots list, she used to have truism that bugs in your code were like roaches, if you found one, there were ten more. but when confronted with a compiler error, she could not accept it. We reminded her of her oft stated truism, but she said that was for a program, not a compiler. We were unable to convince her that compilers were programs.



Flash Poll
Top Comments of the Week
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Max Maxfield

Feast Your Orbs on My Jiggly Exercise Machine
Max Maxfield
52 comments
Last weekend, I was chatting with my mother on the phone. She's all excited that I'm coming over to visit for a week in November. "I'll be seeing you in only seven weeks," she trilled ...

Glen Chenier

Missing Datasheet Details Can Cause Problems
Glen Chenier
3 comments
It is often said that "the devil is in the details." All too often those details are hidden deep within a datasheet, where you can easily overlook them. When a datasheet reference circuit ...

David Blaza

RadioShack: The End Is Nigh!
David Blaza
123 comments
I'm feeling a little nostalgic today as I read about what looks like the imminent demise of RadioShack, at least as we currently know it. An old ubiquitous cartoon image popped into my ...

Larry Desjardin

Engineers Should Study Finance: 5 Reasons Why
Larry Desjardin
47 comments
I'm a big proponent of engineers learning financial basics. Why? Because engineers are making decisions all the time, in multiple ways. Having a good financial understanding guides these ...