I'm an embedded systems engineer. The more I climb the corporate ladder, the more work I need to do.

Partially because of the nature of work which is getting more and more complex, and requires a higher level of expertise.

And partially because of the non-technical stuff like moving project targets (very common in startup scenes), and having to cater to multiple clients with overlapping features needs.

Not to mention that I'm also doing freelance work, consulting, creating content on LinkedIn, and writing books. All of those require my attention and I only have 24 hours a day.

That's why I need to work less while delivering result with higher quantity and quality.

Throughout my embedded career, I've developed some techniques that worked for me. They've enabled me to do more meaningful work while deliberately reduce my effective working hours.

And just like any tips you found on the internet, steal what you like, and discard the rest.

Automate everything you could

Automation is a big part of my life as an embedded engineer, I try to automate everything as much as humanly possible to reduce tedious, repetitive, and boring tasks.

Just so you know, not everything is worth automating, and it takes time to identify which is which. Here are some rules I use:

1. If I do it almost every day (even multiple times a day), it's worth automating.
2. If I don't like the tasks, I will consider to automate it.
3. If I have the resources to make the system to offload the tasks, I will definitely consider automating.

Using those rules, I can automate almost everything in my embedded workflow:

• Automate code typing using IntelliSense (in some cases, even using Gen AI)
• Automate code formatting check using clang-format
• Automate code checking by cppcheck
• Automate code correctness by automated unit tests (I mostly use Catch2)
• Automate code generation by using CubeMX (when working with STM32)
• Automate firmware building using Makefile
• Automate makefile generation using CMake
• Automate code tracking using git
• Automate code hosting using GitHub
• Automate build process and binary generation using Docker + GitHub Actions
• Automate docs generation using AI + Doxygen
• Automate mock/stub generation using GMock and FakeIt
• Automate code coverage checking using gcov

Because the boring parts are now automated, I can focus more on more important parts:

• Firmware architecture design
• Firmware design diagram
• Making design decisions for our firmware development project
• Discuss with stakeholders (CEO, CTO, Business team, clients) to gather project requirements in more detail

Ultra-tight feedback loop

Feedback will ensure you're heading on the right path.

It's like an arrow above your head in Crazy Taxi game.

Humans are full of blindspots, and feedback uncovers them. If somehow you are misguided, based on the feedback, you can realign so you can achieve your career goal faster.

So the cycle is clear: you work 👉 get feedback 👉 you improve 👉 you work 👉 get feedback.

It's a virtuous cycle, it's a positive feedback loop that will guarantee career improvement. Combine that cycle with an even tighter loop, you will get an ultra-tight feedback loop.

Instead of getting feedback once every year, it's much better to get feedback every month. You know what's even better? Yes, getting feedback once every week, even daily.

Yes, daily feedback loop is all we need. It's impossible to fail if you realign with your career goal daily.

Sounds hard? Not really, the trick is you don't think getting feedback as something formal. It's the complete opposite, try to get feedback in casual settings, as often as possible, because being casual will make people more open, thus giving more honest feedback on your work result, work ethics, work habits, etc.

Also, you don't wait until you are given feedback. Proactively ask for feedback. Here's how to effectively ask for feedback:

• After you finish your task (e.g. adding new features), you can immediately tag your senior/tech-lead on GitHub to ask for review. Personally ask "be brutally honest please"
• At lunchtime, strategically ask your colleagues/your direct report to sit at the same desk. Casually ask "what makes a good engineer in your opinion?"
• If you have several senior engineers at your place, they are gems. Ask them by saying "teach me master" or "roast my code".

The key is to keep things casual (not formal) because that's when people are more open and honest with you (especially if you frame the questions like jokes).

Exploit Parkinson's Law

Parkinson's Law states that "work expands to fill the available time", which essentially means you will slack off when working on a job. If you allocate a task with a 2-week deadline, it will be finished in 2 weeks. But if you allocate the same task with 2-day deadline, then it will be finished in 2 days.

Obviously this law isn't hard science, it's an observation that states people tend to procrastinate on their current tasks if there is no sense of urgency.

Fortunately, the opposite is also true. If you estimate the work can be done in 1 week, then try 1 day, and see how far you've gone. Just try it.

I was once assigned to fix a 3-month bug, nobody had been able to solve that bug for months. The deadline was 1 month away. I don't know if I even could solve the bug, but I promised myself I would solve it in 3-4 hours (stupid, I know).

