Everybody trusts a hardware engineer, except themselves. Nobody trusts a software engineer, except themselves.

On Learning

Kevin Cooper: “Kevin treasured trying to learn from men in their 90s,” says Billy. He thought learning from his own experience was nonsense. “It takes too long and you screw up too much,” Kevin would say. “I want to figure out what everybody else already learned and get a good head start.”

7 Habits of Highly Annoying Developers

slow on peer review
over-protective
too much talking, not enough listening
no comments in code, no wiki updates
no accountability
aggressive back-seat driving
jump happy when debugging

Business Jargon

What does "results-oriented" mean?

Focusing on the outcome, rather than the means to get there. It could be said that the opposite is process-oriented. Startups tend to be more results-oriented. But with a good process that is followed, you'll get the outcome you want generally. Other suggested leans could be goal- or people-oriented.

Estimation

In the design and tool evaluation phase of a project, it's actually quite easy to shrink estimated development time. Simply pull back from pushing into the latest cutting-edge devices and tools, and stick with the well-established known entities for whom there is a mature development ecosystem. Everything will come to together much faster, and you'll probably save on BoM costs, but you'll almost certainly have to give up some performance in the end product.

Jack Ganssle: "Various studies and my own observations confirm that testing and debug consume about half of a typical project's schedule. (I combine the two, because debugging is the first set of checks used to isolate the most obvious problems. It's the beginning of the test process). Coding eats only around 20%."

Successful Projects: What NOT To Do

4-Step Teamicide

Set an arbitrary deadline with no input from the implementation team
Don't bother to provide any information or justification for the deadline
Apply pressure towards meeting the deadline
After the goals are reached, the accomplishment demonstrated, cancel the project for no good reason

Pretend there are no upcoming layoffs, and remain silent on the topic after they are initiated.

Team Makeup

From Embedded.com comments: Splitting reporting and responsibility into software vs hardware is ultimately the worst organisational error that can be made. It is way better to combine the people that provides the hardware + the low level software into a "platform" group. They should be sitting right next to each other and working engineer-to-engineer.

Technical Debt

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise." — Ward Cunningham, 1992

74% of us admit to deleting more than 30% of the required or desired features in a mad panic to ship. Managing feature releases is generally wise, but the sad fact is that many of these deleted goodies were partly implemented. When it's time to send the device out the door we drop work on uncompleted portions of the code. Much better: manage the features aggressively, recognizing that the inexorable ship date will come, perhaps too soon. Focus work on those features needed in the initial release.
- Jack Ganssle

Useful References

Communication Templates

Team Objective

Goal:
To create...

What we have:
-item 1

Unknowns:
-item 1

HW work:
-task 1

PL work:
-task 1

SW work:
-task 1

I&T work:
-task 1

Immediate action items from here to next meeting:
-task 1

Timeframe:
Lay it out

Weekly Monday status email

Previous Week:
-task 1

This Week:
-task 1

Backlog:
-item 1

Notes/Needs:
-item 1

Final Project Objectives:
-item 1