🚀 Learning by Doing -- and Understanding
As a developer, one thing I strongly believe is that there’s no better way to learn than getting hands-on and diving into the official documentation of the technology we’re working with.
Nothing against step-by-step YouTube tutorials or plug-and-play little libraries that come with everything ready to go. They have their place: they help speed up prototyping, save time with tested and reliable solutions, and even teach us the best ways to apply the core concepts. But when it comes to deep learning -- especially in areas where performance and optimization are crucial (like games or embedded systems) -- understanding how things work under the hood makes all the difference.
Yes, it’s more work, and it takes more time. But the knowledge we gain stays with us, and it makes us faster when facing future challenges. It’s like Megaman, the classic game character -- he absorbs the power of the enemies he defeats, making it easier to beat even stronger ones later on. I love this metaphor, and you’ll definitely "hear me talk" a lot about the "Megaman Method". 🔵⚙️
📡 Exploring Wi-Fi Networks on the RP2040
Recently, as part of a hands-on embedded systems residency program I'm currently enrolled in, I worked with the RP2040 microcontroller to scan for Wi-Fi networks using the cyw43 driver from the official Raspberry Pi SDK.
The proposed challenge was simple: print the found networks to the serial monitor. But I saw a great opportunity to go further. Instead of just printing to the terminal (as suggested), I built an interactive network selector directly on the BitDogLab board (an educational board with buttons and a display -- I’ll be talking about it more around here, too).
It was an awesome experience -- beyond learning how the driver and SDK work internally, I ended the day with a fully functional piece of software, ready for my portfolio or as a base for future projects. (I even made my own "little library"!)
⏱️ Understanding Interrupts with a Timer
Another interesting challenge we faced involved using interrupts to build a stopwatch. The goal was to better understand how interrupts work on the microcontroller by using callback functions with repeating timers.
While reviewing a friend's code, I noticed he was manually tracking the elapsed time using a variable. That got me thinking: "Doesn’t the SDK already offer a function to return elapsed or remaining time?" I went digging through the documentation -- and yes, it does: pico_time/time.c -> remaining_alarm_time_ms.
A simple question ended up leading me to a better understanding of the SDK’s built-in features and allowed me to write cleaner, more reliable code -- and with more functionality.
📦 The Art of Building Little Libraries
Creating small libraries during development is a great way to practice concepts like modularity, code reuse, and project organization. Besides making the software or game more scalable and reusable, this kind of practice reinforces solid design and architecture principles.
These are essential skills for tackling larger projects -- not to mention the soft skills involved, like autonomy, curiosity, and initiative, all of which are highly valued in any tech team.
🎮 And in Game Development? The Logic Is the Same.
In the gamedev world -- especially when working with popular engines like Godot or GameMaker -- we have access to an ocean of plugins, add-ons, and ready-to-use libraries. And that’s great -- but it can become a trap if we stop understanding how and why things work.
When we create our own systems (a scene manager, AI logic, camera controller, particle system, etc.), we not only learn much more, but we also build real technical baggage, gain independence, and -- over time -- start making smarter decisions in future projects (after all, we already know the pitfalls to look out for at each stage).
🧠 Final Thoughts:
Learn by exploring. Go beyond what’s necessary. Don’t be afraid -- or lazy -- to understand why things work the way they do. We only grow from it. 💫
Thanks for making it to the end -- See ya! ✌🏼
