——
Drive code with principles, shape professionalism with habits
✅ Habit 1: Be Proactive
You are not just a “bug-fixing tool”; you are the “architect” of embedded systems.
💡 Application in Embedded Scenarios:
|
❌ Passive Reaction |
✅ Proactive |
|---|---|
|
“The boss said to change it, so I changed it without asking why.” |
“This function logic has risks; I suggest adding a state machine and watchdog protection to avoid infinite loops.” |
|
“The documentation isn’t written; I’ll wait for someone else to fill it in.” |
“I wrote a ‘XX Driver User Manual’ and a register mapping table and shared it with the team.” |
|
“The board is malfunctioning; call the hardware colleague.” |
“I used a logic analyzer to capture the SPI waveform and found that the clock’s falling edge was sampled incorrectly, pinpointing that the software timing did not match the chip’s requirements.” |
|
“RTOS task stack overflow? I don’t know.” |
“I configured stack overflow detection and printed the actual usage for each task to provide early warnings.” |
🛠️ Practical Tools:
- “Influence Circle List”: Write down 3 things you can control every day (e.g., run static analysis before submitting code, write unit tests, update README).
- Language Conversion Training:❌ “The documentation for this chip is terrible.” → ✅ “I compiled a ‘STM32H7 Clock Configuration Pitfall Guide’ for the team.”
- Proactive Design: Before development, draw “module interaction diagrams”, “state transition diagrams”, and “error handling trees”.
💬 Golden Quote:“True embedded experts do not earn respect by ‘putting out fires’ but establish authority by ‘preventing fires’.”
✅ Habit 2: Begin With the End in Mind
Before writing code, think clearly: who will look at this code in 5 years? Will it still be relevant?
💡 Application in Embedded Scenarios:
✍️ Write your Embedded Developer Mission Statement (recommended to print and post at your workstation):
“I am an embedded software engineer, and I pursue:
- Reliability over speed (better to be slow by a millisecond than to crash once)
- Maintainability over showmanship (do not write bit manipulation magic that no one understands)
- Testability over convenience (every function has isolated test cases)
- Using engineering thinking to safeguard the stable operation of power, energy, and life systems.”
🧭 Backtrack development decisions from the “end”:
|
Question |
Your answer determines the development approach |
|---|---|
|
If this product sells 100,000 units, what if there is an upgrade error on-site? |
→ You must design an OTA upgrade rollback mechanism, version verification, and dual-area backup. |
|
If three years later, a new engineer comes in, will they understand the interrupt service routine I wrote? |
→ You must write comments, add function header descriptions, and avoid global variable pollution. |
|
If the customer requests a new feature, can I avoid changing the old code? |
→ You must use interface abstraction, strategy patterns, and configuration-driven design. |
🛠️ Practical Tools:
- “5-Year Code Review Simulation”: After completing a module, ask yourself: “If this were written by someone else, what score would I give it?”
- Design Documentation First: Before writing code, produce a “Module Design Specification” (including: interfaces, state machines, exception handling, test points).
📌 Embedded Truth:“What you write is not just code; it is a runnable promise — a promise that the device will not suddenly lose control at 3 AM.”
✅ Habit 3: Put First Things First
Your time is not for fixing bugs; it is for preventing bugs.
💡 Application in Embedded Scenarios:
✅ First Things = Things that contribute to “long-term stability, maintainability, and scalability” (not the “most urgent” things)
|
High-frequency “Pseudo First Things” |
True “First Things” |
|---|---|
|
Fixing urgent bugs online (firefighting) |
✅ Writing automated tests to cover such bugs |
|
Urgently changing a parameter |
✅ Making the parameter a configuration file + validation mechanism |
|
Busy debugging hardware |
✅ Writing general debugging tools (serial log parser, register reading scripts) |
|
Following up on requirement changes |
✅ Establishing a requirement change impact assessment process |
🗂️ Self-Management Four-Step Method — Embedded Development Version
|
Step |
Operation Example |
|---|---|
|
1. Confirm Role |
Software Engineer / Module Leader / Team Technical Mentor / Code Reviewer |
|
2. Choose Goals |
Two important tasks for next week:① Add unit tests for the CAN driver② Refactor watchdog reset logic to support configurable timeouts |
|
3. Schedule Progress |
Monday: Write test frameworkWednesday: Write test casesFriday: Merge code + update documentation |
|
4. Daily Adjustments |
Look at the plan before the daily meeting; if you encounter “urgent but not important” matters, decisively say: “I’ll handle it this afternoon.” |
⚖️ Responsibility-Based Delegation (for team leadership):
|
Element |
Embedded Scenario Example |
|---|---|
|
Expected Outcomes |
“The new sensor driver must support hot-swapping, delivered within 3 days, passing automated tests (coverage ≥ 85%)” |
|
Guidelines |
“Cannot modify the main control core timing; must use interrupts + queues to decouple, blocking delays are prohibited” |
|
Available Resources |
Provide SDK, reference code, debugger, and oscilloscope access |
|
Task Assessment |
Code Review + Test Report + Review Meeting Presentation |
💡 Principle:“Important things are never urgent; urgent things are often not important.” In the embedded field, preventive development is always more efficient than firefighting development.
✅ Habit 4: Think Win-Win
You are not fighting against hardware, testing, or products; you are “dancing” with them.
💡 Application in Embedded Scenarios:
❤️ Emotional Bank Account: Your “trust deposits” with colleagues
|
Deposit Behavior |
Withdrawal Behavior |
|---|---|
|
Timely response to hardware issues, not shirking responsibility |
“This is not my problem; it’s your PCB design issue.” |
|
Informing about interface changes in advance |
Suddenly changing the communication protocol without notifying testing. |
|
Proactively helping newcomers debug code |
“Look it up in the manual; I’m busy.” |
|
Providing clear reproduction steps to testing |
“It works fine on my local; you try it again?” |
✅ Win-Win Communication Phrases:
- ❌ “Your test case is wrong; it can’t detect my issue at all.”
- ✅ “The scenario you discovered is crucial; I’ll add a boundary test, and we can improve it together.”
📌 Embedded Iron Law:“A project’s success is not just about the software running; it’s about the entire team believing the system is reliable.”
✅ Habit 5: Seek First to Understand, Then to Be Understood
Don’t rush to talk about code; first, understand the essence of the problem.
💡 Application in Embedded Scenarios:
🎧 Empathetic Listening in Projects:
|
Scenario |
Passive Response |
Empathetic Response |
|---|---|---|
|
Testing says: “This feature is unstable and occasionally restarts.” |
“You must be testing it wrong; I can’t reproduce it locally.” |
“You mentioned ‘occasional restarts’; can you describe if it happens within 10 minutes of power-up? Or during stress testing? Any logs?” |
|
The product manager says: “Can we add a remote upgrade feature?” |
“That requires changing the Bootloader; it’s too complicated.” |
“What scenario do you envision for users to upgrade? Is it OTA or USB? Let’s assess the risks and costs together and design the optimal solution.” |
✅ Technical Communication “Three-Step Method”:
- Restate the problem: “What you mean is that the device loses communication in low temperatures, right?”
- Explore the background: “Is this happening with all models or just specific batches?”
- Explore together: “Can we add a ‘low-temperature mode’ to reduce communication speed and enhance stability?”
📌 The Truth:90% of embedded bugs are not due to code errors but due to misunderstanding requirements or misalignment of boundary conditions.
✅ Habit 6: Synergize
1+1 > 2 — Let people from different backgrounds create better solutions together.
💡 Application in Embedded Scenarios:
|
Scenario |
Inefficient Mode |
Synergistic Mode |
|---|---|---|
|
Software says: “I need 200KB of RAM.” Hardware says: “I can only give 128KB.” → Compromise? |
Each side gives in, resulting in reduced functionality. |
✅ Software uses dynamic memory pools + compression algorithms; hardware switches to external Flash caching → Functionality intact, resources met. |
|
Testing complains: “Your code has no comments.” |
Development retaliates: “Your test cases are incomplete.” |
✅ Jointly establish “Code Commenting Standards + Test Case Templates” |
|
Want to implement AI prediction algorithms? |
“The chip has no NPU; it’s not possible.” |
✅ Use lightweight models (TinyML) + model quantization + offline training + online inference → Successfully deployed on Cortex-M4. |
🧠 Left Brain + Right Brain Collaboration:
|
Left Brain (Logic) |
Right Brain (Creativity) |
|---|---|
|
Analyze timing, calculate stack size, optimize instructions. |
Imagine, “What if the device could diagnose faults by itself?” |
|
Write state machines, consult manuals, configure registers. |
Design a “seamless upgrade” experience for users. |
💡 The ultimate manifestation of synergy:“We are not just ‘making products’; we are defining the standards for the next generation of energy controllers together.”
✅ Habit 7: Sharpen the Saw
You are not a machine; your brain and skills also need regular “sharpening”.
Four Areas of Update for Embedded Developers:
|
Aspect |
Practical Suggestions |
|---|---|
|
Physical |
Protect your cervical spine (use a brace), look into the distance for 5 minutes every hour, drink more water, maintain a regular schedule (staying up late debugging = chronic suicide). |
|
Mental |
Read one embedded paper/technical blog per week (e.g., Embedded.com, ARM official documentation), learn a new language (Rust for MCU). |
|
Spiritual |
Write technical blogs, organize knowledge bases, attend meetups, reflect on “What is my code changing?” (e.g., making energy storage safer). |
|
Social/Emotional |
Proactively conduct code reviews, mentor newcomers, organize technical sharing, sincerely thank those who have helped you. |
📌 Weekly 15-Minute “Sharpening” Plan:: Monday: Read 1 technical article; Wednesday: Organize 1 debugging tip into the team Wiki; Friday: Discuss technical confusions with 1 colleague.
✅ True technical experts are not the ones who write the best code, but those who understand continuous growth and can influence others.
🏁 Summary: The Growth Pyramid of Embedded Developers
|
Level |
Habit |
Goal |
|---|---|---|
|
Base Level: Self-Management |
Habits 1–3 |
From “passive executor” → “proactive designer” |
|
Middle Level: Interpersonal Collaboration |
Habits 4–5 |
From “island engineer” → “team collaborator” |
|
Top Level: System Creation |
Habits 6–7 |
From “code implementer” → product definer |
📌 Action Suggestions (Things to Do Immediately):
|
Habit |
Action Items for This Week |
|---|---|
|
1. Be Proactive |
Write a “Common Issues FAQ for My Module” and share it in the team group. |
|
2. Begin With the End in Mind |
Write a “Maintenance Guide for 5 Years Later” for the next module (even if it’s only 3 sentences). |
|
3. Put First Things First |
Spend 5 minutes every morning writing “The Most Important Thing Today”. |
|
4. Think Win-Win |
Proactively compliment a colleague: “Your testing suggestions helped a lot last time!” |
|
5. Seek First to Understand |
The next time you are questioned, first say: “Can you elaborate on your observations?” |
|
6. Synergize |
Schedule a cross-department meeting: “Can we design a more elegant communication protocol together?” |
|
7. Sharpen the Saw |
Subscribe to a technical newsletter and receive 1 embedded article each week. |
💬 Finally, let me leave you with this: “Excellent developers write code, great developers shape systems; and truly effective embedded engineers define industry standards through their habits.”