I tried to solve it, and found some patterns from my previous experience with lots of bugs. And I solved the bug in a day (a 10-hour session to be exact). I just solved a bug with 3 months deadline within a day. I got paid $900 for solving that bug.

Here's the method to exploit Parkinson's Law. I call it: The Time Compression method.

Just like data compression, you compress time by encoding information more efficiently than the original format. Here's how:

Step 1: Identify Patterns. Just like Redundancy Detection in data compression, you need to identify recurring, tedious, boring, low-value tasks and see if they can be either grouped, delegated, or deleted.

Step 2: Prioritize High-value tasks first. Which is the equivalent of Symbol Weighting in data compression algorithm. After you identify patterns, you sort the tasks, and immediately target the high-impact tasks first.

Instead of building PCB straight from the requirements, why not create a prototype first on breadboard? Ensure the GPIO pins are all compatible, ensure the I2C sensors are working, try to find potential issues first like testing if the flash memory you're using is fast enough for your project (just an example).

Step 3: Find a better way to do things. If you know some action that can lead to a faster result, even though it means you need to learn something, then do it immediately. The payoff is doubled here: 1. You learn something new, 2. You solved the problem much faster.

Here's a concrete, real-life example: I was working on GPS tracking device at work. Obviously GPS will need to be outdoors to work normally.

The problem was, I worked on my PC to develop the firmware and troubleshoot issues, flashing firmware, monitoring log output, and it's indoor, so you can imagine the problem already.

The distance was 30 meters between my PC and the GPS, ideally I would need a USB extender to make it work. I didn't have one so I need to back and forth bring the GPS device inside to check the log and update firmware.

Totally inefficient. I have wide WiFi coverage, only if I can piggyback the USB packets via WiFi. And that's when I discovered USB-IP, a USB passthrough over IP. I learned a bit to setup (probably like 1 hour max). Connect a random Raspberry Pi (any raspi will do, including Zero Wireless) to the GPS device, and I can immediately access the device as if it were connected directly to my PC locally.

Instead of waiting for 3 days and wasting $20 for a 30-meter USB extender for this specific case, I used what I had, and I found a better way to do my things. 

Sometimes Step 3 is closely related to automation, well because one better way to do things is really by automating it. Another example is my little tool here:

At work, my company bought several solar panels of different sizes and powers. I was asked to characterize each solar panel and get the IV curve for each. Something like this:

Essentially I need to measure the voltage output while varying the load. To make the load variable, I need to use many power resistors with different values. Just imagine how tedious the task would be.

And this is another perfect example of automation. Instead of naively buying loads of resistors, and test one by one, I went another route: I built a dedicated electronic load that logs the current and voltage output.

I probably spent around 3-4 hours building it. But the ROI was invaluable.

In summary, Parkinson's Law can do bad or good for you, depending on how you use it. Exploit the law by using the Time Compression I've outlined above.

Delegate your work (even as an engineer)

Let's be honest, life as an engineer is full of tasks:

• Writing documentation
• Meeting to discuss ideas for new projects
• Gathering project requirements to answer business problem
• Exploring the best technology to solve the problem
• Selecting components, reaching out to vendors, calls with Field Engineers
• Writing and testing firmware code
• Coordinating with many stakeholders to ensure smooth development
• Etc.

Ah, too many. I'm even too lazy to list them all. You know me. And here's one recipe to ensure your life will be miserable:

Do everything yourself.

Busy is good. But if you're too busy, that means you're worthless and inefficient (especially if you sacrifice family time, personal time, and prayer time).

Look, if there's too much on your plate, this means you need to offload your tasks. In other words, you need to delegate some of your work.

I understand that your boss delegates some of his/her tasks to you, but that doesn't mean you can't delegate your tasks. Here's what I mean:

If you pay closer attention, you'll notice that some of your tasks are high-value but tedious, like thinking about what features an embedded project should have.

Or what chip to use, etc.

Realize that you can delegate those tasks to the most capable machine to work on those: generative AI.

Yes, I said it. Things like ChatGPT, Claude, Perplexity, Gemini. They can help you automate most of the tasks that require low creativity, but high precision.

For example, if I want to build a GPS tracker for heavy machinery, what standard features should I implement?

I can list them all by myself like:

• Able to track GPS coordinate
• Able to send data via LoRaWAN
• Able to store data in case of poor signal quality
• Able to store configuration

And the list goes on. There's a high chance I would miss some important features, well because I'm still a human.

