Why Giving Advice Is Easier Than Doing the Work (Especially in IoT and Embedded Systems)

☝☝☝☝

It’s something I’ve become increasingly aware of while working on technical projects: giving advice is often far easier than actually doing the work. On the surface, a suggestion can sound simple, logical, and even obvious. But once you’re the person responsible for implementing it, the reality quickly becomes more complicated. This gap between theory and practice is something every developer eventually encounters, and it’s particularly noticeable in hands-on fields like IoT and embedded systems.

When someone isn’t directly involved in a project, they don’t carry the same constraints. They’re not dealing with the specific hardware limitations, firmware quirks, time pressures, or integration challenges that define the day-to-day reality of the work. As a result, their advice can be well-intentioned but disconnected from what is actually achievable. It’s easy to recommend a clean solution when you’re not the one responsible for making it function under real conditions.

This becomes especially important when working with IoT networks. On paper, connecting devices, transmitting data, and visualising results sounds straightforward. In practice, however, there are countless points of failure: unreliable connections, inconsistent sensor readings, power constraints, and communication protocols that don’t always behave as expected. What looks like a simple architectural decision can turn into hours or even days of debugging.

Embedded systems take this challenge even further. When firmware is involved, you’re no longer just writing code, you’re working directly with hardware behaviour. Timing issues, memory limitations, and low-level bugs can all influence whether something works or fails. A suggestion that sounds perfectly valid in theory may not account for these constraints, and implementing it can introduce problems that weren’t visible at the outset.

One of the most frustrating situations is when someone confidently says, “That definitely works,” only to discover that their knowledge is based on outdated information. In fast-moving technical environments, especially with microcontrollers and supporting libraries, things change quickly. Firmware updates, library changes, or hardware revisions can break previously working solutions. What worked a year ago might no longer apply, and relying on that advice can lead you down an unproductive path.

The real cost of this isn’t just technical, it’s time and momentum. Following a recommendation that doesn’t hold up in practice means backtracking, rethinking your approach, and sometimes undoing hours of work. This can be particularly difficult when you’re trying to make steady progress on a project, only to find yourself dealing with the fallout of a decision that seemed reasonable at the time.

That said, this doesn’t mean advice is useless, far from it. Advice can be incredibly valuable when it’s grounded in current, relevant experience. The key is learning how to evaluate it. Asking questions like “When did you last use this approach?” or “Was this on similar hardware?” can help you determine whether a suggestion is worth pursuing. Over time, you develop a sense for which ideas are likely to translate into working solutions.

Ultimately, working on technical projects teaches you something deeper than just coding skills: it teaches judgment. You learn to balance external input with your own understanding of the system you’re building. You become more cautious about implementing suggestions without testing them, and more confident in trusting your own observations. And perhaps most importantly, you realise that while advice is easy to give, the real expertise comes from doing the work and dealing with the consequences when things don’t go to plan.

If you are the project manager and the software developer for your own project or a group project when you are doing most of the work it's OK, but don't do both jobs simultaneously, it's not possible. Do your project management jobs first, you need to get them completed before you can get into the technicalities, then use a pen and paper notebook to write down your own plan with instructions for yourself. Now that you've got a goal, a direction, development targets and a design for overall system you can get into your own developer mindset and focus on that for hours, occasionally referring back to your own written instructions when required.