You may redistribute this newsletter for non-commercial purposes. For commercial use contact email@example.com. To subscribe or unsubscribe go here or drop Jack an email.
Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes.
I'll present the Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. As I noted in a recent blog, I'm cutting back significantly on travel, so this will be my last trip to Australia.
Jack's latest blog: 2019's Most Important Lesson
|Quotes and Thoughts|
"With the past coming down the road so fast, we are going to have to address it in the future" Perkins McGuire
|Tools and Tips|
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.
Bob Paddock submitted this idea for bi-directional comm using just an LED. Part of the secret sauce? Reverse-biasing an LED makes it a photoreceptor:
Roy Tellason sent an excellent link to a paper about monitoring and balancing Li-ion cells in electric vehicles.
Stephen Bernhoeft sent in an idea from Bob Pease's book Troubleshooting Analog Circuits. It's another way to use a backwards FET to protect against an improperly-inserted batter.
And Joe Vandzura added this:
Chris Hemingway has a debugging tip:
|Freebies and Discounts|
Greg Wagner won last month's Amazon Echo.
This month's giveaway is a 30 V 10 A lab power supply:
Enter via this link.
|More on Encoders|
Last issue's comments on encoders engendered a lot of fascinating responses from readers.
Yassen Gorbounov wrote (and gave me permission to post) an excellent paper about eliminating the errors which may arise during direction reversal of a shaft.
Chris Gates commented:
Rob Milne sent some code:
Attila Kalinka suggested an interesting chip:
Bob Paddock sent:
|Honesty in Scheduling
The nuns at Holy Redeemer elementary school on Long Island taught us that lying is a sin. As we got older they added a certain amount of nuance to that, differentiating between venial and mortal sins, but the injunction to stick to the truth never wavered.
Adulthood showed that there were more than two shades to honesty: some things are indeed private, and sometimes kids need a carefully modulated version of the truth. But the nun's basic precept has, in my experience, been a pretty darn good guide to behavior: don't lie.
All of us know this. Most of us, except campaigning politicians, practice it with a good degree of rigor.
Yeah, but the boss will cut our schedule in half.
Yeah, but the show drives the schedule, not any sort of engineering realities.
Yeah, but they'll agree to our timeline but will pile on more functionality throughout the project, all without changing the end-date.
So, many developers give up in disgust and agree to whatever the boss demands, knowing fatefully that it will slip, maybe by a lot. Or they double their real estimate to come out even when management whacks months off their projection.
I think that's a tremendous mistake. Don't lie. Work from the highest of ethical standards. Create an accurate, detailed, schedule and present that.
In my experience most engineering managers are ex-engineers. They love numbers. Yet too many of us present schedules devoid of detail. It's hard to argue against a tightly-reasoned schedule that's accompanied by detailed work breakdowns. Once, arguing this point in a class of 80 developers, all of whom were issuing "yeah, buts" at a machine-gun rate, their VP of engineering stood up and told them: "you never give me these sorts of details, so of course I don't believe you. Give me the numbers and I'll have to yield."
Of course it is true that plenty of bosses will not be swayed no matter what arguments we present. Many honest schedules will fall on deaf ears. But it seems to me that we have an obligation to be truthful regardless. We must collect actual data to compare against projected dates when the project is done, so both we, and the boss, can learn.
Yes, it is somewhat naive to expect management to suddenly have the scheduling scales fall from their eyes when presented with well-supported schedules. But by being dishonest we play their same game. And that's just plain wrong.
The IEEE Code of Ethics says, among other things "[We promise] to be honest and realistic in stating claims or estimates based on available data". I think that's a pretty good place to start.
Yet an awful lot of engineers disagree with me. What's your take?
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|Joke For The Week
These jokes are archived here.
Bob Paddock, cited in this Muse twice already, sent this:
The Preface to Murphy's Law:
|About The Embedded Muse
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at firstname.lastname@example.org.
The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at email@example.com for more information.