Now, let's ask AI to help us do it:

Here's the raw output from my ChatGPT:

Building a GPS tracker for heavy machinery requires attention to durability, precision, and functionality tailored to the operational needs of construction, mining, and agricultural equipment. Here are the standard features you should implement:

Core Features

1. Real-Time Location Tracking

   • Use GPS/GLONASS/Galileo/Beidou for accurate global positioning.
   • Update intervals should be configurable (e.g., every 10 seconds to every few minutes).

2. Geofencing

   • Allow users to set virtual boundaries.
   • Trigger alerts when the machinery leaves or enters a specified area.

3. Activity Monitoring

   • Track engine runtime, idle time, and operational hours.
   • Provide insights into machine usage and efficiency.

4. Anti-Theft Alerts

   • Tamper detection (e.g., vibration or physical removal alert).
   • Movement detection when the machine is supposed to be stationary.

5. Durable Design

   • Rugged, waterproof, and dustproof casing (e.g., IP67 or higher).
   • Vibration and shock resistance to withstand harsh environments.

6. Remote Immobilization

   • Enable operators to remotely disable the machinery in case of theft or unauthorized use.

7. Power Supply and Backup

   • Connect to the heavy machinery's power source.
   • Include a rechargeable battery with sufficient backup (e.g., 24–48 hours) in case of disconnection.

8. Data Logging

   • Store data locally when the cellular signal is lost and sync it once the connection is restored.
   • Include non-volatile memory to prevent data loss during power outages.

9. Connectivity

   • Cellular Connectivity: Support 2G/3G/4G LTE and future-proofing for 5G.
   • Satellite Communication (optional): For remote areas without cellular coverage.
   • Bluetooth/Wi-Fi: For close-range configuration and firmware updates.

10. Over-the-Air (OTA) Updates

    • Allow remote firmware and software updates.

Advanced Features

1. Sensor Integration

   • Accelerometers and gyroscopes for motion, tilt, and vibration monitoring.
   • Temperature, humidity, and fuel sensors for environmental and operational monitoring.

2. Route Optimization

   • Provide insights into optimal routes for heavy machinery movement.

3. Driver Behavior Monitoring

   • Track metrics like harsh braking, sharp turns, and over-speeding.

4. Predictive Maintenance

   • Integrate with CAN bus or OBD-II to monitor engine health and notify users of potential issues.

5. Dashboards and Reporting

   • Provide a web or mobile app for tracking, analytics, and reporting.
   • Generate automatic reports (e.g., daily, weekly, or monthly usage summaries).

6. Multi-Device Support

   • Track and manage multiple pieces of machinery from a single interface.

Compliance Features

1. Regulatory Compliance

   • Ensure compliance with relevant regulations (e.g., emissions, safety, or transport laws) in the target region.

2. Audit Trail

   • Keep logs of operational data for legal or maintenance purposes.

Additional Considerations

• Energy Efficiency: Ensure the tracker consumes minimal power from the machinery.
• Localization: Support multiple languages and units of measurement for global users.
• Scalability: Design the system to support fleets of various sizes.

By focusing on these features, you can create a reliable GPS tracker that meets the specific demands of heavy machinery operations while offering value through advanced monitoring and management capabilities.

I'm not even thinking about geofencing and Anti-theft alert. But there are many good features to know.

Now, I don't have to implement everything, I have the list, and I just choose what I need to answer the business problem, and then I'll propose it to my boss.

Yes, the answer isn't complete. For example, I need it to be configurable, but I can always ask a follow-up request to chatGPT to breakdown the settings I need to have (interval settings, LoRaWAN OTAA or ABP, timeout settings, etc.)

This is just one example.

Another example is to delegate program writing to AI, especially if the program is very simple. I love to use AI to generate Python script utilities to help me finish my job.

I once needed to log a 24-hour UART output to analyze bugs, I needed a customized program to store the log into a file with specific naming rules. I know I could write a Python script myself, but instead, I just delegated it to chatGPT.

It generated the Python script, but when I reviewed the code, there were some minor issues. I told ChatGPT to change some parts of the code and the result was a robust, and good enough Python script to get things done.

Tips: Don't ask ChatGPT something you can't verify or correct. Think of it like an internship student who knows theory, but lacks practical experience and wisdom.

If you don't know how to write firmware, don't ask ChatGPT to generate firmware.

If you don't understand legal clause, don't ask it to generate a legal agreement document.

