The simplest way to 10x your embedded learning speed:

Tons of experimental projects — here’s why:

• Experimental projects will help you learn in isolation (an important concept)
• They will act as training wheels
• They can be reused as future project’s template

Now let's delve into each one.

They will help you learn in isolation

Yes this is an important thing when learning. Learning in isolation means you learn one thing at a time.

Building full-scale embedded projects, while it's also good, will expose you to too many things at once. Let's say you learn embedded by exploring Smartwatch firmware source code, you will have to learn heartbeat sensor code, timekeeping code, display code (very complex), code for Bluetooth LE, and tons of other moving parts. All at once.

That sounds overwhelming.

It's better to build a project for each concept you want to learn. For example:

• A project containing how to drive an OLED display
• A project about how to broadcast Bluetooth LE advertisement payload
• Another project for heartbeat sensor to understand heart arrhythmia (I don't even know what that is lol)

In summary, learning in isolation will help your brain manage stress and deliberately practice one thing in one project.

They will act as training wheels

The funny thing about experimental projects is that, you will soon feel more confident to learn the next thing.

For example, once you've experimented with BLE, next time you need to add BLE will feel effortless and smooth like butter.

Somehow now you know BLE GATT, GAP, various generic profiles, how to config advertisements, etc. This time you work faster, and better. You know the common errors that could show up, plus how to solve them. Weird, but now BLE felt natural for you.

Switch to another project, and you will learn much faster.

Actually, to your surprise, this is backed up by science. Just look at the drawing I made below:

Apparently, learning embedded systems is all psychological.

They can be reused as future project’s template

Lastly, this is probably the best way to reuse your learning folders: by making them as templates.

That way, you don't even need to worry about various configurations, you just copy and paste. And voila! You have added a new feature.

For example, in your BLE project before, you already made a BLE profile for Heart rate sensor, next time you need BLE with a heart rate sensor, you could just pull the folder and clone it. It will probably take 5 minutes (instead of redoing the same shit for 45 minutes, big win!).

The 2-Rule Method

All the above sounds easy, but to make it effective, there are lots of nuances to understand before you do it.

I created a 4-Rule Method to help you create experimental projects far more effectively.

Rule #1: Aim for 100 Side Projects

Part of being an excellent embedded engineer is just mere exposure. Create at least 100 side projects for 100 concepts you want to learn.

Yes, it seems daunting at first. But 100 projects are actually achievable if you learn lots of things.

Create a new project to learn how to interface a sensor with I2C.

Create a new project to convert analog signal into digital signal using ADC.

Create projects for different microcontrollers.

Make sure you understand each project, each line, and each configuration. Don't just blindly copy-paste code online because it will defeat the purpose of experimentation.

Look at my experiment folder:

I have plenty of reusable projects in my stash.

Rule #2: Ditch best practices

Except you are experimenting with best practices, please ditch best practices, for now. The goal is to exposure to lots of things, including bad, stupid, dumb practices. You don't learn just from good things, but also from bad things.

Should you host the project on GitHub? Up to you.

Should you use Arduino or mbed? I don't know.

Even better, keep breaking rules in embedded systems to see how far you can abuse the project. Pick bad variable name, create 10000 lines main.cpp, try to overflow buffer. What happens if you don't draw diagram first.

You will learn something. And you will learn why such things are considered bad in the first place.

Ditch the rules in experimental mode. But use all the best practices you know at work.

Bonus Rule: Prioritize Quantity over Quality

Yes, you read it right.

You should prioritize quantity over quality. Because quality work comes from lots of repetition. How do you think Tiger Woods perfected his swings?

Don't be too afraid of low-quality side projects, nobody will see them anyway.

Trust me, the quality will follow later. Focus on quantity first. Let me remind you of this quote:

90% of everything is crap

Sturgeon's law

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

1. Professional Firmware Development Guide. If you're looking to build professional-grade firmware, I share 6+ years of expertise developing firmware. This guide shows you the exact workflow I use to build high-quality firmware for my company and my freelance clients.

2. Join other 2400+ engineers by subscribing my newsletter.