Remember, generative AI is there to help you accelerate tasks you already know how to do, not tasks you know nothing about. In my observation, many beginners (ab)used gen AI and treated it like a demigod who knows all. And blindly copy and follow every output it spitted. Not a good way to use AI.

Quantity over quality

To work less as an embedded engineer, you need to do quality job at work.

But, unless you're learning about fitness and gym, at the beginning you need quantity over quality.

As a beginner learning something new, forget about quality. You don't know what defines quality so you are better off by doing quantity first. Do it enough time until you get a sense of the "best" way to achieve the goal.

And here's a secret: you do quality at work, and you do quantity at home.

Yes, that's the irony of working less. You essentially work more outside your job, so you can work less at the workplace.

Just remember Tiger Wood, the golf champion. He had practiced 5-figure hours before he even became the world champion. He would practice his swings, his pose, and his mentality outside competitions, not inside competitions.

Your "golf competition" is your workplace, and your practice sessions are outside of it.

Exposure to lots of things

Lastly, what you truly need to work less is knowing how to do your job. Yeah I know it sounds obvious, but hear me out.

When you first do anything, you will be suck. Because you need to get to know the topic, you need to familiarize yourself with the relevant tools, you need to understand the core concepts. All of those are important when you're working as an embedded engineer.

For example, the first time you learn CAN bus, everything is hard:

• You need to understand what is CAN bus, and where it's used
• You need to understand the core concepts of CAN bus, the signaling system, the protocol
• You need to learn the CAN bus transceiver chips, probably you have to read the entire datasheet
• You need to learn the tools to analyze CAN data, and how to troubleshoot them
• etc.

As you begin to be familiar with the CAN bus workflow, you begin to see patterns, and next time you're tasked to work on CAN bus, everything feels easy.

Remember, the CAN bus is still the same, but somehow, something that was hard, now is easy peasy. Hard knowledge about CAN stays unchanged, it's your brain that grows.

Now, imagine you're hanging out with your fellow engineer friends every weekend. Imagine last weekend you both talked about his work, about Modbus.

Your friend started to blabber about Modbus, whining about bugs and issues, and because you were curious, you asked him about Modbus, what's the difference between Modbus vs CAN bus, and how did he solve the bugs he was facing.

He told you everything he knows, the basic concepts, the tools, the mechanisms. And you started to get familiar with Modbus, although you have never touched a Modbus project before.

Next month, your company announced that they are starting to use Modbus for your embedded project. Bingo!

You are given 1 month to learn Modbus and write firmware for the prototype. Guess what? You probably don't need 1 month to finish, probably 1 week is more realistic, because all the most important parts (aka the foundational) have been learned (thanks to your friend).

Imagine: 1 month down to 1 week. That's a 400% acceleration.

What do you do in week 2 and so on? You tell me. I don't and won't dictate what you should do (Hint: learn something that will propel your career even further). 

Now, exposure can be in many forms:

• From your hangout friends (like above)
• From your weekend reading
• From your side project experiments
• From doing freelance work

From those options, the last one is interesting. Because by doing freelance work, the benefit is twofold now: 1. You are learning something new. 2. You get paid.

The more exposure you get, the easier it is to work on pretty much any topic. Because embedded is an industry with strong hands-on requirements, the more your hand gets dirty, the faster you can work, thus making yourself far more efficient at the workplace.

Get ready to be promoted, because from my experience, companies reward those who showcase lightning-fast learning speed. Your influence will be higher, people are seeking your advice, and beware, you will attract haters too! (office politics are always an ugly thing, you know).

That's all you need to know to work less as an embedded engineer.

Remember, working less doesn't mean you're lazy. In fact, it's the complete opposite. The ability to work less means you're efficient, and by being efficient you can tackle more harder problems and solve more high-impact problems in your life, and at your workplace.

Personally I prefer being more efficient at work, because that way, I don't need to worry about overtime, struggle to find basic knowledge, etc. Thus saving my energy after work. I'm married with one 3-year-old son, so I would rather play with him instead of spending more hours at work, doing things I should be delegated, compress, or delete.

Whenever you're ready, there are 2 ways I can help you:

1. FREE Firmware Development Email Course. A free 7-Day Email Course to teach you the foundational concepts you should know to start firmware development. Full of practical tips and industrial insights.

2. FREE Embedded Freelancing Email Course. Another free Email Course to help you grasp the basics of embedded freelancing and make more money as an embedded engineer.